無料GitHub で公開

app-excellence

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

daishiman/harness-dev

インストール方法を見る

含まれるファイル（19）

SKILL.md8.2 KB
assets/T1-requirements.md1.8 KB
assets/T2-experience-spec.md5.7 KB
assets/T3-feature-map.md1.5 KB
assets/T4-release-readiness.md2.0 KB
references/01-requirements.md4.7 KB
references/02-experience-design.md6.7 KB
references/03-feature-decomposition.md5.4 KB
references/04-build-standards.md4.5 KB
references/05-quality-gates.md5.3 KB
references/artifact-first-delivery.md8.4 KB
references/checklists/accessibility-jp.md1.5 KB
references/checklists/package-lock.json1.6 KB
references/checklists/package.json59 B
references/checklists/performance.md1.3 KB
references/checklists/risk.md1.7 KB
references/checklists/ux-psychology.md1.9 KB
references/data-lifecycle.md6.9 KB
scripts/check-artifact-first-contract.mjs8.9 KB

SKILL.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. 判断の最上位ルール(常時適用)

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

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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

app-orchestrator

無料日本語概要

Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。