mission-specify について
mission-specifyは、ミッション駆動型ソフトウェア開発の仕様策定スキルです。brief.mdを測定可能な受け入れ基準に変換し、判断内容を記録します。計画と実装は後続のスキルが担当します。
主な機能
- 01成功基準を二値の成果に変換
- 02追跡可能なspec.mdの受け入れ基準を作成
- 03測定不能な基準や矛盾を提示
- 04明確化の判断を記録
- 05共有エグゼキューター契約に準拠
活用シーン
- 01プロジェクト概要をテスト可能な仕様に変換
- 02曖昧または矛盾する要件を解決
- 03ミッションワークフローで仕様策定と明確化を実行
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ tikalk/ adlc-team-skills --skill mission-specifyインストール後、Claude Code で/mission-specifyを入力して読み込まれたか確認します。
詳細
mission-specify
必要条件: .agents/skills/factory-mission/references/executor.md(インストール先のパス)にある factory-mission スキルの共有エグゼキューター契約。adlc-cli skills add tikalk/adlc-team-skills --skill factory-mission でインストールしてください。
ローカルセッション — ゲートへの回答はあなたが行います
ADLC_RUN_ID が設定されておらず、このセッションに人が参加していて、ゲートに回答する人がほかにいない場合です。ゲートを Slack に中継する agentic-container ランタイムが存在するのは、ランナーポッド内だけです。
- 一時停止中の実行は、ミッションの終了ではなく、あなたの番です。
adlc-cli workflow runまたはresumeが、ゲートで一時停止した状態で終了した場合(adlc-cli workflow state show <run_id>でrun_paused、status: paused)、ゲートの質問と選択肢を人に尋ねてください。その後、adlc-cli workflow resume <run_id> --input <verdict_input>=<answer>を実行して続行してください。誰にも質問せず、一時停止中の実行であなたのターンを終えてはいけません。 - MR を承認するすべてのゲートの後には、MR を開くステップを続けます。 MR/PR を約束するメッセージのある
gateの後にはpublishステップを置きます。変更が及ぶリポジトリごとにrun-branch.shとopen-mr.shを実行し、mr_url(複数の場合はmr_urls)を書き込みます。その後にのみ書き戻しのステップを置き、完了コメントから実際の MR にリンクできるようにします。回答を受けても後続のアクションがないゲートは、計画の不備です。実行を開始する前に計画を修正してください。 - ターンを終える前に、実行が
completed、failed、または中断済みになっているか、もしくは人に確認を求めたゲートで一時停止している状態にしてください。
このスキルの役割
mission-specify は、ミッション SDD ファミリーの仕様策定フェーズを担います。ミッションの brief.md を、各受け入れ基準を「はい」または「いいえ」で判定できる spec.md に変換し、その過程で行った決定を記録します。共有エグゼキューター契約(.agents/skills/factory-mission/references/executor.md)に従って動作します。specify ステップは brief.md を読み取りドラフトを出力し、clarify ステップは spec.md を読み取って決定を出力します。reads_from はオーケストレーターによって解決されます。このスキルは仕様の段階で終了します。計画は mission-plan、構築は mission-implement、検証と収束は mission-verify、REVIEW と SHIP は factory-review と factory-deploy の担当です。
デフォルトの進め方
brief.mdを読みます。目標、制約、対象外事項、成功基準を入力として扱い、元の表現を維持する必要はありません。- すべての成功基準を、二値で測定可能な成果として言い換えます。それぞれ、終了コードを返すコマンド、存在するアーティファクト、または変更を示す差分によって、「はい」か「いいえ」で回答できるものにします。
spec.mdに、成果、制約、対象外事項、受け入れ基準、スコープ外の内容を記述します。各受け入れ基準が、言い換え元の成功基準を追跡できる状態を保ちます。- 測定できない基準と、互いに矛盾する制約を明らかにし、文章で曖昧にごまかしてはいけません。
- 明らかにした各項目を明確化フェーズで解決します。ゲート付きの実行では人に尋ね、自律モードでは根拠とともに決定を記録します。その決定が
clarifyの出力です。 - 技術を選定したり、ファイルを計画したりしてはいけません。それらは後続のフェーズで行います。
ステップの契約
| ステップ | phase_type | output_type | reads_from | artifact |
|---|---|---|---|---|
specify | generate | draft | brief.md | spec.md |
clarify | clarify | decision | spec.md | — |
ゲート
このフェーズにゲートはありません。
境界
- ワークツリーは扱いません。分離はオーケストレーターの担当です。このスキルは、渡されたツリー内で作業します。
- リースは扱いません。実行リースの取得、更新、解放は行いません。
- トラッカーへの書き込みは行いません。コメント、ラベル、ステータス遷移、MR/PR の作成は行いません。
- マージや承認は行いません。このスキルが承認、マージ、出荷することはありません。
- 差し戻し先:測定不能な基準や矛盾する制約は、解決するまで clarify に留めます。後になって仕様が誤りだと判明した場合は、下流で受け入れ基準を黙って編集するのではなく、担当する clarify フェーズで修正します。