app-excellence git:20261002.c0e127dA

Immutable. This exact content never changes and is served at /api/v1/blob/71ed7c032c366256.

---
name: app-excellence
description: アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
---

# 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` の「本人しか決められない境界」だけに限定する