アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
run-dev-graph-decompose
大きな自然文構想を feature・architecture・機能間依存へマクロ分解したいとき、ready feature の system-dev-planner package を atomic 登録・binding 別投影したいときに使う。
インストール方法を見る含まれるファイル(7)
- SKILL.md16.2 KB
- prompts/R1-elicit.md2.7 KB
- prompts/R2-plan.md2.9 KB
- prompts/R2b-feature-planning.md3.0 KB
- prompts/R3-decompose.md3.3 KB
- prompts/R4-project.md2.8 KB
- prompts/R6-dryrun.md2.5 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Pre-choice usable artifact execution
Purpose & Output Contractの最小の実成果物をmain contextで作成する。effect別のparse/open・secret・irreversible・corrupt guardだけを実行し、現物path・digest・開き方を提示してからaccept-as-is/light/standard/detailedを記録する。accept-as-isはその場でhandoff完了とし、後続sectionを実行しない。
Post-choice selected improvement execution
以下の既存workflow・goal-seek・評価・修正sectionはlight/standard/detailedが記録されてsemantic_evaluator_startedへ遷移した場合だけ実行する。release/exhaustiveは別の明示eventを必要とする。
run-dev-graph-decompose
Purpose & Output Contract
- 入力: 大きな want、feature 粒度/依存方針、C24/C11 検証済み graph context、任意の system-dev-planner package。
- 出力: feature/architecture/機能間 DAG の macro report、ready feature ごとの exact-13 package receipt、binding 別 publication report。
- 完了条件: macro DAG に phase-task 混入0、ready package が P01..P13 exact-set、自動/手動経路の二重登録0、dry-run write 0 である。
Hard boundary
dev-graph はマクロ層: purpose/goal/scope/acceptance を持つ feature、共有 architecture node、feature 間 depends_on を所有する。system-dev-planner はミクロ層: 1 feature から P01..P13 の13 task specs/DAG/package を所有する。本 skill が phase task を独自生成してはならない。
Macro flow
- 大きな want、feature 粒度、依存推定方針、dry-run を確認する。
- want を feature 候補と architecture context に分解し、各 feature に
purpose/goal/scope_in/scope_out/acceptance/architecture_refsを付ける。循環と実装粒度の task 混入を独立 auditor で拒否する。 - C02 preview/atomic writer で macro graph を登録する。draft/unconfirmed/readiness incomplete は tracker 投影しない。
- feature 間依存が満たされた ready feature ごとに
run-system-dev-planを Skill 呼出しする。--manual-plan//system-dev-plan結果も同じ package gate へ入れる。 - P01..P13 exact 13、共通 parent/package、13-node DAG、source digest を検証し、C02
register-packageへ渡す。graph_node_id+source_digestで自動/手動の二重登録を防ぐ。 beadsは C28 create/dep-add、githubはbuild-github-projection.py(gh 操作はすべて C12 gh-bridge 経由) で本文 markerdev-graph:<graph_node_id>を同一性とする Issue 一つと任意 Projects item 一つ、noneは local only。mode=both+auto、github+local_only、beads+GitHub Issue mutation は fail-closed。
local commit 後の外部失敗は rollback せず node/operation 単位 pending_retry とし、build-github-projection.py --retry-from <report> でその operation だけを再実行する。--dry-run は local/Beads/GitHub write 0。出力は macro report、per-feature package receipt、publication report。
ゴールシーク実行
ゴール (Goal)
自然文の「やりたいこと(大)」からfeatureノード群+architectureノード+機能間depends_onを生成するマクロ分解を行い、ready featureごとにsystem-dev-planner(ミクロ層)を自動起動または手動/system-dev-plan実行結果を受理してpromoted typed task群をparent_feature付きでC02へatomic登録し、binding=beadsはC28へissue/依存edge、binding=githubはC12へIssue/任意Projects、binding=noneはローカルのみへ冪等投影した状態になっている
目的・背景 (Why)
マクロ (feature/architecture/機能間依存の保持+実行オーケストレーション) とミクロ (1 feature→13タスク仕様書) の責務混線を避けるため、C14は自然文のwantをfeature+architecture+機能間depends_onへ分解するところまでを担い、feature単位の細タスク仕様書生成はexternal plugin system-dev-planner (external_contract_ref: plugin-plans/system-dev-planner/handoff-run-plugin-dev-plan.json) へ委譲する。ready feature (機能間depends_on充足) ごとに [自動] run-system-dev-planをSkill呼出しでpurpose/goal/scope_in/scope_out/acceptance/architecture_refsを入力文脈として渡し、[手動] 人間の/system-dev-plan実行結果も同じ入口として受理する。両経路が返すpromoted typed taskはgraph_node_id+source_digestを冪等キーにC02単一writer経由でparent_feature=当該featureとしてatomic登録し、二重登録を防ぐ。既存の「自然文とpromoted system taskの入口一本化」責務は維持し、tracker_binding_intentはC02がrepo-configと照合して解決し、mode=bothのautoは拒否する。beadsはC28 create/dep-add、githubはC12 Issue/Projects、noneはlocal graphだけへ投影する。GitHub binding+local_onlyは未管理taskを生むため拒否する
完了チェックリスト
- macro result が feature/architecture/機能間 depends_on だけを持ち循環と phase-task 混入が0件である
- draft/unconfirmed/evaluation非pass/readiness非complete の tracker publication が0件である
- 各 ready feature package が P01..P13 exact 13、共通 parent/package、13-node DAG を満たす
- C02 local commit が all-or-none で、自動/手動経路の重複 node が0件である
- beads/github/none の各 task が単一 projection authority と linkage を持つ
-
--dry-runの local/Beads/GitHub/Projects write count が0である
ゴールシークループ
frontmatter の goal_seek.engine: inline / fork: subagent / max_loops: 5 を実行契約とする。固定手順は使わず、未達 checklist と担当 prompts/*.md からその周回の操作を都度生成する。各周回で inner criterion を検証し、完了後は outer criterion の live trial/content review を最大 feedback_contract.max_iterations=3 周で評価する。
ゴールシーク配線
- 開始時に C24
resolve-repo-context.py --mode writeの JSON receipt を得て、repo_rootがcontent_roots.repositoryの realpath と一致する場合だけDEV_GRAPH_ROOT=<receipt.repo_root>に固定する。cwd から再解決しない。 - 元のゴールを
$DEV_GRAPH_ROOT/eval-log/run-dev-graph-decompose-goal-spec.jsonへ、各 checklist の status/evidence を$DEV_GRAPH_ROOT/eval-log/run-dev-graph-decompose-progress.jsonへ記録する。 - 未達 responsibility を担当する
prompts/<R-id>.mdを読み、Agentで分離 context に fork する。ユーザー判断が必要な境界だけAskUserQuestionを使う。 - 各周回末に
$DEV_GRAPH_ROOT/eval-log/run-dev-graph-decompose-intermediate.jsonlへoriginal_goal、original_goal_hash、current_goal_snapshot、delta_from_original、merged_directive_for_next、drift_signalを append-only で記録する。次周回は直前のmerged_directive_for_nextを必須入力にする。 - 5周到達時に未達が残れば完了扱いせず、progress と blocker を親へ handoff する。全 checklist と
feedback_contract.criteriaが PASS のときだけ完了する。
ゴールシーク検証
各周回後に次の検査を実行し、中間成果物の欠落・goal drift・hash 不一致を fail-closed にする。
python3 - "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-decompose-goal-spec.json" "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-decompose-intermediate.jsonl" <<'PY'
import hashlib, json, sys
goal = json.load(open(sys.argv[1], encoding='utf-8'))
rows = [json.loads(line) for line in open(sys.argv[2], encoding='utf-8') if line.strip()]
required_keys = {'original_goal','original_goal_hash','current_goal_snapshot','delta_from_original','merged_directive_for_next','drift_signal'}
expected = hashlib.sha256(goal['original_goal'].encode('utf-8')).hexdigest()
assert rows, 'intermediate.jsonl is empty'
for row in rows:
assert required_keys <= row.keys(), required_keys - row.keys()
assert row['original_goal'] == goal['original_goal']
assert row['original_goal_hash'] == expected
PY
Criteria acceptance
criteria:IN1:validate-graph-schema.pyで生成nodeを検証し必須キー欠落が0件である。criteria:OUT1:feature+architectureDAGは循環なし・task粒度混入なしで、評価前draftのIssue起票は0件、tracker投影はconfirmed/pass/readiness completeだけに限定する。criteria:OUT2: 同一入力を二回実行してもbinding=beadsはbd issue/blocks edge、binding=githubはIssue/Project item、binding=noneはlocal nodeを各一組だけ維持する。criteria:OUT3:--dry-runはlocal/Beads/GitHub/Projects write 0件である。criteria:OUT4:mode=both+auto、github+local_only、beads+Issue publicationの各authority衝突をfail-closedにし、外部write 0件にする。criteria:OUT5: local batch成功後の外部失敗は対象operationだけをpending_retryから冪等再実行する。criteria:OUT6: 同一ready featureの自動起動を重ねてもP01..P13 exact 13は一組だけで、全taskのparent_featureとfeature_package_idが一致する。criteria:OUT7: 自動経路と手動/system-dev-plan経路は同一parent featureへ収束し二重登録0件である。
Gotchas
- dev-graph は macro feature/DAG だけを作り、P01..P13 task spec 生成を再実装しない。
- draft/unconfirmed/readiness incomplete の feature/task を tracker へ投影しない。
- 自動と手動の planner 結果を別 gate にせず、同じ
graph_node_id+source_digestの冪等キーへ収束させる。 - local commit 後の外部失敗で macro graph を rollback せず、失敗 operation だけを
pending_retryに残す。 mode=both+auto、github+local_only、beads+Issue mutationは authority 衝突として fail-closed にする。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。