Ship with skills, not vibes 25 個の skill を一本の開発フローにつなぐ

これが書くのは一つの問いに答えるための使い捨てのコードです。問いが先に来て、あとに来るすべての形を決めます。間違った問いに答える prototype は、どれだけ見栄えがよくても純粋な無駄です。「使い捨て」は、どう書くかへの制約であって、「必ず破棄する」という約束ではありません：テストなし、動く以上のエラー処理なし、抽象化なし、永続化なし。

二つの分岐で、返ってくるものは大きく違います。「このロジックや状態モデルは正しく感じられるか？」には共有できる単一の HTML ファイルが返ってきます——state panel、free-play ボタン、タブ式のナビゲーションを備え、すべて領域の言葉でラベルづけしてあるので、デザイナーや領域の専門家にそのまま渡して自分で感じてもらえます。裏のロジックは DOM に触れないきれいな純モジュールで、検証できたらそのまま本番のコードへ引き上げられます。「これはどう見えるべきか？」には同じ route 上に並ぶ、大きく異なる複数の UI バリアントが返ってきます。フローティングの下部バーで切り替えます。バリアントが食い違うべき場所は色ではありません。構造です——軽く調整しただけの card grid が三つ並んでも、それは壁紙であって prototype ではありません。

それを「堅牢化」していると気づいた瞬間、もう prototype を作ってはいません——テストを足す、本物のデータベースにつなぐ、「あとで必要になるかも」のために一般化する。そういうことです。

成果物をどう扱うか：答え（裁決と、それが解決した問い）は耐久性のある場所に置きます——commit message、ADR、実装 issue。prototype 自体は消しませんが、main にも入れません。commit 先は prototype/<name> branch、決して merge しません。実装 issue にポインタを一つ残します。

落とし穴：本当は実装すべき場面で、agent は prototype を勧めてきます——命名の問題で、流れに不慣れな agent には「チケットができたあとの当然の次の一歩」と読めてしまうのです。それからもう一つ。app 全体を prototype しないこと：自然な停止点がなく、惰性でそのまま製品になり、「テストもエラー処理もない」コードがそのままユーザーの前に出ます。

それが素材にするのは一次資料だけです（公式ドキュメント、ソースコード、仕様、ファーストパーティの API）。どの主張も、答えを持っているその出所まで遡ります。会話の中では答えてくれません——出力は一つのファイルで、どの主張にもリンクが付きます。決め手は、読む部分をどこで走らせるかです。バックグラウンド agent。

research は委任した足仕事であって、外注した思考ではありません。

落とし穴：自分自身の二つ目を生んでしまいます（issue 530）——skill は呼び出し側にバックグラウンド agent を立てろと言うだけで agent の種類を縛らないため、立ち上がるのは同じツールと指示を握った汎用 agent で、それがまた一つ立ち上げます。ある人の計測がこれです。単一の research タスクが、三回の重なった実行で約 450k token を燃やしました。重複したほうは三十分後、完全に視界の外で終わっていました。呼び出したらバックグラウンドタスクの一覧を見て、重複を止めてください。

もう三つあります。逆向きの失敗——グローバルな指示がさらなる委任を禁じている場合、バックグラウンド agent は丁重に断り、skill は静かに何もしません。「信頼度の高い出所」はモデル自身の判断で、allowlist はありません。実際に効く緩和策はこれです。引用を二つ三つ、無作為に追いかけること。そのもの自体ではなく「そのものの要約」に着地していたら、その実行は失敗です。停止基準がありません。範囲はこちらの責任です——一つの API、一つの挙動、一つのバージョンについての主張のほうが、「research X」よりはるかに良いものが返ってきます。

research ファイルは ADR ではありません：ADR は残し、research ファイルは使い終わったらアーカイブするか削除します。古くなった research ファイルは無いより悪く、以後の repo 読み取りを汚染します。

六つのフェーズ：repro を作る、最小化する、仮説に順位をつける、プローブを仕込む、リグレッションテスト付きで直す、片づける。

「タイト」なフィードバックループができるまで、agent に理論を立てさせません。名前の付いたコマンドが一つ、すでに一度走らせてある、この bug では赤で、直せば緑になる。bug 報告を渡された coding agent の既定の振る舞いはコードを読んで推測することですが、この skill はそれを塞ぎます。赤にできるコマンドがなければ、Phase 2 はありません。その gate こそが、この skill の価値のすべてです。

