tracer-wat

Wat

すべてのスキルを覚えているわけではないので、尋ねてください。

状況に合う、最も軽いステップから始めてください。小さく、要件が固まっている依頼なら、直接 /tracer-implement に進めます。不確実性を解消したり、役立つ永続的なコンテキストを作ったりする場合にのみ、インタビューや仕様書を使ってください。大規模で見通しの立たない取り組みは、Wayfinder から始めます。エントリーポイントのワークフローは、ユーザーが呼び出すものであり、自動的には起動しません。

メインフロー：アイデア → リリース

1. /tracer-interview-me — ここから始めます。徹底的なインタビューは、設計ツリーとして機能します。各ラウンドでは、現時点で回答可能なすべての質問を一度に番号付きで提示し、それぞれに推奨回答を添えます。事実はサブエージェントが調べ、決定するのはあなたです。コードベースがある場合は、既存の CONTEXT.md／ADR を考慮し、最初のラウンドの前にツリーを絞り込み、確定した用語や決定事項を記録に反映します。コードベースがない場合は、ステートレスに実行します。フロンティアの質問に実行可能な回答が必要な場合（この状態モデルで問題ないか、この UI をどのように見せるべきか）は、/tracer-prototype に寄り道します。質問に答えるための使い捨てコードを作り、回答は残してコードは削除します。フロンティアがなくなり、暗黙の前提もなくなったら完了です。その後、/tracer-to-spec に引き継ぎます。

2. /tracer-to-spec：確定した決定事項を、簡潔な受け入れ基準、安全上の制限、焦点を絞った検証項目にまとめます。明示された決定事項を保持しつつ、実装上の提案を要件に変えてしまわないようにします。すでに明確な小さな依頼なら、仕様書は省略してください。

3. 分岐 — 複数のセッションにまたがる開発ですか？

   • はい → /tracer-to-tickets：仕様書をトレーサーバレット型の垂直スライスに分割し、それぞれにブロッキング依存関係を明記します。その後、チケットごとに**/tracer-implement**を開始し、各チケットの間でコンテキストをクリアします。
   • いいえ → ここで**/tracer-implement**に進みます。

4. 維持するコントロールの度合いを選びます。

   • /tracer-implement：短いアプローチと焦点を絞ったチェックを承認し、1つのコンテキストで実装してから一度レビューします。受け入れた欠陥は1回で修正し、コードが変更された場合に限り、修正箇所のみを再確認します。根拠と懸念事項を報告し、ブランチはそのまま残します。
   • /tracer-autopilot：通常の承認チェックポイントなしで、同様に適切な規模の作業を進め、その後、ブランチを終了する方法をあなたが明示的に選びます。独自のインフラストラクチャや、より強い保証が必要な場合は、引き続き判断が必要です。レビューと修正の上限は再開後も維持され、未解決の重要な作業は「Blocked」となります。

チケットが公開されるまで、ステップ1～3は途切れない1つのコンテキストウィンドウで実行してください。インタビュー、仕様書、チケットが同じ思考の積み重ねを引き継げるよう、途中でコンテキストを圧縮したりクリアしたりしないでください。その後の各実装またはオートパイロット実行は、チケットを起点に新たに開始します。

導入：大規模で見通しの立たない取り組み

取り組みが1つのエージェントセッションには大きすぎ、かつ進め方がまだ明確でない場合に限り、/tracer-wayfinderを使います。たとえば、仕様書に必要な決定事項をまだすべて把握できていない、新規プロジェクトや大規模な機能開発です。共有の決定チケットマップを作成し、セッションごとに1つの決定に取り組みながら、フォグ・オブ・ウォーのフロンティアを名前付きの目的地へと押し進めます。

/tracer-interview-me が1つのセッションに収まる決定ツリーを持つアイデアを解決するのに対し、Wayfinder はより大きなツリーを複数のセッションにわたって維持します。時間がかかり、運用上の負担も大きいため、最終的な開発が複数セッションに及ぶという理由だけで、スコープの明確な機能に使わないでください。

マップが明確になったら、成果物ではなく決定事項を出力します。マップを**/tracer-to-spec**に渡すと、リンクされたすべての解決内容を読み込み、実装可能な仕様書にまとめます。その後、/tracer-to-tickets、/tracer-implement と進めてください。複数セッションにわたるマップから、直接実装に進んではいけません。マッピングの結果、取り組みが本当に1つのセッションに収まり、マップが不要だと確認できた場合にのみ、直接 /tracer-implement に進みます。

チケットを並行して実行する

