grilling の対話で job-graph 向けの計画（tmp-agents/<job>/plan.md と job-graph/spec.json）を確定し、任意で GitHub の epic / sub-issue へ出す上流スキル。`/job-plan` の明示実行専用。
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
job-graph は「計画ファイル → spec.json → レーン起動 → 手放し監視」を担うが、手放し運用の成否は 計画の完成度で決まる。依存辺・境界・期待ファイルが曖昧だと job-graph は Phase 0 で問いを立てて 止まり、完了条件が曖昧だとワーカーが勝手に終了判断する。job-plan はその上流で、 grilling による対話で計画を閉じ、job-graph がそのまま消費できる 2 ファイルを確定させる:
tmp-agents/<job>/plan.md（6 章固定。ワーカーの /review-converge が ground truth として読む）tmp-agents/<job>/job-graph/spec.json（plan が plan.md を指す。job-graph の計画突合の材料）外部書き込み（GitHub issue）を含み得るため disable-model-invocation: true。/job-plan の明示実行
時のみ動く。以下、スキル本体のパスを <SKILL> と表記する。
Skill("grilling") に委ね、本スキルは brief と「閉じるまで終われない項目」を固定するだけ
（references/grilling-brief.md）。フロンティアが空になるまで成果物を書かない。--issue が無ければ AskUserQuestion で問い、
既定はローカルのみ。起票前に本文を提示して承認を取る（external-writes 準拠）。check_plan_spec.py（plan ↔ spec 整合）と job-graph の
plan_orchestration.py（循環・base・plan 実在）が両方通るまで終わらない。FAIL は該当項目だけ
grilling へ戻す（全体をやり直さない）。/job-graph tmp-agents/<job>/plan.md を提示して終わる。
HERDR_ENV は本スキルには不要。Python プロジェクト（pyproject.toml + uv.lock、依存なし）。実行は
UV_PROJECT_ENVIRONMENT="$HOME/.cache/uv-venvs/job-plan" uv run --project "<SKILL>" python "<SKILL>/scripts/<script>.py"。
check_plan_spec.py <plan.md> <spec.json>（stdlib のみ）: 第 3 章の固定小見出しと spec の task を
突合し VERDICT: PASS|FAIL を出す。job-graph の Phase 0 も同じスクリプトを兄弟パスで呼ぶcreate_issues.py --plan … --spec … [--epic N] [--sync]: epic / sub-issue の起票・spec への
issue 書き戻し・plan.md 第 6 章への URL 追記・改訂同期。gh auth status を先に検査する引数を解釈する（--issue は末尾フラグとして分離）:
| 引数 | 入力 | 読み方 |
|---|---|---|
| 対象名・自由記述 | ユーザーの依頼 | <job> 名をこの語彙から提案する |
docs/dev/<対象>/spec.md 等のパス | feature-spec の成果物 | REQ-# を全て拾い、task へ引き継ぐ |
| 数字 | GitHub issue | gh issue view <N> --json title,body と gh api repos/{owner}/{repo}/issues/<N>/sub_issues で本文と既存 sub-issue を読む。sub-issue はタスク候補 |
tmp-agents/<job>/ が既にあれば 改訂か別名かを AskUserQuestion で問う（推奨 = 改訂）。改訂なら
既存 plan.md / spec.json を読み、差分だけを grilling する（既存 task の issue 番号は保つ）。
Skill("grilling") を、references/grilling-brief.md の雛形で組んだ brief 付きで呼ぶ。brief には
「閉じるまで終われない項目」10 個（<job> 名 / 分割・branch・依存 / boundary / expected_files・scale /
完了条件 / コミット計画 / 事前裁定 / スコープ外 / REQ-# 対応 / 既存 sub-issue の振り分け）を必ず載せる。
references/handoff.md と同じcommit-plan スキル準拠（task = ブランチ単位）tmp-agents/<job>/plan.md を references/plan-template.md の 6 章で書く。第 3 章の小見出し
（branch / 依存 / 完了条件 / 変更対象 / 規模目安 / 境界 / コミット計画）は固定文法。崩すと
check_plan_spec.py が偽 FAIL を出すtmp-agents/<job>/job-graph/spec.json を references/plan-spec-mapping.md の対応表で書く
（plan は tmp-agents/<job>/plan.md、prompt は組み立て規則どおり）check_plan_spec.py → VERDICT: PASS。FAIL の ERROR 行は task 単位で直す。WARNING（第 5 章が空・
REQ-# の孤児）は該当項目だけ grilling へ戻すplan_orchestration.py（--prompt-dir なし）→ ERROR なし。SCHEDULE の wave が第 2 章の見込みと
合うことを目視する改訂のときも同じ手順。既存 task の spec を書き換えない限り issue は保たれる。
--issue があれば問わずに進む。無ければ AskUserQuestion で「ローカルのみ（推奨）/ GitHub issue にも
出す」を問う。本文にも選択肢を書く（remote-control で選択 UI 前の文脈が見えない対策）。
AskUserQuestion が deny されていれば番号付きで列挙して回答を求めるcreate_issues.py（入力が issue 番号なら --epic <番号>）。手順・失敗時の
再実行・改訂時の --sync は references/plan-spec-mapping.mdgh auth status が通らなければスクリプトは何も作らず exit 2。その旨を伝えてローカル成果物だけで
終える（issue は後から同じコマンドで出せる）次を提示して終わる（自動連鎖しない）:
/job-graph tmp-agents/<job>/plan.md
併せて伝える: 親・レーンは既定の auto のままでよく、レーンへ bypassPermissions / dontAsk は渡さないこと
（理由は job-graph Phase 1 末尾の注意）、issue を出したなら epic の URL、改訂なら変更した task の一覧。
このスキルは下記を呼び出す側で、内容を重複させない。
grilling（Phase B の対話そのもの）/ commit-plan（コミット計画の様式）/ external-writes
（Phase D の承認）/ job-graph（引き渡し先。spec の意味は job-graph references/spec.md、依存・境界の
判定基準は references/dependency-analysis.md）/ lane-ops（事前裁定の判定基準表）references/: grilling-brief.md（brief 雛形・閉じる項目・調査ラウンド）/ plan-template.md
（plan.md の 6 章と第 3 章の固定文法）/ plan-spec-mapping.md（plan → spec の対応表、末尾ゲートと
issue 起票・改訂同期のコマンド）No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
The English summary is being prepared. Showing the original description.
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
The English summary is being prepared. Showing the original description.
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
The English summary is being prepared. Showing the original description.
`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。plan モードでのコミット計画の立案は commit-plan スキルの領分。
The English summary is being prepared. Showing the original description.
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。
The English summary is being prepared. Showing the original description.
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。
The English summary is being prepared. Showing the original description.