ループが「ある」ことは目標ではなく、「タイト」であることが目標です：速い（秒単位）、決定的（毎回同じ裁定）、鋭い（「crash しなかった」ではなく、正確な症状を断言する）、agent が無人で走らせられる。30 秒かかって flaky なループは、無いのとたいして変わりません。断続的に出る bug では、目標はきれいな repro ではありません。再現率を上げることです——トリガーをループさせる、並列化する、負荷をかける、sleep を注入する。

これは衝突をテキストの問題として扱うことを拒みます。hunk に手を触れる前に、両側を一次資料まで遡ります——commit message、PR、元の issue——ですから、選んでいるのは二つの意図の間であって、二つのテキストの塊の間ではありません。両立できるところでは両方を残します。本当に両立しないときは、この merge の明示された目標に合うほうを選び、そのトレードオフを言葉にします。衝突を取り繕うために新しい振る舞いを発明することはありませんし、途中で投げ出しません：merge は必ず完了した commit まで運ばれます。

repo 自身の自動化された検査を見つけ出し、commit の前に走らせもします——merge は git のなかで、「二つの branch を同時に満たしているのに、どちらの側のテストも通らない」ものが最も生まれやすい場所だからです。

追加の実務知識：衝突を避けるために並行タスクのあいだで「ファイルを分け合う」のはやめてください。得られるものよりコストのほうが高くつきます。守る価値のある唯一の規律はこれです。大きなリファクタリングを先に済ませる。worktree で並行して進めるときは、merge して戻すのは、その変更を書いた session がやるのがいちばんです。意図を知っているのはその session だけだからです。全員の衝突をまとめて最後の agent に batch で渡すのは、この skill が苦労して組み立て直そうとしているものを、ちょうど捨てる行為です。

codebase をスキャンして深化の機会——浅いモジュール（インターフェースが、それが隠しているものとほぼ同じくらい複雑なモジュール）を深いモジュールに変えられる箇所——を洗い出し、HTML レポートにまとめ、選んだ候補に対して grilling を行います。

コードは決して変更しません。run 全体が生み出すのは「HTML ファイル 1 つと対話 1 回」です。リファクタリングそのものは後で別の session で、通常の構築フローに乗せます。これが、リファクタリングツールではなく点検であるということの意味であり、「まだ手を付ける準備ができていない」codebase に対して走らせる価値がある理由でもあります。

フィルターは二つ：deletion test——このモジュールを削除したと想像したとき、複雑さはより小さなインターフェースの背後に集約されるのか、それとも各呼び出し側へ拡散するのか。「集約」になるケースだけがカードになります。また、領域を指定しない限り、直近の commit 履歴を先に読み、スキャンをいま動いているパスへ寄せます——誰も触っていないコードの深化は、あなたが永遠に実行しないリファクタリングです。

強度ラベルは三段階：Strong（deletion test を明確に通過し、摩擦も実在する。真剣に見る価値あり）、Worth exploring（筋は通るが、見返りはコードがこの先どこへ向かうかに左右される）、Speculative（網羅性のために挙げてあるだけで、大半は安心して無視できる）。

自分が作成していない issue にだけ使います。生の bug 報告、外から来た feature request、突然現れた外部の PR。to-tickets が産出するチケットは構造上すでに agent-ready であり、それらに triage を走らせても、うまくいって無駄骨です。この skill は提案して待ちます：分類と状態の判断を理由とともに伝え、指示があるまで何も適用しません。

triage された項目はどれも、最終的に分類の役割ちょうど一つと状態の役割ちょうど一つを持って終わります。分類は二つ、bug と enhancement。状態は五つ：needs-triage（評価が必要なもの）、needs-info（報告者待ち。返信があれば needs-triage に戻る）、ready-for-agent（完全に仕様化され、agent brief が付いている）、ready-for-human（同じ brief に「なぜ委譲できないか」を加えたもの）、wontfix（クローズ、理由は記録済み）。

