create-issue

create-issue

ユーザーの一行の意図を、grilling で固めてから issue として起票する skill。issue body は grilling で確定した内容から直接組み立てる。起票先と書き込み手段は実行時に解決する (「起票先を解決する」節)。

Symphony 系の運用へ乗せる前提で、起票先は Symphony の 1 系統と 1 対 1 に対応する。Symphony が次の poll で拾うことを期待する。

なぜ grilling を必須にするか

simple に見える issue ほど、未検証の前提が無駄な実装を生む。issue の Outcome / Why / 完了条件を曖昧なまま起票すると、Symphony が拾った後の実装ワーカーは推測で動く羽目になる。

grilling は設計判断を design tree として展開し、frontier (前提が揃った決定) が空になるまで質問ラウンドを回す。全ての分岐を訪れて暗黙の仮定が残っていない状態が、そのまま issue body の素材になる。

手順

1. grilling で意図を固める

Skill ツール経由で grilling を起動し、ユーザー の一行の意図を渡す。grilling は次を実施する。

• 意図を design tree へ展開し、前提が揃った決定の集合 (frontier) を洗い出す
• frontier の質問を 1 ラウンドにまとめ、番号付き・推奨案付きで提示してユーザー の回答を待つ
• 回答で tree を組み直し、frontier が空になるまでラウンドを繰り返す
• 環境から取れる事実 (関連ファイル / 先行事例 / 既存 issue) は sub-agent で自分で調べる。ユーザー へ聞くのは決定だけ

注意点:

• frontier が空になり、shared understanding に達したとユーザー が確認するまでステップ 2 へ進まない。grilling は確認前に動くことを禁じている
• 議論結果を design doc として別ファイルへ書き出さない。直接 issue description へ統合する

理由: bg session の作業 workspace は origin/main の depth=1 clone なので、scraps/open/ 等へ書いた新規ファイルを bg session 側から読めない。issue body だけが情報源になる前提で組む。

2. 起票先を解決する

起票先は Symphony の 1 系統 = 対象 repo。まず repo を決め、その repo の tracker を決める。

1. 会話の文脈から対象 repo が自明 (例: 「skills/X への変更」「daily note の cron が…」「unslop の rule 追加」) ならそれを採る。決められないなら AskUserQuestion で確定する
2. 対象 repo のローカル clone があれば WORKFLOW.md frontmatter の tracker.kind を読む。works repo のみ agents/ai-native/WORKFLOW.md、それ以外は repo root
3. clone が無い、または読み取れない場合は linear として扱う

以降、kind ごとに「Tracker 別操作」の手段を使う。

3. 重複を検索する

grilling で出てきたキーワード (1〜2 語) で既存 issue を検索する。検索は終端状態 (Done / Canceled) 以外をすべて対象にする。実装中や Human Review の issue と重なることがあり、状態を絞ると取りこぼす。

近い既存 issue が出た場合、新規作成せず該当の identifier と URL をユーザー へ報告して止まる。

4. description を組み立てる

grilling で確定した内容から、次の節構成へ落とす。

• ## Outcome — 最終状態と価値を箇条書きで 2〜4 点。手順は書かない
• ## Why — 起票の動機・前例との関係・設計の理由。bg session が edge case で判断するための背景情報
• ## 参考 — 参照した関連ファイル、関連 issue (実在のみ)、外部 URL。意図にある外部参照を必ず含める
• ## 完了条件 — 観測可能な状態 (コマンド出力、ファイル存在、tracker / GitHub の見え方) を箇条書き
• ## スコープ外 — 含めない範囲を箇条書き