アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
run-dev-graph-schedule
feature ready と task ready を分離したいとき、依存・tracker parity・resource scope・active lease を満たす conflict-free batch を算出したいときに使う。
インストール方法を見る含まれるファイル(4)
- SKILL.md11.0 KB
- prompts/R1-elicit.md2.5 KB
- prompts/R2-plan.md2.4 KB
- prompts/R3-schedule.md2.9 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-schedule
Purpose & Output Contract
- 入力: C24/C11 検証済み subgraph、binding parity、C27 lease snapshot、max parallel。
- 出力: strict ready sets、resource-safe parallel batches、conflict pairs、
devgraph/<graph_node_id>branch/claim command。 - 完了条件: 全推薦が confirmed/pass/readiness complete、全 dependency done、lease/resource conflict 0 を同時に満たす。
- 対象 subgraph と max parallel を確定する。
- beads binding は C28 の
readyと status/depends_on exact-set parity=confirmed の積集合だけを採用する。github/none は local graph から算出する。 - confirmed/pass/readiness complete、全依存 done、active lease なしだけを候補にする。
- feature ready は system-dev-planner 起動候補、task ready は実行候補として別 batch にする。両者を同じ batch に混ぜない。
schedule-graph.pyの resource_scope conflict と C27 lease snapshot を重ね、同じ resource を触る組を分離する。C17 独立 verifier が不一致を出したら推薦しない。
出力は ready sets、parallel batches、conflict pairs、各 task の devgraph/<graph_node_id> branch と dev-graph worktree claim <id> command。read-only で graph/tracker/lease を変更しない。
ゴールシーク実行
ゴール (Goal)
グラフの依存関係・完了状態・active worktree leaseから次に着手すべきready-setと、リソーススコープ/lease重複のない複数worktree向け並列バッチを算出・提示した状態になっている
目的・背景 (Why)
依存関係を都度人手で追跡せずに次の一手を判断できるようにする。binding=beadsはC28でstatusとdepends_on edge exact-set parityがconfirmedの場合だけbd ready候補を採用し、parity pending/conflictは推薦しない。その候補へdev-graph固有のresource_scope/lease重複回避を重ねる。github/noneはC16で自前算出し、mode=bothはbinding別結果を合成する。二層ready-set: feature ready (機能間depends_on充足) はper-feature planning起動候補、task ready (feature内depends_on充足+resource_scope非競合) は実行候補として区別し、feature単位の並列batchとtask単位の並列batchを混在させない (MM-10)
完了チェックリスト
- candidate は confirmed/pass/readiness complete、全 depends_on done、active lease なしを満たす
- feature ready と task ready が別々の ready-set/batch に出力される
- 同一 parallel batch の resource_scope.touches 重複 pair が0件である
- 各 task の suggested_branch が
devgraph/<graph_node_id>で claim command が public CLI 形式である - 実行前後の graph/tracker/lease digest が同一である
ゴールシークループ
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 readの JSON receipt を得て、repo_rootがcontent_roots.repositoryの realpath と一致する場合だけDEV_GRAPH_ROOT=<receipt.repo_root>に固定する。cwd から再解決しない。 - 元のゴールを
$DEV_GRAPH_ROOT/eval-log/run-dev-graph-schedule-goal-spec.jsonへ、各 checklist の status/evidence を$DEV_GRAPH_ROOT/eval-log/run-dev-graph-schedule-progress.jsonへ記録する。 - 未達 responsibility を担当する
prompts/<R-id>.mdを読み、Agentで分離 context に fork する。ユーザー判断が必要な境界だけAskUserQuestionを使う。 - 各周回末に
$DEV_GRAPH_ROOT/eval-log/run-dev-graph-schedule-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-schedule-goal-spec.json" "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-schedule-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:schedule-graph.pyの ready-set に blocked/draft/unconfirmed/evaluation非pass/readiness非complete の候補が 0件であることを script test で検証する。criteria:OUT1: 推薦 task は全depends_onがdoneで、未充足依存を持つ候補が ready-set に0件であることを受入テストで検証する。criteria:OUT2: 同一parallel batch内のresource_scope.touches重複ペアが0件で、active leaseと衝突する候補を推薦しないことを受入テストで検証する。criteria:OUT3: ready taskごとに一意なsuggested_branch=devgraph/<graph_node_id>とdev-graph worktree claim <id>commandを返し、C27が同一graph_node_idの二重claimを0件に抑止することを受入テストで検証する。
Gotchas
blocked/draft/unconfirmed/evaluation!=pass/readiness!=completeのどれかを ready に混入させない。- 直接依存だけでなく全
depends_onの done を確認する。 - 同一 batch の
resource_scope.touchesと active lease の両方を衝突判定に使う。 - feature planning 候補と task 実行候補を同一 batch に混ぜない。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。