wontfix は三種類あり、その違いは重要です。なぜなら知識ベースに書き込まれるのは一種類だけだからです：すでに実装されているものは、それが存在する場所を指すコメントを残し、out-of-scope には書きません（それは作られた機能であって拒否された機能ではありません。書き込むと重複チェックを汚染します）。拒否した bug は丁寧に説明してクローズします。拒否した enhancement は out-of-scope ディレクトリにファイルを一つ書き、クローズのコメントからリンクします。そのディレクトリは拒否された概念一つにつき markdown 一つ（issue 一つにつき一つではありません）であり、triage は何かを評価する前にディレクトリ全体を読み、キーワードではなく概念で照合します。

brief を書く前に検証します：bug は報告者の手順どおりに再現し、PR は checkout して関連するテストを走らせ、そのうえで三つの結果のいずれかを報告します——確認済み（コードパス付き）、再現できない、試すには詳細が足りない（これ自体が最も強い needs-info のサインです）。すべては agent brief を良くするためであり、その brief は正確さより耐久性を旨として書かれます：型、シグネチャ、振る舞いの契約を書き、ファイルパスと行番号は決して書きません。issue は何週間も放置されることがあり、その下でコードは動き続けるからです。

落とし穴：label は自動では作られません。状態が五つでは足りないというのが最もよく挙げられる不足です（blocked、deferred、implemented はいずれも要望がありますが、どれも ship されていません）。backlog 全体に一度に放って走らせないでください——「注意が必要なものを見せて」というパスは、選ぶための安価なリストです。一度に二十個の issue を回すと、agent はそれを静かに証拠の土台として扱ってしまいます。そのうえこの skill が返すのは、issue の本文だけでコメントは返しません。

この skill が引き受けるのは、agent session 一つには収まらないほど大きな案件です——目的地は言えるのに、まだ経路が見えない。それを tracker 上の共有された一枚の地図として描きます。地図は decision チケットで構成され、一度に一枚ずつ解いて経路がはっきりするまで進めます。

計画はしますが、実行はしません。各チケットは「解決すると決定が出る」問いを一つ抱えているのであって、実行すべき構築の一片ではありません。地図が完成したと言えるのは：誰かがこれを作り始める前に、決めるべきことが何も残っていない状態です。このルールは agent が最もよく破ります。

これと grill-with-docs の境界は session の数であって、プロジェクトの大きさではありません：一つの会話に収まるなら grilling（安くて質も良い）。収まらないときだけ wayfinder です。範囲がはっきりしている機能に wayfinder を持ち出すのは、よくある間違いです。

地図に載る四つのもの：Destination——行き着いた先がどんな姿か。それをどのチケットよりも先に名付けます。Decisions so far——クローズしたチケット一枚につき一行、それぞれ詳細が実際に住んでいる場所へリンクします。Not yet specified、つまり戦争の霧——来ることは見えていても、まだ正確に言い表せない決定です。判定基準はその問いをいま正確に言えるかどうかであって、答えられるかどうかではありません。Out of scope——目的地の外だと判断した作業です。クローズし、決して卒業させません。地図は保管場所ではなく索引であり、決定はそれ自身のチケットの中にだけ生きています。

Frontier は「開いていて、ブロックされておらず、まだ引き受けられていない」チケットのことです。session は作業を始める前にチケットを自分に assign して引き受けるので、assignee がそのまま引き受けの印です。チケットは常に名前で呼び、裸の番号は使いません——issue 番号がずらりと並んだ壁は、文章の中では読めません。

現在の会話を一つの引き継ぎドキュメントに圧縮します——ワークスペースではなく OS の一時ディレクトリに書き出される markdown ファイルで、まっさらな agent がそれを読めばそのまま引き継げます。

これが買っているのは可搬性であって、圧縮ではありません。そのぶん、聞こえるよりずっと狭い用途になります：ファイルが要るのは、仕事が動くときだけです。トリガーは四つ——harness を替える、別のディレクトリや repo に移る、仕事を同僚に渡す、phase の途中で見つかった支線を分岐させる。

最も飛ばされがちな使い方は分岐です。自分は自分の session に留まったまま、蓄積した context の複製を、並行して働く二人目の agent に渡します。prototype の脇道はまさにこう使います：深い設計の会話の最中に、走らせてみないと決着しない問題にぶつかり、しかも苦労して積み上げた thread をその調べものに費やしたくない——prototype の session に handoff し、答えを受け取り、それを持ち帰って、元の thread で引用する。二回の横断、生きた会話は一つ、話し直しはゼロ。

