dev-pipeline

Dev Pipeline

既存のスキルを再利用して、機能のライフサイクルをオーケストレーションします。ここでは各フェーズを実装しません。現在の状態を特定し、判断ルールを適用し、自分の担当を実行して、次のフェーズでユーザーが実行する正確なコマンドを伝えます。

Issue トラッカーとトリアージラベルの語彙が提供されている必要があります。そうでない場合は、/setup-leandrocfe-skills を実行してください。

ユーザーが起動するスキル（to-spec、to-tickets、wayfinder、triage、implement、handoff）を実行するのはユーザーだけです。あなたの役割は、いつ、なぜ実行するのかを伝えることです。モデルが起動するスキル（grilling、tdd、code-review）は、適切なフェーズであなたが直接呼び出します。

1. 状態を特定する

何かを提案する前に、作業がどのフェーズにあるかを把握してください。質問するのではなく、調べてください。

• ユーザーの説明が新しいアイデアを示している？ → 規模の見積もりフェーズ。
• トラッカーに spec があり、派生チケットがない？ → 分解フェーズ。
• brief／トリアージラベルのない未完了の issue がある？ → トリアージフェーズ。
• brief が付いた対応可能な issue があり、ブランチがない？ → ディスパッチフェーズ。
• 進行中のブランチがある？ → 実装またはレビューのフェーズ（差分を確認）。

検出したフェーズを一文で伝え、そこから進めてください。進行中の作業がある場合は、パイプラインを最初からやり直してはいけません。

2. 規模を見積もる（フェーズ 0）

新機能は、まず規模を見積もります。次の 4 つの結果が考えられます。

規模	基準	進め方
軽微	約 1 時間未満、1～2 ファイル、曖昧さなし	成果物は不要です。このセッションで直接実装します（リポジトリが PR を使う場合は、ブランチを作成して PR を作成します）。
小規模	1 セッション・1 PR で完了し、スコープが明確	spec は不要です。短い spec を作成し（トラッカーに単独の issue を作成するか、トラッカーがローカルの Markdown なら .md を作成）、そのまま実装に進みます。
中規模／大規模	1 セッションを超える、または並行するエージェントが 1 つを超える、またはスコープに実質的な曖昧さがある	完全なパイプライン（セクション 3）。
巨大／先が見えない	目的地までの道筋がまだ見えていない。グリーンフィールドであるか、1 回のセッションで計画するには機能が大きすぎる	「/wayfinder を実行してください」と伝えて、道筋を描き、曖昧さを解消して意思決定につなげます。道筋が明確になったら、/to-spec からパイプラインに再合流します。

基本ルール：作業が 1 セッションを超える、または並行するエージェントが 1 つを超える場合は、トラッカーに issue を作成します。それ以外は、できるだけ最小限にします。 小規模か中規模か迷ったら、ユーザーに質問を 1 つだけしてください。用心のためにスコープを膨らませてはいけません。

wayfinder に進む基準は規模ではなく、見通しです。何を構築するかを説明できるなら、どれほど大きくても完全なパイプラインに進みます。まず何を決めるべきか分からないなら、wayfinder に進みます。

3. 完全なパイプライン（中規模／大規模）

各フェーズはゲートで終了します。成果物を作成し、ユーザーがレビューした後、次に実行するコマンドを伝えます。

フェーズ	実行者	成果物	ゲート — 次のステップ
明確化	あなた（grilling スキル経由で直接呼び出します）	会話を通じて共有された理解	「/to-spec を実行して内容をまとめてください」
仕様策定	ユーザー：/to-spec	トラッカー上の簡潔な spec	「spec に対して /to-tickets を実行してください」
分解	ユーザー：/to-tickets	各チケットにブロッキング関係を付けた垂直スライス形式のチケット	「/triage を実行して分類し、brief を作成してください」
トリアージ＋ルーティング	ユーザー：/triage。トリアージ中に、あなたがセクション 4 の表を適用します	brief と agent:* ラベルが付いた issue	「issue #N に対して /implement を実行してください」（最初に対応する frontier、つまり未解決のブロッカーがない issue を指定します）
実装	ユーザー：/implement。合意済みのシームでは tdd を使用します	ブランチ＋コミット＋PR	code-review を呼び出します
レビュー	あなた（code-review スキル経由で直接呼び出します）	2 つの軸（標準＋仕様）で整理した差分の指摘	承認 → マージ。問題あり → 実装に戻ります。
続行	—	—	同じセッションで続ける場合は、次のチケットに進みます。新しいセッションの場合は「/handoff を実行してください」と伝えます。完了時は spec を閉じます。

