App Excellence — アプリ制作基準(手順ゲート制)

アプリ・機能の要件を受け取ったら、最初に references/artifact-first-delivery.md を読み、成果物先行で以下の8手順を進める。各手順のゲートは内部品質条件であり、依頼者への質問・返答待ちを意味しない。急ぎの案件でも手順は飛ばさず、仮説を明示して薄く通過する。手順番号は本スキル内部の番号であり、app-orchestrator のステージとの対応は同定義の裁定ルール5(語彙)にある。リリース可否そのものは INV-5 の3判定だけで決まり、本スキルのゲートはそれ以外の理由で公開を止めない(INVARIANTS.md)。

成果物はプロジェクトの docs/product/ に保存する。テンプレートは本スキルの assets/ から複製する。会話で合意しただけの仕様は、存在しない仕様として扱う。

手順と参照ファイルのルーティング

手順	やること	その手順で読むファイル	成果物	ゲート条件
0	問題フレーミング	references/artifact-first-delivery.md + references/01-requirements.md	仮説入り問題定義	「誰の・何の課題か」を証拠から一文で書け、事実と仮説が分離されている
1	要件定義(5層分解)	同上	assets/T1-requirements.md を複製して記入	成功指標が数値で定義され、Non-Goalsが3つ以上ある
2	体験設計	references/02-experience-design.md(+ 外部データ取込・マスタ・締め処理があれば references/data-lifecycle.md)	assets/T2-experience-spec.md	全画面に6状態が定義され、ピーク/エンド体験とcatalog-default provenanceが指定済み
3	機能分解・計画	references/03-feature-decomposition.md	assets/T3-feature-map.md	縦切りスライスに分割され、最リスク仮説と全層trace・要件フラグ・UI sliceのcatalog adoptionがSlice 0〜1に入っている
4	実装ループ	references/04-build-standards.md(+ 同上の場合 references/data-lifecycle.md)	動くスライス	スライスごとに: 全層trace実装+保存/再読込/更新/失敗回復E2E+UI sliceのcatalog検査+計測イベント+デモ可能
5	品質ゲート	references/05-quality-gates.md + references/checklists/ 全4種	検査記録	4チェックリストに加え、可視UIはjp-web-design references/catalog-default-contract.md の現在段階のconformanceを検査し、T4へ記録した
6	リリース判定	references/05-quality-gates.md §4	assets/T4-release-readiness.md	v0: mvp-first §4 の必須4項目 + launch-security の v0 ゲート(CRITICAL ゼロ) / v1: 同 + launch-security の v1 ゲート + T4 が「Go」+ 依頼者の受け入れ確認済み
7	リリース後学習	本ファイル §3	学習メモ	初週の計測レビュー日が決まっている

各referenceは該当手順に入った時点で読む(先読みして要約で済ませない。原文の規範に従う)。

§1. 判断の最上位ルール(常時適用)

1. Evidence → Decide → Draft → Validate → Diff: 通常は事前質問ゼロ。調査から最有力案を1つ選び、質問より先に判断可能な成果物を作る(references/artifact-first-delivery.md)。
2. 体験10原則(詳細は references/02-experience-design.md §1)が競合したら番号の若い方が勝つ: ①速さは最上位の機能 ②システム状態を常に見せる ③確認より取り消し ④選択肢を減らす ⑤親指で完結 ⑥プラットフォーム慣習に従う ⑦記憶させず認識させる ⑧文字より状態で伝える ⑨ピークとエンドを設計する ⑩通知は礼儀
3. 依頼者が機能(L5)を語ったら、証拠から課題(L1)と成果(L2)を再構成する。根拠が弱い値は可逆な仮説としてT1へ書き、空欄や質問待ちで止めない。L1に戻せない機能はT1の保留リストへ
4. 心理学は倫理ガード付き: ユーザーの目標達成を速くするためだけに使う。ダークパターン禁止リスト(references/checklists/ux-psychology.md §C)への該当は launch-security の CRITICAL として扱う(INV-3。v0・v1 とも公開不可)
5. 測れない品質は品質ではない: 成功指標・性能予算・計測イベントは機能と同時に設計・実装する
6. 要求変更は歓迎し、必ずT3に新カードとして追加する(既存スライスに滑り込ませない)
7. 人が直した値と、確定済みの数値は、システムの都合で書き換えない: 取込値は手修正で上書きしない/確定済み期間はマスタ変更で自動的に変えない(references/data-lifecycle.md)。該当する案件では手順2でこの方針を決めてからT2を書く

§2. サイズ判定(最初に実施し、T1に記録)

• S(画面1〜3、単一ユースケース): T1/T2は各1ページ、手順5はチェックリストの★項目のみ
• M(画面4〜10、複数ロール): 全テンプレートをフル記入、チェックリスト全項目
• L(それ以上、外部連携あり): Mに加え、技術検証スパイクをSlice先頭に置き、リスクレビューを依頼者と実施
• 迷ったらMとして扱う

§3. 手順7: リリース後学習

1. リリース翌週に: 成功指標の実測値/性能実測/エラー率/想定と違った利用箇所を1枚のメモにする
2. 「作ったが使われていない機能」を特定し、削除または改善を提案する(機能を減らす提案は成果である)
3. 一般化できる学びは本スキルへの差分として人間に提案する

§4. 他の仕組みとの接続

• インフラ・デプロイ・セキュリティはプロジェクトの CLAUDE.md と本キット同梱のスキル(cloudflare / workers-best-practices / wrangler / cloudflare-secure-deploy / better-auth-google-gate / launch-security)のガードレールに従う(本スキルはその上のプロダクト層であり、これらのガードレールを上書きしない)
• 可視UIの既定適用は jp-web-design の references/catalog-default-contract.md を単一の正本とする。実際のDOM/component/layout/style/interaction差分で対象を判定し、詳細を本スキルへ複製しない。
• 非IT依頼者の場合: T1/T2の仮説を平易な日本語の「初稿カード」と操作可能なpreviewへ翻訳して見せる。空欄の質問票は渡さない。内部成果物としてはT1〜T4を作成する(テンプレートを差し替えたり省いたりはしない)。ただし記入の深度は §2 のサイズ判定に従う: T2は規模を問わず必須、T1/T3/T4はSなら該当欄だけの最小記入(T1は1ページ)、M/Lは全テンプレートをフル記入
• フィードバックは抽象質問ではなく成果物への差分として受け取る。質問が必要な場合も references/artifact-first-delivery.md の「本人しか決められない境界」だけに限定する