何が旅をするか：ドキュメントは生きた thread（いま何が飛んでいるか、なぜか、次は何か）と、推奨する skill を一組携えていきます。秘密は書き出す前にマスクされます。すでに書き留められているものは、意図的に一切持っていきません——spec、計画、ADR、issue、commit、diff はすべてパスか URL で参照し、決してコピーしません。

落とし穴：ファイルは一時ディレクトリにあり、パスは長く OS ごとに違うので、パスを尋ねて書き留めてから先へ進むこと。session をまたいで temp を消す環境もあるので、次の session がすぐに始まらないなら、自分で永続的な場所へコピーしておきます。次の agent への渡し方はパスを指すことです。要約を shell コマンドに貼り込んではいけません——特殊文字を含む要約は壊れますし、典型的な失敗は黙って切り詰められることです。「what は拾うが why は拾わない」というのは公正な批判なので、「次の session は何のためか」をパラメータとして渡すとよいでしょう。そして、検証されていない思い込みが事実として書き留められていないか注意してください。

自分ひとりでは決められない決定を、一通の質問票に変えて、足りないピースを握っている人に渡します。

それが問い詰めるのは「今回の送付」であって、主題ではありません。主題についてあなたを問い詰めても、ここでは意味がありません——主題を知らないことこそが、他人に書いて送る理由なのですから。そこで、必ず答えられる二つのことだけを尋ねます：誰に宛てるのか（相手の役割、専門、あなたとの関係。これで語り口と、ドキュメントがどれだけ context を自前で持つべきかが決まります）と何を持ち帰る必要があるのか（自分では決着させられない具体的な決定や事実。これが成果物を測るチェックリストになります）。そのあとはすべて起草です。

ドキュメントの形：一行の purpose と、「あなたの頭の中に一度も入ったことのない人」に向けた短い context。質問は重要なものから先に並べ、主題ごとにまとめる。一問に一つの考えだけ、複合質問は絶対に作らない。「わかりません」と答えてよいと明示する——フラグの立った不確かさは役に立ち、事実のように読める自信ありげな推測は役に立ちません。最後は catch-all を一つ。

これは意図的に一切分岐せず、一切複数の宛先を取りません。三人が三つの答えを握っているなら、三回走らせます。最もよくある使い方は、行き詰まった grilling です：同じ会話の中で走らせます——ingest の段階を持たないこの skill が grilling のあとで働くのは、その session がすでに context に入っているからにほかなりません。

agent が、いま言ったばかりのことをもう一度売り込み直します：足りなかった context を補い、平易な言葉で書き、あなたのプロジェクトの CONTEXT.md にある語彙を使います。

この skill はたった三行で、それは未完成の草稿ではなく設計です。冗長さと戦う skill は、長くなることで失敗します：四百行の「簡潔にせよ」を読んでも、モデルはやはり冗長になります。モデルが読み取るのは、訴えの中身ではなく分量だからです。

名前がそのまま仕組みです。先頭に来る語は wait。「もっと簡潔に」は agent の出力についての指示で、モデルは「言葉を削る」ことで従い、その結果あなたはもっと迷子になります。wait が指すのはあなたの状態です：「理解はここで失敗した」と言っているのです。「短くして」と言われた agent は電報を書きます。「待って、置いていかれた」と言われた agent は戻って説明し直します。流行している言い回しはどれも出力を名指ししていて、モデルは短いだけで明確にはならない語り口へと過剰修正します。聞き手を名指しすれば、両方の半分がそろって手に入ります：より少ない言葉、そしてあなたに欠けていた前提。

意図的に「説明し直すのはそれ」と言い、「直前のメッセージ」とは言いません——あなたを置き去りにしたものはたいてい一段落より大きく、どこまで戻るかは agent が決めます。本当の解毒剤は、あらかじめ共有言語を作っておくことです。wait-what が直せるのは、すでに起きてしまった一件だけです。

これを実行したディレクトリを常設の学習ワークスペースに変え、一連の自前のスタイルを持つ短い HTML レッスンで、複数の session にまたがって一つの主題を教えます。

モデルがすでに知っていることからは教えません。parametric knowledge は信用できないものとして扱われます：教える前に、まず信頼度の高い資料を探し、資料ファイルに記録し、どのレッスンでもそれを引用します。そして状態を持ちます——mission、資料、レッスン、学習ログはすべてファイルとしてディレクトリの中に住んでいます：