4. エージェントのルーティングとランタイム

2つの独立した軸をトリアージで決定し、issue に2つのラベルとして記録します。

軸1 — ロール。 次の3つの質問を順番に確認し、最初に「はい」と答えたものを採用します。

1. 未決定の設計判断やトレードオフがありますか？ → agent:architect
2. 進め方は決まっていますが、判断が必要ですか？ → agent:builder
3. 曖昧さのない機械的な作業ですか？ → agent:runner

Advisor はコードを書く前（精査、スコープ設定）だけ、Reviewer はコードを書いた後（レビュー段階）だけに担当します。

軸2 — ランタイム。 実行に使用するツール／モデルです。デフォルトの表（セットアップに応じて調整してください。ロール→デフォルトランタイムの対応はここに、例外はラベルに記録します）：

ロール	デフォルトのランタイム	理由
agent:architect	Claude Code、最上位モデル	深い推論、トレードオフ
agent:builder	Claude Code の中位モデル、または Codex	標準的な実装
agent:runner	利用可能な中で最速／最安のもの（Codex mini、Grok fast、Haiku）	機械的な作業、大量処理

デフォルトから外れる場合のみ runtime:* ラベルを付けます（例：architect に runtime:codex）。レビューのルール：可能な限り、作成者とレビュアーには異なるランタイム／ベンダーを使います。クロスモデルレビューのほうが、自己レビューより多くの不具合を見つけられます。

ラベルは issue に付けるため、ディスパッチ時に判断をやり直す必要はありません。

ランタイム間のディスパッチ

自己完結した brief がインターフェースとなるため、どの CLI でも追加のコンテキストなしで issue を処理できます。方法は2つあります。

• 手動：ユーザーが issue の worktree で、ラベルに指定されたランタイムを起動し、brief を参照させます（gh issue view N）。
• ヘッドレス：オーケストレーションセッションがシェル経由でディスパッチします。例：worktree 内で codex exec --full-auto "implemente a issue #N; brief em: gh issue view N" を実行します。他の CLI でも同様です。オーケストレーターはディスパッチと結果の収集だけを行い、worker と並行して実装することはありません。

どちらの方法でも、結果は同じ経路で戻ります。つまり、issue を参照するブランチと PR です。パイプラインは、どのランタイムが差分を作成したかを知る必要もありません。

5. コンテキストと並列処理

エージェントはステートレス、成果物はステートフル。 コンテキストを会話のメモリーに残すことはありません。

• issue の brief は自己完結しています。issue を担当するエージェントに追加情報は必要ありません。別のエージェントのために作業を準備する場合は、brief を記述します。
• spec には理由を記載し、issue からリンクします。
• PR の説明には、レビュー用に実施内容を記載します。
• /handoff を使うのは、issue の作業が途中で中断された場合だけです。brief の代わりには決して使いません。

競合を避けた並列処理：

• issue 1件につき、ブランチ1つ、エージェント1つです。ローカルで並列に進める場合は git worktrees を使います。
• brief には issue が変更するファイルを列挙します。変更ファイルが重複する issue を並列でディスパッチしないでください。
• 依存関係は /to-tickets がすでに記録した ブロッキングエッジです。対応しているトラッカーではネイティブ機能を使い、対応していない場合は本文に記載します。ブロッカーがすべてクローズ済みのチケットだけをディスパッチしてください。

6. Git

• ブランチ：feat/<n>-slug-curto（名前に issue 番号を含めます）。
• Conventional commits を使用し、PR の本文に Closes #N を記載します。
• PR は小さく保ちます（目安：一度でレビューできる規模）。段階的にマージします。

アンチパターン

• 小さな作業のために spec を作成しないでください。規模の見積もりはそのためにあります。
• トラッカーが設定済みの場合、ばらばらの .md ファイルに spec を記述しないでください。孤立した成果物には状態も担当者もありません。
• 「issue は明白だから」という理由でトリアージを省略しないでください。agent:* ラベルと brief があることで、再分析せずにディスパッチできます。
• 1つの応答で複数のフェーズをまとめないでください。一度に1つのゲートだけ進め、次のフェーズに入る前にユーザーが成果物をレビューします。