specifying-gates

ユーザー指定ゲートの仕様策定

このスキルが実行される条件

次のいずれかに該当する場合です。

1. ユーザーゲートタスクの json:metadata フェンスに "requiresUserSpecification": true がある場合、または
2. エージェントが「HOW がわかっているか？」のセルフチェック（executing-plans を参照）を実行し、検証の仕組みが曖昧だと判断した場合、または
3. ユーザーが /specify-gate <task-id> を手動で実行した場合。

それ以外の場合、つまり verifyCommand が具体的で、すべての acceptanceCriteria に確認可能な証拠がある場合は、エージェントがゲートを直接実行し、このスキルは呼び出しません。

開始時に告知します：「Task N の検証方法を確定するため、specifying-gates スキルを使用します。」

重要 — このスキルが行わないこと

• 検証コマンドは実行しません。仕様策定のみを行います。
• タスクを完了にはしません。メタデータを補足するだけです。その後、エージェントは executing-plans に戻ります。
• ブレインストーミングをやり直しません。設計はすでに決定済みで、未確定なのは1つのゲートの実行方法だけです。

入力

対象タスク ID。コマンド引数、または現在進行中のユーザーゲートタスクから解決します。

TaskGet でタスクを読み込み、その説明から json:metadata フェンスを解析します。

4つの質問

ブレインストーミングスキルのルールに従い、AskUserQuestion を使って一度に1つずつ質問します。

Q1 — 確認可能な結果

AskUserQuestion:
  question: "Gate: <task subject>. What exact state proves this works? One line per criterion. 'It works' is not an answer — name a sensor, HTTP status, log line, file presence, or equivalent."
  header: "Gate outcome"
  options:
    - label: "I'll type the criteria"
      description: "Write 1-5 concrete, observable conditions"
    - label: "Copy from task's acceptanceCriteria"
      description: "Use the existing list (only if it's already concrete)"

ユーザーの自由記述の回答を、acceptanceCriteria に文字列のリストとして保存します。項目が曖昧な場合（具体的な対象を示さずに「動く」「問題ない」「期待どおり」「適切に」などを含む場合）は、確認可能な内容を明示するよう求めます。

Q2 — 証明方法

AskUserQuestion:
  question: "How should the agent capture that state?"
  header: "Mechanism"
  options:
    - label: "CLI command"
      description: "A shell command whose output shows the criterion"
    - label: "REST / API call"
      description: "HTTP request, inspect response"
    - label: "Subagent with briefing"
      description: "Dispatch Sonnet or Haiku with a prompt template"
    - label: "Direct inspection"
      description: "Read a file, query an entity, check a log"

「Subagent with briefing」の場合は、続行する前に Q5（ディスパッチ契約）を質問します。

ユーザーが依頼内容ですでにライブフィクスチャを指定している場合、「ドライトレース」による証明方法は提示しません。ライブコマンドのみを verifyCommand として記録します。仕様策定は決定を確定させるものであり、ユーザーがすでに下した決定を再び検討するものではありません。

Q3 — 対象範囲

AskUserQuestion:
  question: "Run this once, or over multiple targets?"
  header: "Scope"
  options:
    - label: "Once"
      description: "Single execution, single target"
    - label: "Per instance / target"
      description: "Run identically across a list (e.g. all environments)"
    - label: "First on one, then on all"
      description: "Prove it on one target, then roll out to the rest — the classic two-gate pattern"
    - label: "Custom"
      description: "Describe the rule in free text"

gateScope として "once" | "per-target" | "one-then-all" | カスタム文字列を保存します。

Q4 — 失敗時の方針

AskUserQuestion:
  question: "If the gate fails, what happens?"
  header: "On failure"
  options:
    - label: "Stop the plan (Recommended)"
      description: "No further tasks until this gate passes"
    - label: "Reopen this task, continue others"
      description: "Mark in_progress, keep the plan moving elsewhere"
    - label: "Log and continue"
      description: "Record failure, proceed — use only for informational gates"

failurePolicy として "stop-plan" | "reopen-continue" | "log-continue" を保存します。

Q5（条件付き）— サブエージェントのディスパッチ契約

Q2 が「Subagent with briefing」の場合のみ質問します。

AskUserQuestion:
  question: "Paste the exact prompt / briefing the subagent should receive. This becomes the dispatch contract — the agent cannot substitute a shorter version at runtime."
  header: "Dispatch brief"
  options:
    - label: "I'll paste it"
      description: "Provide the briefing text"
    - label: "Use instances/<tag>/seed-briefing.md"
      description: "Per-target briefing file already written by a plan task"
    - label: "Generate from task description"
      description: "Build the briefing from the task's Goal + Files + Acceptance Criteria"

subagentBrief（文字列またはファイルパス）として保存します。

書き戻し

すべての質問に回答した後：

1. タスクの説明を更新します。 新しいフィールドを含めて json:metadata フェンスを書き換えます。requiresUserSpecification を削除します。それ以外はすべて保持します。完全な新しい説明を指定して TaskUpdate を呼び出します。

{
  "files": [...],
  "verifyCommand": "<from Q2 — the CLI/API string, or '(subagent)' sentinel>",
  "acceptanceCriteria": ["<from Q1>", ...],
  "userGate": true,
  "tags": ["user-gate"],
  "gateScope": "<from Q3>",
  "failurePolicy": "<from Q4>",
  "subagentBrief": "<from Q5 if applicable>"
}

2. 「Specification」セクションを追加します。 タスク説明の人間向け部分で、json:metadata フェンスの上に追加します。

### Specification (via /specify-gate on <ISO-date>)

- **Outcome:** <Q1>
- **Mechanism:** <Q2>
- **Scope:** <Q3>
- **Failure policy:** <Q4>
- **Subagent brief:** <Q5 if applicable>

3. .tasks.json と同期します。 タスク項目の説明とメタデータを更新し、lastUpdated を設定します。

4. 告知します：「仕様が確定しました。ゲートを実行するため、制御を executing-plans に戻します。」

引き継ぎ

制御は executing-plans に戻ります。エージェントは更新されたタスクを読み込み、verifyCommand を実行する（または subagentBrief を使ってサブエージェントをディスパッチする）とともに、出力を記録します。完了とする前に、各基準について AC: <criterion> — PROVEN BY <evidence> を投稿します。

このスキルで行ってはいけないこと

• ExitPlanMode または EnterPlanMode を呼び出さないでください。
• 検証を開始しないでください。このスキルの終了後、executing-plans に戻ってから検証を実行します。
• 質問は4〜5個を超えないでください。回答が不十分だと感じる場合は、最初の一連の質問に質問を追加するより、1つだけ追加質問をして再確認してください。
• タスクの説明と .tasks.json 以外のファイルに書き込まないでください。サイドファイルは作成しません。

統合

• 呼び出し元： executing-plans（自動）、/specify-gate スラッシュコマンド（手動）。
• 戻り先： executing-plans。
• 参照先： メタデータスキーマについては skills/shared/task-format-reference.md。