ブロッカーがすべて解消済みで、相互に依存関係のない最前線のチケットは、各チケットにつき /tracer-implement セッションを1つ実行して同時に進められます。

• 各セッションでは、まず /tracer-worktrees を実行します。各セッション専用のチェックアウト、ブランチ、.tracer/implement/ ワークスペースを用意します。すべてのタスクでコミットするため、並行セッションが変更済みの作業ツリーで衝突することはありません。
• 各セッションの作業が完了したら /tracer-finish-branch を実行します。新たな証拠でテストを検証してから、安全にワークツリーをクリーンアップしつつ、マージ／PR／保持／破棄を行います。

単独で使う場合

• /tracer-code-review — 固定された基準点に対するあらゆる差分を、基準と仕様の2軸でレビューし、各軸について重大度を評価したうえで判定を示します。独立したレビューを行う場合に選んでください。Autopilot は独自の範囲を限定したレビュアーを使用します。修正に使う予算は、ワークフローの呼び出し側が管理します。
• /tracer-convince-me — 完了した作業が当初の目標を達成していることを証明します。すべての期待事項を観察可能な主張に変換し、実用上可能な最も強い境界で新たな証拠を集め、証明済み、反証済み、未検証の事項を報告します。納品時の対象を絞ったチェックよりも深い証明を明示的に求める場合に使用してください。Autopilot の自動ステップではありません。証明レポートは失敗を報告しますが、修正を許可するものではありません。
• /tracer-tdd — red → green のリファレンスです。優れたテストとは何か、継ぎ目、アンチパターン、ループのルールを説明します。/tracer-implement は内部でこれを使用します。完全な仕様なしで、1つの振る舞いをテストファーストで構築するには、単独で使用してください。
• /tracer-worktrees ／ /tracer-finish-branch — メインのフロー以外でも、ブランチを分離して作業する際に使える開始・終了の手順です。
• /tracer-prototype — 1つの設計上の疑問に答える、小規模で使い捨てのプログラムです。ステップ1での寄り道ですが、設計上の疑問を机上で解決しにくい場合はいつでも利用してください。
• /tracer-research — 背景エージェントに一次資料を使って1つの事実確認の質問を委任し、引用付きの回答を1つの Markdown ノートにまとめます。Wayfinder は AFK リサーチチケットでこれを使用します。通常のインタビューにも活用できます。

基盤となる用語体系

他のスキルの下位で実行される、モデルが呼び出す2つのリファレンスです。それぞれが対応する用語の唯一の情報源です。言葉を定義するものであり、プロセスは実行しません。言葉が問題の場合は直接使用するか、上記のスキルから呼び出してください。

• /tracer-domain-modeling — ドメインの用語体系です。曖昧な用語に異議を唱え、多義的な言葉を整理し、覆しにくい決定を ADR として記録します。/tracer-interview-me のドキュメント対応モードが作成する CONTEXT.md と ADR の形式を管理します。
• /tracer-codebase-design — モジュールの形状を設計するための、深いモジュールの用語体系です（モジュール、インターフェイス、深さ、継ぎ目、アダプター、活用度、局所性）。/tracer-to-spec の継ぎ目のステップ、/tracer-tdd、/tracer-implement の Interfaces ブロックは、すべてこの用語体系を使います。

セッションをまたぐ場合

• /tracer-handoff — 現在の会話を、新しいセッションで引き継げるドキュメントにまとめます。/tracer-to-tickets の前にスレッドが長くなった場合や、/tracer-prototype セッションに分岐して回答を持ち帰る場合に使用してください。
• /compact（組み込み）— 以前のターンを要約しながら、同じ会話を続けます。フェーズ間の意図的な区切りで使用し、フェーズの途中ではコンパクト化しないでください。/tracer-handoff は分岐し、/compact は継続します。

前提条件（任意）

/tracer-setup — リポジトリごとに1回実行し、課題トラッカー（GitHub、GitLab、ローカル、または独自のもの。docs/agents/issue-tracker.md を参照）と、/tracer-wayfinder、/tracer-to-spec、/tracer-to-tickets、/tracer-code-review が参照するドメインドキュメントの構成を設定します。省略可能です。すべて .tracer/ 配下のローカル Markdown にフォールバックします。

意図的に含めていないもの

トリアージの導入手順や、独立したブレインストーミングの機能はありません。単一セッションでの発見は /tracer-interview-me が担い、複数セッションにまたがる不明瞭なケースのみ /tracer-wayfinder が担います。大規模な複数レビュアーのパック（例：/code-quorum）は、タスクごとではなくマイルストーンの区切りで組み合わせます。