アプリ・スコアカード

アプリ・スコアカード は何をしますか？

このSKILL.mdと同じディレクトリにLOCAL.mdがある場合は、まずそれを読んでください。このワークスペース固有の情報（パス、ツール、例）が含まれており、以下の一般的なデフォルト設定を上書きします。

1つのルーブリック、すべてのアプリ、毎回。目的は比較可能性です。同じディメンション、同じ0～5の基準、同じゲートを使用するため、3月に採点したアプリを6月に再度採点すれば、その差分に意味があり、2つのアプリを基準を再議論することなく比較できます。

「What Makes an App Exceptional」調査レポート（references/framework-source.md）と、そのギャップを埋めるためのターゲット調査（references/research-notes.md）に基づいて構築されています。完全な23ディメンション実行の実例（匿名化）：assets/example-audit.html。

原則（一度読めば、すべての判断の基礎となります）

1. スコアより先にゲート。 セキュリティ、プライバシー、法的、アクセシビリティ、そして事実を主張するアプリについてはコンテンツの正確性は非補償性です。デザインで5を取っても、プライバシーで0を取ったことを相殺できません。最初にオープンゲートをリストアップし、平均化してはいけません。
2. 意見よりもエビデンス。 すべてのスコアにはエビデンスグレード（E0: 主張 → E4: 確固）が付与され、すべての所見は Observed（観察） / Inferred（推測） / Hypothesis（仮説） / Unknown（不明） でタグ付けされます。
3. コードから行動を推測してはいけません。 リテンション、エンゲージメント、マーケットフィット、満足度、収益は、テレメトリー、コホートデータ、またはサーベイがない限り 不明 です。コードやスクリーンショットで証明することはできません。「おそらく」ではなく「不明」と明記してください。
4. ステージがルーブリックを決定します。 Pre-PMFのアプリは、SLO（サービスレベル目標）を持っているかではなく、学習しているかで判断されます。references/stages.md を参照してください。
5. ベンチマークよりサイクル。 普遍的なD7リテンションはありません。週次のジョブで「2週間に数回」使われているのが健全です。まず自然なサイクルを特定してください。
6. すべての弱いディメンションに最小修正を。 修正案のないスコアカードは苦情です。1行、元に戻せる、時間単位または日単位でサイズを見積もってください。

ワークフロー

0 · フレーミング（5分、省略不可）

1行ずつ、次の項目を確定します：ターゲットユーザー · プライマリジョブ · 自然なサイクル · ファーストバリューイベント · ビジネスモデル · 主な代替手段（「何もしない」を含む）。リポジトリに AGENTS.md / README.md がある場合、それらから引用して記載します。ない場合は推測し、その前提を明記して進めます。

次にステージを選択します（references/stages.md）：

ステージ	シグナル	ルーブリック
Pre-PMF	アクティブユーザー100人未満、コホートデータなし、またはSean Ellisの「非常に残念」が40%未満	9ディメンション + ゲート
グロース	コホートが存在、アクティブ100人超、または有料顧客がいる	全23ディメンション + ゲート
アイデア / 設計書	まだコードがない	仮説品質のルーブリックのみ（stages.md §3）

1 · エビデンス収集（可能な限り並行して）

常時（コード + デプロイ環境）：

• ルート / 画面、APIサーフェス、認証と認可の強制（サーバーサイドか？）
• テスト：実行する。リント：実行する。CI：ワークフローを読む。デプロイ：スクリプトを読む。
• テレメトリー：実際に送信されているものは何か？（アプリがホストされていないプラットフォームをターゲットにしたアナリティクスのインポートは何もカウントしません。）
• ストア / DB：ユーザーごとに何が書き込まれているか、削除はあるか、バックアップはあるか。
• プライバシー / 利用規約 / 削除ルート。有料APIのレート制限とクォータ。
• アクセシビリティのgrep：aria-、alt=、focus-visible、prefers-reduced-motion、ラベル。
• i18nカバレッジ：文字列が外部化されているかハードコードされているか、ロケール、複数形/日付ルール。
• エラー / 空 / ローディング / オフライン状態。ルートレベルの error.tsx / not-found.tsx。
• パフォーマンス：サーバーサイドまたはクライアントサイドの重いデータ、キャッシュ、記録されていればp95。
• AI / リファレンスアプリの場合：アトリビューション + 引用ロジック、グラウンディングガード、ハルシネーション制御、コーパスの出典。

利用可能な場合（行動）： ベータフォーム、アナリティクス、コホートテーブル、サポートチケット、Sean Ellisサーベイ結果、観察されたセッション。これらによりディメンションが「不明」から実際のスコアに引き上げられます。これらがない場合は、不明のままにします。

幅広くカバーするために読み取り専用の Explore エージェントを（最大3つ並行で）展開します。エントリポイント、ナビゲーション、コアフロー、認証、ストアは自分で読みます。

2 · ゲートをチェック

references/rubric.md §Gatesより。各ゲートは open（開） / closed（閉） / n-a（該当なし） で、観察されたエビデンスとともに記述します。オープンゲートはすべての出力の先頭に配置します。よくある例：個人情報を収集しているのにプライバシーポリシーや削除パスがない、支払いがあるのに利用規約がない、サーバーサイドの認証が欠けている、高齢者向けのアニメーションがあるのに prefers-reduced-motion 対応がない、リファレンスアプリでコンテンツの帰属や引用が不適切。

3 · 各ディメンションを採点

選択したルーブリックの各ディメンションについて（references/rubric.md）：

• ルーブリックの基準（感覚ではない）を使用して0～5で採点。
• エビデンスグレード E0～E4 とタグ（Observed / Inferred / Unknown）。
• ディメンションのチェックリストにチェック：present（あり）/ partial（部分的）/ missing（なし）/ unknowable（判断不能）。
• ファイル:行、ルート、設定、引用に基づいた1行の所見。
• スコアが3以下の場合、1行の最小修正。

