mcpField
M
mission-specify

mission-specify

github.com/tikalkその他1449 回インストール今日更新
リポジトリ

mission-specify について

mission-specifyは、ミッション駆動型ソフトウェア開発の仕様策定スキルです。brief.mdを測定可能な受け入れ基準に変換し、判断内容を記録します。計画と実装は後続のスキルが担当します。

主な機能

  1. 01成功基準を二値の成果に変換
  2. 02追跡可能なspec.mdの受け入れ基準を作成
  3. 03測定不能な基準や矛盾を提示
  4. 04明確化の判断を記録
  5. 05共有エグゼキューター契約に準拠

活用シーン

  1. 01プロジェクト概要をテスト可能な仕様に変換
  2. 02曖昧または矛盾する要件を解決
  3. 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 ランタイムが存在するのは、ランナーポッド内だけです。

  1. 一時停止中の実行は、ミッションの終了ではなく、あなたの番です。 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> を実行して続行してください。誰にも質問せず、一時停止中の実行であなたのターンを終えてはいけません。
  2. MR を承認するすべてのゲートの後には、MR を開くステップを続けます。 MR/PR を約束するメッセージのある gate の後には publish ステップを置きます。変更が及ぶリポジトリごとに run-branch.sh と open-mr.sh を実行し、mr_url(複数の場合は mr_urls)を書き込みます。その後にのみ書き戻しのステップを置き、完了コメントから実際の MR にリンクできるようにします。回答を受けても後続のアクションがないゲートは、計画の不備です。実行を開始する前に計画を修正してください。
  3. ターンを終える前に、実行が 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 の担当です。

デフォルトの進め方

  1. brief.md を読みます。目標、制約、対象外事項、成功基準を入力として扱い、元の表現を維持する必要はありません。
  2. すべての成功基準を、二値で測定可能な成果として言い換えます。それぞれ、終了コードを返すコマンド、存在するアーティファクト、または変更を示す差分によって、「はい」か「いいえ」で回答できるものにします。
  3. spec.md に、成果、制約、対象外事項、受け入れ基準、スコープ外の内容を記述します。各受け入れ基準が、言い換え元の成功基準を追跡できる状態を保ちます。
  4. 測定できない基準と、互いに矛盾する制約を明らかにし、文章で曖昧にごまかしてはいけません。
  5. 明らかにした各項目を明確化フェーズで解決します。ゲート付きの実行では人に尋ね、自律モードでは根拠とともに決定を記録します。その決定が clarify の出力です。
  6. 技術を選定したり、ファイルを計画したりしてはいけません。それらは後続のフェーズで行います。

ステップの契約

ステップphase_typeoutput_typereads_fromartifact
specifygeneratedraftbrief.mdspec.md
clarifyclarifydecisionspec.md—

ゲート

このフェーズにゲートはありません。

境界

  • ワークツリーは扱いません。分離はオーケストレーターの担当です。このスキルは、渡されたツリー内で作業します。
  • リースは扱いません。実行リースの取得、更新、解放は行いません。
  • トラッカーへの書き込みは行いません。コメント、ラベル、ステータス遷移、MR/PR の作成は行いません。
  • マージや承認は行いません。このスキルが承認、マージ、出荷することはありません。
  • 差し戻し先:測定不能な基準や矛盾する制約は、解決するまで clarify に留めます。後になって仕様が誤りだと判明した場合は、下流で受け入れ基準を黙って編集するのではなく、担当する clarify フェーズで修正します。

コメント