中心にある考えは storage strength（長期の保持）であって、 fluency（その場の思い出せる感じ。読んでいるあいだは習熟したように感じられ、一週間後には消えています）ではありません。それは望ましい困難を使って前者を作ります。知識が先です（この段階では難度は敵であり、理解に必要なワーキングメモリを食います）。技能はそのあと、タイトなフィードバックループで鍛えます（この段階では難度は道具です）。レッスンはめったに読み返されませんが、リファレンス文書は読み返されます——ですから、一つのレッスンの圧縮されたエッセンスはリファレンスのディレクトリに属するのであって、それを導入したレッスンの中に埋めるものではありません。

落とし穴：ファイルが間違った場所に書き込まれることがあり（issue 377、あるユーザーのレッスンがグローバルの skill ディレクトリに書き込まれました）、最初にディレクトリ名をはっきり言ってください。小テストの正解が必ず最初の選択肢になります（複数のモデルで確認済み、未修正。あるコントリビューターは 9 レッスン 33 回すべてが A だったと報告しています）。能力評価のステップがありません。最初のメッセージで、自分の既存の知識とギャップを伝えてください。間隔反復のスケジュールもありません。復習したければ自分から頼んでください。

コードのためだけではありません——記録では、コード以外の用途のほうが大きな割合を占めます。コードの中では、いちばん強い用途はゼロから言語を学ぶことではなく、見知らぬ codebase や新しいチームの技術スタックの中で方向をつかむことです。著者はきれいな組み合わせを一つ挙げています。問い詰められている最中に分からないものに当たったら、grilling を止めて学びに行かないでください——学習ワークスペースへ handoff し、そこで学び、戻って続きをやります。

それは対話型 bash scriptを生成し、人間を一歩ずつ手作業の手順に沿って導きます——サードパーティサービスをつなぐ、一度きりの移行を走らせる、プロジェクトを状態 A から状態 B へ移す。

agent が script を書きますが、それを実行することは決してありません。実行するのは自分のマシンの上です。ですから wizard は、それに従って進める手順書ではありません——それはプロセスを駆動し、状態を保持するプログラムであり、あなたの担当はクリックとペースト、そして Enter を押すことです。Stage は「一つの画面に一つの集中したタスク」で、script は stage の間でターミナルをクリアします。

script を書く前にまず scoping：それは何も知らないまま尋ねるのではなく、あなたの repo を読みます——環境ファイル、compose ファイル、framework config、そして CI 設定の中のすべての secret と変数参照。そのどれもが wizard の出さなければならない値です。そのうえで順序づけた stage の一覧を出して確認を取り、そのあとで初めて各 stage を人間がたどる正確な経路に対応づけます。今の UI がどうなっているか分からないときは、あなたに尋ねるか文書を調べるのであって、クリックを発明したりはしません。

template がすでに UX を解決しています：進捗、確認ゲート、クロスプラットフォームでの URL の起動、secret の伏せ字入力、環境ファイルへの冪等な書き込み、CI secret の書き込み、そして「何をスキップしなければならなかったか」の締めくくりの要約。固定ライブラリの半分はどの wizard でも同じで、決して手で直しません。一貫性こそが要点です。wizard を書く agent はそれをエンドツーエンドで実行せず、静的な検証に切り替えます。最初に実行するのはあなたで、その一回がそのままテストです。

落とし穴：途中で前のステップに戻れません。3 つ目のステージで打ち間違えたら中断して走り直しです（走り直しは安く、環境ファイルに書き込み済みの値はデフォルトとして戻ってきます）。プロンプトでは矢印キーに bug があり（issue 741）、backspace は効きます。サードパーティサービスの状態を調べに行くことはしません。API key はモデルの context に入りません——ただし scoping のときに key をチャットへ貼り付ければ、それは貼り付けた他のどんなテキストとも同じく context の中にあります。

これは設計を進めるのと同時に、プロジェクトの ubiquitous languageを作り上げ、磨いていきます——用語集と衝突する言い回しに異議を唱え、曖昧な言葉を使ったときに正確な言葉を引き出し、具体的なシナリオで一つの関係を境界がはっきりするまで圧力テストします。