UI / UXデザインについては、rubric.md §UX Designのビジュアルデザインサブルーブリック（タイポグラフィ、階層、色、スペーシング、一貫性、コピー）を使用します。ここで詳細が必要な場合は、スコアカードの後に ui-usability-audit を起動し、そのレターグレードを参照します。

4 · 判断

• オープンゲート（再度、最初に）。
• 勝つためのトップ3理由 · 失敗するトップ3理由 · トップ3の不明点。
• 最もレバレッジの効く次の実験または修正。
• 評決：Go（ゴー） / Conditional Go（条件付きゴー） / Iterate（イテレート） / No-Go（ノーゴー）、確信度付き。 経験則：1つでもオープンゲートがある場合、最大でも Iterate。すべてのゲートがクローズされ、バリューイベントが計測されていれば Conditional Go。自然なサイクルで4週間分のリテンションデータがあれば、Go が視野に入ります。

5 · 成果物の提供 — ビジュアルスコアカードが成果物です

チャットメッセージはサマリーです。公開されたHTMLスコアカードアーティファクトが出力です。 これなしに実行を終了しないでください。Artifactツールが利用できない場合（Codex、サブエージェント）、アプリのリポジトリに docs/scorecards/<日付>-scorecard.html としてHTMLを書き込み、代わりにそのファイルを送信/開いてください。

1. アーティファクトの構築：assets/scorecard-template.html から開始します。artifact-design スキルを最初に読み込み、テンプレートの構造をこの順序で正確に維持します。これにより、すべてのアプリのスコアカードが同じように読めるようになります。
   1. ヘッダー — <アプリ名> スコアカード、ステージ + エビデンスソース + 日付のアイブロウ、1文のテーゼ、評決チップ（go / デフォルト琥珀色 / nogo クラス）、確信度、およびフレーミングストリップ（ユーザー · ジョブ · サイクル · バリューイベント · 代替手段）
   2. 一目でわかるグリッド — ディメンションごとに1タイル、スコアバンドで色分け（teal ≥ 3、amber 2、red ≤ 1、grey unknown）、オープンゲートがあるディメンションには gate アウトライン、前回の実行との差分があれば▲/▼のデルタ。
   3. ゲート — すべてのゲートをカードとして：オープン（赤）またはクローズ（緑）、観察されたエビデンスと code 内のファイル/ルート名。
   4. ディメンション別カード、グループ化（戦略と経済性 · エクスペリエンスと信頼性 · エンジニアリングとスケーラビリティ、またはTier Aリスト）：スコア、エビデンスバッジ、2～4文の所見、present/partial/missing/unknowableのマークが付いたチェックリスト、スコア3以下には最小修正行。
   5. 最終判断 — 3カラム（勝つ理由 · 失敗する理由 · 重要な不明点）と、ダークな「最もレバレッジの効く次のステップ」パネル。
   6. 方法論のフッター — 何を読み、実行し、拒否したか。前回の実行へのリンク。 デザインルール：実際のコンテンツのみ、ダミーテキスト禁止。すべての色はトークンセットから（ダークモード対応）。絵文字や装飾的なチャートは禁止。数字はtabular monospace。レンダリングされたページを一度見て、問題を修正してから公開する。
2. 公開：Artifact を使用。タイトルは <アプリ名> スコアカード、最初の公開時のみファビコン🔬。再実行時は、前回のアーティファクトの url を渡して、履歴が1つのリンクに保たれるようにします（docs/SCORECARD.md で確認）。
3. チャット：最初にリンク、次にフレーミングブロック、オープンゲート、コンパクトなテーブル（ディメンション · スコア · エビデンス · 所見）、評決。簡潔に。アーティファクトの散文を重複させない。
4. 永続化：アプリのリポジトリにある docs/SCORECARD.md に行を追加します（なければ作成）：日付 · ステージ · オープンゲート · ディメンション別スコア · 評決 · アーティファクトURL。ユーザーが要求した場合のみコミットします。

ルール

• 完全に読んでから採点する。 ルーブリックは判断を短縮するものであり、読むことを短縮するものではありません。
• テスターやファイルがその通り言っている場合は、言い換えずに引用する。
• わからないことは採点しない。 「不明」は有効で正直なセルです。
• ベンチマークをでっち上げない。 引用してよい唯一の数値しきい値は、references/research-notes.md にあるものです（SUS 68/80、Ellis 40%、CWV 2.5秒 / 200ミリ秒 / 0.1、Nielsen重症度0～4、WCAG 2.2 AA、ASVS L1）。それ以外は、アプリ自身の前回の実行との比較です。
• すべてのアプリで同じルーブリックを使用する。 アプリごとにディメンションを追加したり削除したりしないでください。ディメンションが本当に該当しない場合（例：内部ツールでの収益化）は n-a とマークします。n-a は記録され、スキップされません。
• ライブアプリを操作する必要がある場合、開発環境/ステージング環境のみ。 本番環境は不可。
• 読み取り専用。 スコアカードは推奨するものであり、アプリを編集するものではありません。
• アーティファクトなし、実行なし。 チャットのスクロールバックにしか存在しないスコアカードは、次の四半期には比較できません。常に公開する（またはHTMLファイルを書き込む）。

関連スキル

• ui-usability-audit — UXデザインディメンションの深掘り、ビジュアルのビフォーアフター。
• qa-sweep — 機能のPASS/FAILで、信頼性とコアUXにフィードします。
• dev-to-prod-promotion-review — スコアカードの評決がリリースゲートへのインプットになります。
• panel-brainstorm — 「最小修正」に代替案が必要な場合。