Skill.md検索

スコアリングモデルの設計・変更: ブランド適合度・疑似アクティブ度・リスク度などのサブスコアを定義し、重み付けして総合スコア（0〜100）を算出。モデル変更時は必ずADRに記録し、既存スコアとの回帰テストを実施できます。 データソース・信頼度の明確化: 各スコアが「事実データ（Instagram API取得）」「計算値」「LLM推定」「取得不可」のいずれかを明記し、スコアの来源を透明化できます。 スコア変更時の互換性維持: 旧スコアを「legacyScore」フィールドに30日間保持し、差分を計算するマイグレーションスクリプトを自動生成。既存レポートへの影響を最小化できます。 サブスコア一覧の統一管理: ブランド適合スコア・疑似アクティブ度スコア・リスクスコア・エンゲージメント率・フォロワー品質スコアの定義を型（Typescript等）として整理し、全チームで同じ定義を使用できます。 欠損データへの対応: 一部データが取得不可の場合、スコアをゼロにせず重みを再分配する仕組みで、部分的な情報でも信頼性の高い評価が可能です。 データサイエンス・分析担当: スコアリング仕様を厳密に定義し、複数バージョン間での互換性を保ちながら改善したい人 プロダクトマネージャー: インフルエンサー評価の基準を可視化し、ステークホルダーに説明可能な形にしたい人 ML/DataOps エンジニア: スコア計算パイプラインを設計・運用し、LLM推定値の信頼度を管理したい人 経営企画・意思決定者: スコアの算出根拠（信頼度・データソース）を把握し、評価結果に基づく意思決定をしたい人 総合スコア（0〜100）はブランド適合スコア×0.4 + 疑似アクティブ度スコア×0.35 + リスクスコア（反転）×0.25で算出。サブスコアは5種類（ブランド適合・疑似アクティブ度・リスク・エンゲージメント率・フォロワー品質）で、いずれも0〜100範囲。スコアフィールドはvalue・type・confidence・source・calculatedAt・evidenceを含む構造を必須化。type は fact（API直接取得）・estimated（計算値）・llm（LLM生成）・unavailable（取得不可）の4値。計算手順は①Instagram Graph APIで事実データ取得→②計算値算出→③LLM分析実施、②各サブスコア正規化→欠損値への重み再分配→総合スコア算出、③スコア+evidence返却。変更時互換性方針として差分計算スクリプト・旧スコア保持（30日）・回帰テスト実施必須。gotchasではゼロ除算対策・LLM非決定性（calculatedAtとモデル名記録）・エンゲージメント率定義統一・データ鮮度管理（30日以上で再計算）を記載。

データが「事実なのか・推定値なのか・AI生成なのか」を視覚的に区別するデザインガイドを使って、ユーザーが情報の信頼度を一目で判断できます。 テーブル、フィルタ、比較ビューなど、ダッシュボード画面で必須の機能の実装ルールが明示されているので、バラバラな実装を防げます。 Instagram URL / ユーザーネーム入力のバリデーション仕様が含まれ、不正な形式の入力を事前ブロックできます。 ローディング・空状態・エラー・非公開アカウントなど、あらゆる状態表示のパターンが定義されているので、ユーザー体験の一貫性が保たれます。 レスポンシブ対応（デスクトップ主体、タブレット動作、モバイル制限表示）とInstagram API の遅延対策（スケルトンローダー）も含まれています。 Instagram 分析など、推定値と事実値が混在するダッシュボードを設計・実装するフロントエンドエンジニア データの信頼度を明確に表現する必要がある分析ツール・SaaS の UI 設計者 テーブル、フィルタ、比較ビュー機能を含む複雑なダッシュボードを標準化したいチーム Instagram API 連携時の遅延対策やエラーハンドリングをガイドに従いたい開発者 データ表示の原則では、fact（事実）は通常表示、estimated（推定）はグレー系+[推定]バッジ+信頼度アイコン、llm_generated は[AI分析]ラベル、unavailable は—表示+[取得不可]ツールチップで区別します。信頼度は high=グリーン dot、medium=イエロー dot、low=レッド dot+警告アイコンで表現します。状態管理は、ローディング時スケルトン、空状態は「候補がありません。URLを入力して追加してください」、エラーはメッセージ+再試行、非公開アカウントは「非公開のため分析できません」と表示します。テーブル設計はtemplates/table-filter-template.md参照で、ソート・フィルタ・ページネーション（20件/ページ）・列表示切り替えが必須機能です。比較ビューは最大10件横並び、超過時横スクロール、選択候補を固定ヘッダー表示、数値は棒グラフ、推定値と事実値で色分けします。フォーム入力はhttps://www.instagram.com/username/「https://instagram.com/username」「@username」「username」が有効で、TikTok URLや空文字は無効です。レスポンシブは1280px 以上デスクトップ、768〜1279px タブレット、モバイル制限表示対応。gotchas として、API応答2〜10秒でスケルトン必須、LLM テキストの innerHTML 直接挿入禁止（XSS対策）、比較ビュー10件固定は横スクロール必須を記載。

技術選定の理由を後から確認できる - フレームワークやデータベース、認証方式など重要な選択をした際に、「なぜこれを選んだか」を文書として残せます 意思決定のトレードオフを可視化 - 複数の候補案を比較し、それぞれのメリット・デメリットを記録することで、チーム全体の理解が深まります 設計変更時の参考資料になる - 過去の判断を参照できるため、同じ議論を繰り返さず、より良い決定ができます 新しいチームメンバーへの引き継ぎが楽 - なぜこの設計になっているのかが明確に記録されているため、オンボーディング（新人研修）がスムーズです 廃止・変更時の履歴が残る - 決定が古くなった場合、いつ何が理由で変わったかを追跡できます プロダクトマネージャー・プロジェクトリーダーで、チームの意思決定を整理・共有したい人 エンジニアリング責任者で、アーキテクチャの判断根拠を文書化したい人 複数チームが関わるプロジェクトで、設計方針を統一・説明したい人

PRD（製品要件書）を効率的に作成 - 背景・ターゲットユーザー・機能・非機能要件など必要な項目をテンプレートに従って埋めるだけで、開発チームが実装できる仕様書が完成します ユーザーストーリーで要件を可視化 - 「誰が、何をしたくて、なぜか」の形式で書くことで、単なる機能リストではなく、ユーザー視点の要件が明確になります 受け入れ条件で曖昧さを排除 - 「高速に動作する」ではなく「読み込み時間が500ms以下」のように、テストで確認できる条件を定義でき、開発時の迷いが減ります データソースと信頼度を明記 - 取得できるデータ・できないデータ、推定値の精度など、プロジェクト固有のルールを仕様に組み込めます スコープを明確に管理 - 「入れるもの」「入れないもの」を明確にすることで、要件のズレを防ぎます プロダクトマネージャー・プロダクトオーナーで、要件定義を効率的に進めたい人 デザイナーで、開発前に詳細な要件を理解しておきたい人 スクラムマスター・プロジェクトマネージャーで、要件の曖昧さを最小化したい人 エンジニアで、「何を作るか」を正確に理解した上で実装したい人