これは能動的な規律であって、受動的なものではありません。ただ CONTEXT.md を読んで語彙を借りるのは、どの skill にもできる一行の習慣です。これはモデルを変えているときに使うものです。これが、あなたを中断させる理由です：用語が決着したその瞬間に、会話の途中で CONTEXT.mdへ書き込みます——バッチ版は一回の session の要約であるのに対し、リアルタイム版はその session の実際の成果物。

成果物は二つ、基準も二つ。CONTEXT.md に入るのは用語（あるものが何であるか、一〜二文）です。書き込みのしきい値は「曖昧な言葉が正式な用語になったとき」、タイミングはリアルタイムです。決して入らないのは実装の詳細、spec、走り書き、一般的なプログラミングの概念です。ADR に入るのは一つの決定（一〜三文：context、選択、理由）です。書き込みのしきい値は三つすべてに当てはまること——逆転が難しいこと、context がなければ意外に感じること、実際のトレードオフの結果であること——であり、しかも提案であって既定ではありません。

本当に覚えておくべきなのは CONTEXT.md のあのルールです。実戦で壊れるのがそのルールだからです：それは用語集であり、用語集でしかありません。放っておくと、モデルは「CONTEXT.md に書き込む」を「与えられた答えをすべて永続化してよい」という許可として受け取り、ファイルは走り続ける spec になってしまいます——これはこの skill でいちばん多く報告されている問題で、複数のモデルにまたがっています。

この skill の効きを実感できる動き：何かがどう動くのかをあなたが述べると、それはコードを調べて矛盾を並べて見せます——「あなたのコードは Order 全体をキャンセルしていますが、いま部分キャンセルができると言いました。どちらが正しいのですか？」こうして、どちらか一方が変更される前に、言語とコードは声に出して揃うことを強いられます。制限：交差参照するのはコードと commit 済みのドキュメントだけで、あなたの issue tracker は検索しません。ですから、数か月前にクローズされた issue の中で議論し尽くして意図的に決着させた命名の衝突が、新しいものとして持ち出されます。

落とし穴：CONTEXT.md が 500 行以上に膨らむ——サイズは症状であって病気ではありません。そのまま、簡潔にして実装の詳細を取り除くよう指示してください。ファイルが本当に引き締まっているのに、読者が同時に頭へ入れたくない二つの領域をなお含んでいる場合にだけ、分割を検討します——肥大したファイルを分割しても、肥大したファイルが複数できるだけです。自動トリガーはこの skill の最も弱いところです：grilling を一通り走らせても CONTEXT.md の中身がまったく変わっていないなら、まさにそれが起きています。名指しで指示してください。人のレビューを経ていない、agent が書いた用語集は、無いよりも悪いものです：自信ありげに響く言い伝えになり、後続の session に真実として扱われます。

skill、指示ファイル、spec、runtime prompt、README——agent が読むものならすべてです。包装は違っても、書き方は同じです。

この skill の既定の動きは削除であって、説明ではありません。agent に別の agent 向けの指示を書かせると、字数の大半はモデルがすでに知っていることの説明に消えます。そのどの一行も no-op です：context の対価を払いながら、行動を何ひとつ変えていません。この参考資料はそれを見つけ出すためのレンズです。だからこの skill が値を返す相手は、白紙のファイルだけではありません。すでに手元にある文書に対しても、少なくとも同じだけの価値を生みます。

負担は二種類あります。Context load は、常時ロードされる材料が agent のウィンドウの中で払わせるコストです。指示ファイルの一行、skill description、トリガーされるかどうかに関係なく毎 turn context に居座るもの、そのすべてです。Cognitive load のほうはあなたにかかるコストです。どの文書が存在し、いつどれに手を伸ばすか——索引はあなた自身です。これは最小化すべきコストではなく、人間が主導権を握るための値段です。この二つが腑に落ちれば、書くときの判断の大半は、同じ取捨を場所を変えて行うだけになります。

五つのてこ：Context pointer（context の中にあり、context の外の材料を名指しし、「いつ取りに行くか」まで符号化した参照。agent がどれだけ確実にそこへ手を伸ばすかを決めるのは、pointer の言葉づかいであって、その参照先ではありません）、Information hierarchy（「ファイル内の手順」から「ファイル内の参考」へ、さらに「pointer の先に置いた参考」へと上がる梯子）、Completion criteria（防ぐのは早すぎる完了、その防衛線です）、Leading words（モデルの事前学習にすでにある圧縮された概念。錨は二度下ろします——body では実行のために、pointer ではトリガーのために）、Pruning（単一の真実の源、関連性、そして一文ずつ当てる no-op test）。

no-op test は行動で測るもので、美意識で測るものではありません：その一行を消して、agent の行動が変わるかを問います。通らなかった文は、丸ごと削る——言い換えるのではありません。意見が割れたときは、その文書を走らせて決着をつけます。議論はしません。判定基準は、文書が良くなると同時に短くなること、そして残りの少なさに驚くこと。もうひとつ、同じことが二度書かれていないこと（重複は「この文書は一度も試されていない」ことの最も確かな徴候です）。

この skill が手に取るのはゆるいアイデアです。それを材料にインタビューし、あなたがそれに踏み切れるようになるまで続きます。練り上げた計画がなくても始められます——その計画を作ることこそが、この session の目的です。そしてこの skill は無状態です。ファイルも書かず、作業場も残しません。残るのは、頭の中にある、より鋭くなった版だけです。題材はコードでなくてよく、repo も要りません。

plan mode は切ってください。これは agent に早く計画を出せと急かすもので、「問いの中に留まる」ことの正反対です。

うまく回っているときの姿：あなたが何かに異を唱えます——一度も押し返さなかった session は、そもそも要らなかった session です。質問は長い点滴ではなく「数回のラウンド」で届き、後のラウンドは前に言ったことの上に明らかに積み上がります。ある問いが、ずっと暗黙のうちに下していた決定を掘り返すので、予想しなかった場所にたどり着きます。終わるころには、どの選択もその場にいなかった人に向かって弁護できます。

ラウンドを数えて、質問を数えないでください。46 問を 4 ラウンドに分けるのは普通の一回です。200 問は範囲が大きすぎるという意味で、長すぎる session は dumb zone——つまり context window が埋まりすぎて質問の質が落ちる領域——へ漂っていきます。問い詰めが終わって腹が決まったら、新しい session を開かないでください。その会話の context こそが価値です。

これは勧めて、そこで止まります。grill もせず、spec も書かず、ファイルも開かず、名指ししたばかりの skill を代わりに起動することもしません——手に入るのは「次に何を打つか」だけで、打つのはあなたです。渡してくる思考の単位は flow：単一の skill ではなく、skill を貫く一本の道筋のことです。

知っておくべき正直な限界。これは手書きの地図で、repo に遅れますし、この pack の skill しか知りません。しかも「skill の半分は入っていない」と言ってきます——既知で未修正です。routing される skill の大半は user-invoked で、harness はそれらを agent に注入する一覧に載せません。agent はその一覧を完全なものとして扱い、存在しないと報告します。それらは入っています。

さらに、この skill は他の skill の挙動を誤って説明することがあります：skill 本体ではなく、自分が持つ一行の要約から答えるからです。ある詳細な報告では、単一の session の中で三回それが起きており、「thread を spec に変えるもの」という大雑把な印象だけで to-specを飛ばすよう勧めた例も含まれていました。その SKILL.md ファイルは一度も開かれておらず、代償として本物の seam チェックが一回抜け、切り出したチケットは作業量を過小評価していました。他の skill について効いている断言をしてきたら、まず開かせてください——その SKILL.md。

位置づけ：ask-matt はこの一式の上に立つ secondary sourceです。router と SKILL.md が食い違ったときは、SKILL.md のほうが正しいです。

状況：顧客から「ときどき送信すると 500 が返る」と報告があり、自分では再現できません。

1. 他人からの報告なので、まず合流路に乗ります：/triage。報告者の手順で再現できますか。できなければ needs-info、あるいは今すぐ追うと決めます。
2. 今すぐ追うと決めたら、session を開き直します：/diagnosing-bugs、そして「まず赤くなるループを作ってくれ」と明言します。

この先は機械的です：最小化（残った要素はどれも、なぜ効いているのかを言えること）、3 から 5 個の順位づけされた反証可能な仮説（唯一の人間のチェックポイント）、タグ付きのプローブを埋めること、修正より先にリグレッションテストを書くこと、後始末、そして当たった仮説を commit message に書くこと。

知っておくべき分岐がひとつ：そのリグレッションテストを置く正しい seam がないとき、この skill はそう言うべきで、偽の安心を与える浅いテストを書くべきではありません——「seam がない」こと自体が発見です。渡す先は improve-codebase-architecture。

状況：八年目のプロジェクトに入ったばかり、あるいは vibe-coded な repo を引き継いだところです。ADR もなく、領域言語もなく、設計原則もありません。

1. 初日：/setup-matt-pocock-skills で tracker と文書の配置を整えます。
2. 初日：/grill-with-docsで、この既存の repo を CONTEXT.md を通して立ち上げてもらいます。覚悟すべきはとても長いインタビューです（ファイルが形になるまで 50 問以上かかったという報告もあります）。しかも能動的に舵を取ってください——この skill はコードを読み、見つけたものについて質問してきますが、「コードにすでにある言葉のどれが正しい言葉か」を決めるのはあなたです。
3. 二日目：/improve-codebase-architectureを呼び、開口一番「問い詰めないで、まずレポートをください」と伝えます。すべてが Speculative なら、実際には何も見つけられていないということです。Strong の候補を一つ選びます。
4. 二日目：候補は一度に一つ。その候補について grilling させ、成果物は diff ではなく「決定」です。そのあとに to-spec、to-tickets、implement。
5. その後：数日おきにアーキテクチャ点検をもう一度回して、メンテナンスとします。

正直な期待値：本当に収拾がつかなくなったプロジェクトでは「少しは助かったが、それでも足りない」という報告があります。八年もの legacy codebase では、モデルが同じ場所を堂々巡りするのを見た人もいて、一方で同じ skill が整った repo ではきれいな図を出してきます。いまのところ、このケースを専門に扱う skill はありません。

状況：新しいプロダクトモジュールをゼロから作る。道すじはまったく見えておらず、一回の対話で話しきれるものでないのは明らかです。

1. まず五つの wayfinder: label があることを確認します（存在しない label があると gh コマンドがそのまま失敗します）。
2. /wayfinder。最初にやるのは、destination の命名です。問われるのは「地図全体の目的地」であって、この session の目的地ではありません。範囲は境界のはっきりした一つの epic まで絞ります。「V1 の実装」ではいけません。
3. 幅優先の grilling を一度おこない、Destination、Decisions so far、霧、Out of scope を描き出します。霧とチケットを分ける判定基準はその問いを「いま」正確に言えるかどうかです。冒頭の grill で霧が一つも見つからなければ、「これは地図が要らないほど小さい」と言って止まるべきです。
4. research チケットは地図を描いている最中に発射され、並行で燃やします。ほかのチケットは一度に一枚だけ。自分に assign して引き受けます。
5. 一枚解くごとに、resolution のコメントを貼り、チケットを閉じ、地図に一行残して、そこで止まる。前方の霧を晴らし、いま言葉にできるようになったものを新しいチケットへ卒業させます。
6. 地図が空になったら：/to-spec #<map_issue>（渡すのはメインの地図で、個別の decision チケットではありません）。そのあとに /to-tickets、/implement。

三つの致命的な落とし穴は 第 06 節 の wayfinder の項目にすでに挙げてあります：agent が本番コードを書き始める、そして to-specを飛ばさない、grilling チケットを並行で回さない。

状況：ビジネス上の判断を考えている——新しい製品ラインを立ち上げるか、提案の価格をどう決めるか、記事の論証の骨組みをどう組むか。

1. きれいな対話を一つ開きます（どの repo の中にいる必要もありません）。plan mode を切って、 /grill-me。
2. 一巡ずつ答え、番号を振ってまとめて返します。浅すぎる問いは押し返し、範囲がずれてきたら言葉にします。「わかりません」は本当の答えです。
3. 「実物を見ないと答えられない」問いに当たったら、それは ungrillable です。コード以外の場面ではたいてい、一枚の下書きを先に作る、一枚の表を先に計算する、顧客を一人先に捕まえる、のいずれかになります。
4. 「答えが他人の頭の中にある」問いに当たったら、同じ会話の中で /to-questionnaire。それをその人に送り、答えが返ってきたら次の一巡を開きます。
5. これはステートレスです：ファイルを書かず、ワークスペースも残しません。残るのは、あなたの頭の中にある、より鋭くなった版だけです。