AI の「直しました」に証拠を付けさせろ！ pstack を Claude Code に入れてみた

こんにちは、小林です!

株式会社リンクアンドモチベーションでデータスチュワードをしています。個人開発では機械学習で米国株の押し目を推定して売買する機能を持ったアプリを作っていて、その開発で Claude Code を使い込んでいます。その環境に、Cursor の公式プラグインリポジトリで公開されている pstack を入れて使っています。

はじめに

pstack は、エージェントの「直しました」という報告を受け取る前に、確かめた証拠を出させるための作業の型の集まりです。Cursor のエンジニア poteto 氏が公開し、Claude Code にもコマンド2つで入ります。

仕事を始めるときに呼ぶのは /pstack:poteto-mode だけです。poteto-mode は依頼文から23種類の作業の型（プレイブック）を1つ選び、その手順を TODO リストに一字一句写してから作業を進めます。Bug fix、Feature、Perf issue の型は、完了の前に本物のアプリやコマンドで動作を確かめる手順を含みます。確認が通らなければ、エージェントは合格扱いにせずにその旨を報告します。

ただし、エージェントが自分で動作を確かめられる環境がなければ、この仕組みは働きません。そのため利用者は最初に、リポジトリごとの検証スキルを作ります。

効果は、私の個人開発ですぐに見えました。毎回 500 を返していた API の修正を頼むと、エージェントは修正前のコミットで5組の API がすべて 500 を返すことを自分で再現しました。修正後は26件のテストで直ったことを示し、3つのモデルによるレビューで見つかった抜けも、先にテストを足してから埋めました。この記事の初稿も同じレビューにかけ、事実の誤りを2つ直しています。

Claude Code を普段使っていて pstack を知らない人と、エージェントの運用を設計する立場の人に向けて、pstack v0.15.29 の使い方と仕組みを説明します。考え方の説明には、kaito 氏の Zenn 本『【Cursor pstack】AIエージェントに開発を任せる環境をつくる』（v0.15.29 に対応した 2026-10-20 版）を引用します。

導入

プラグインを入れる

Claude Code には、次のコマンド2つで pstack を入れます。

claude plugin marketplace add cursor/plugins
claude plugin install pstack@cursor-plugins

marketplace add は cursor/plugins リポジトリを ~/.claude/plugins/marketplaces/cursor-plugins に clone します。SSH での clone に失敗すると HTTPS で取り直すので、GitHub に SSH 鍵を登録していない環境でもそのまま進めます。私は、SSH 鍵も ssh-agent も使えない状態でこの切り替えを確かめました。

あとで pstack を新しい版に上げるときは、claude plugin update pstack@cursor-plugins を実行して Claude Code を再起動します。PR の作成には gh コマンドを使うので、gh auth login もこの段階で済ませておきます。

モデルと検証スキルを設定する

Claude Code を再起動したら、/pstack:setup-pstack を実行します。setup-pstack は推論の予算（各役割のモデルにどれだけ深く考えさせるかで、Claude Code の effort に当たる）を4段階から選ばせ、役割ごとのモデルを ~/.claude/rules/pstack-models.md に書き出します。Claude Code は ~/.claude/rules/ の Markdown を毎セッション読み込むので、この設定は次のセッションから効きます。

setup-pstack は最後に、アプリを動かして確かめる手段（verify-* のスキルなど）がリポジトリになければ、検証スキルを作るかを一度だけ聞きます。初めて使うなら、作ります。続けて、形式検証のスキルがなければ、それを作るかも一度だけ聞かれます。形式検証のスキルは、モデル検査や証明を使い、テストが通る場合だけでなく対象のすべての場合でコードの性質が成り立つことを確かめる手順書です。ガイドは、並行処理、リトライ、状態機械、パーサーのように、テストでは壊れる場合を拾いにくいコードがあるなら作るよう勧めています。

cursor-team-kit のスキルを3つコピーする

pstack の手順は、Cursor の別パッケージ cursor-team-kit のスキルを3つ名指しで呼びます。その3つは、コミット前に AI が書きがちな余計なコードを削る /deslop と、画面やコマンドを操作して動作を確かめる control-ui と control-cli です。cursor-team-kit は Claude Code 向けには配布されていませんが、この3つの中身は Playwright や tmux を使う普通の手順書で、Cursor の機能に頼っていません。

marketplace add で clone したリポジトリから、次のコマンドでコピーします。同じ名前のスキルが既にあれば、このコマンドはそのスキルを残し、コピーしません。

K=~/.claude/plugins/marketplaces/cursor-plugins/cursor-team-kit
mkdir -p ~/.claude/skills
for s in deslop control-ui control-cli; do
  [ -e ~/.claude/skills/$s ] || cp -R $K/skills/$s ~/.claude/skills/
done

既に同じ名前のスキルがある場合、pstack はそちらを呼びます。中身が同じかは diff -r で確かめてください。

Cursor のチャット履歴を前提にした workflow-from-chats のようなスキルも含まれるので、cursor-team-kit の18のスキルを丸ごとはコピーしません。pstack が呼ぶのは、この3つだけです。

コピーしたスキルは pstack を更新しても新しくならないので、更新のたびに見比べます。

コストを見積もる

pstack は、サブエージェントと複数モデルのレビューに余分なトークンを使います。ガイドは、それを厳密さの代金だと書いたうえで、減らし方を4つ挙げています。

• /pstack:setup-pstack を実行し直し、推論の予算を下げるか、安いモデルを選ぶ
• 役割を auto か inherit-parent にして、チャットのモデルで動かす
• レビューに並べるモデルの数（パネル）を減らし、動くサブエージェントを1つずつ減らす
• 小さく明らかな編集には使わず、厳密さが要る仕事にだけ /pstack:poteto-mode を使う

使い方

依頼文の書き方

pstack のガイドは、依頼文に書くことを5つ、書かないことを2つ挙げています。中心は目的と、合否が出る完了条件です。やり方を書くとエージェントがよりよい方法を探す余地がなくなり、スキルを使う順序を書くと型の手順が抜けたり入れ替わったりします。

書く	書かない
目的（何が問題か、何を実現したいか）	やり方（どのファイルをどう直すか）
合否が出る完了条件。時間の長さは完了条件にならない	スキルを使う順序
確認したい証拠（出力、スクリーンショット、前後の数値）	最初のうちは、自分が推測した原因。書くと調査が偏る
分かっていること（症状、ログ）
本当の制約（「まず再現して」「コードは変えないで」）

同じチャットで別の話を始めると、poteto-mode は進行中の型の次の手順だと受け取ることがあります。話題を変えるときは、依頼文を new task. で始めます。

場面別の依頼文

pstack のガイドと本の例を、Claude Code の呼び方に直して載せます。

不具合を直すときは、再現を先に頼みます。

/pstack:poteto-mode users get two notifications after a retry. repro first, then fix and verify.

コードを変えずに原因を調べるときは、Investigation の型が選ばれます。この型は読むだけで、PR を作らずに、根拠を引用した説明を返します。

/pstack:poteto-mode new task. figure out why the cache entry survives logout. don't change any code yet.

機能を追加するときは、完了条件と見せてほしい証拠まで書きます。

/pstack:poteto-mode add json output to this command. text output stays byte-identical, the json parses, both run against the sample project. show me the evidence.

設計を比べてから進めるときは、/architect を名指しします。/architect は、複数のモデルに型と関数の骨組みを並行で作らせ、比べてから統合します。

/pstack:poteto-mode we need to add rate limiting for external webhooks. /architect this first, and answer any open questions with prototypes. let me review before proceeding.

差分をレビューさせるときは、/pstack:interrogate を使います。

/pstack:interrogate the whole branch, but skeptically. no nitpicks unless it's an actual bug or regression.

TODO リストの実物

次の TODO リストは、この記事の下書きの確認を Investigation の型で頼んだとき、私の Claude Code が実際に作ったものです。1番目の手順はコード向けなので、エージェントは理由を添えて飛ばしています。

1. Route through the how skill. For motivation questions, also route through the why skill.
   skip: 対象はコードではなく記事なので、how の代わりに interrogate の複数モデルのレビュアーで原典と照合する
2. throughput checkpoint: n/a, read-only investigation
3. Produce the how-shaped output, or a recommendation with a tradeoffs table if the request is a decision between alternatives.
4. Apply the unslop skill to the reply.

手順を省くこと自体は許されています。省いた手順と理由がリストに残るので、利用者は省き方が妥当かを後から読んで判断できます。ただし、このリストもエージェント自身が書いた記録なので、理由が筋の通ったものかは利用者が読んで確かめます。

考え方

pstack の考え方は2つに分けられます。報告ではなく成果物を信頼することと、任せる範囲を確かめられる環境の広さで決めることです。

信頼するのは成果物

本の第2章の見出し「信頼するのは、エージェントではなく成果物」が、pstack の考え方をまとめています。本は、その理由を一文で書いています。

成果物を信頼するのは、報告は正しさの証明にならないからです。

「直しました」は作業をしたという報告で、正しいことの根拠ではありません。根拠が書かれていなければ、受け取った人は結局自分で差分を開き、動かし直すことになります。そこで pstack は、完了の条件を本物の成果物で確かめたことに置きます。原則の1つ Prove It Works は、ビルドが通った、エージェントがそう言った、といった代わりの指標で完了を判断することを禁じています。

型の手順も、この考え方で書かれています。Bug fix の型は、同じ画面や同じコマンドで元の再現手順が通ることを確かめさせ、「判定できなかった」や「別の画面で確かめた」は合格と認めずに報告させます。PR の本文には検証結果の欄（Verification）があり、実際に動かした経路とその結果を1〜3項目の箇条書きで書かせます。

任せる範囲は、確かめられる環境の広さで決まる

本の結論は「おわりに」の次の一文です。

エージェントに任せられる範囲は、エージェントの賢さではなく、エージェントが自分の仕事を確かめられる環境の広さで決まる

pstack のガイドは、この考えを検証スキルの勧めとして具体化しています。ガイドによれば、自分で確認できるエージェントは確認が通るまで手を止めず、確認できないエージェントは結果をその都度人間に戻して手作業で確かめさせます。検証スキルは、アプリを起動し、ユーザーと同じ操作をして、スクリーンショットなどの証拠を残すための、リポジトリ専用の手順書です。/pstack:create-verification-skill を実行すると、エージェントが対象のリポジトリを調べて生成し、一度動かして使えることを確かめてから渡します。

本は任せ方を4つの段階に分け、仕事の種類ごとに1段ずつ上げるよう勧めています。私なりに言い換えると、人間の手元に残る仕事が段階ごとに減っていきます。

1. 人間が、差分と動作を全部確かめる
2. 確かめるのはエージェントで、人間はその証拠を読む
3. 人間は依頼と完了条件を書き、PR と証拠だけを受け取る
4. 仕事を並列で任せ、人間は方針と取り消せない操作だけを決める

証拠を読む経験を積まないまま並列にすると、確かめていない PR だけが増えていきます。そのため本は、途中の段階を飛ばさないよう念を押しています。poteto 氏が発表した「2026年8月の1か月で2,500件の PR を本番にリリース」は、この最後の段階の姿だと私は推測しています。本も、この件数を「エージェントに安心して任せられる環境を整えた結果、あとからついてきた数字」だとしています。

仕組み

型、スキル、原則

pstack の部品は3種類あり、それぞれが答える問いが違います。型は「何をどの順でやるか」に、スキルは「その手順をどうこなすか」に、原則は「迷ったときにどちらを選ぶか」に答えます。原則もスキルの形で実装されていて、v0.15.29 には型が23、原則が24、原則以外のスキルが32あります。

poteto-mode は依頼に合う型を1つ選びますが、例外が2つあります。大きな仕事や席を外して任せたい仕事は、Feature のような型が当てはまる場合でも /figure-it-out に回します。どの型にも当てはまらない仕事も同じです。/figure-it-out は、その仕事専用の手順を組み立てるスキルです。

PR を出す型は、最後に Opening a PR の手順を呼びます。

コンテキストの扱い

pstack は、読ませる量を必要な分に絞ってコンテキストを空けておきます。セッションの最初に読ませるのは、入口の SKILL.md（151行）と、Claude Code では対応表だけです。原則は SKILL.md の中に「いつ当てはまるか」の一行ずつの索引として並び、エージェントは当てはまった原則の本文だけを開きます。型は選んだ1つだけを開き、スキルは手順がそこに来たときに読みます。

この読み方を守らせる規則もあります。poteto-mode は返答に、どの原則がどの決定を左右したのかを書き添えるよう求めます。名前を挙げてよいのは、このセッションで本文を読んだ原則だけです。原則の名前だけを覚えていて本文を読まずに引用する、という手抜きをこの規則が塞ぎます。依頼文に apply prove it works. のように原則名を添えると、その原則を適用させられます。適用する原則は本文を読む決まりなので、結果として本文が読まれます。

サブエージェントへの渡し方も、メインのコンテキストを小さく保つように決められています。poteto-mode は、サブエージェントへの指示にファイルの中身を貼らず、パスだけを書くよう求めます。中断と再開を挟むと指示が抜け落ちるため、やり直しや次の仕事では、poteto-mode は元の依頼、その後の指示、前の報告をまとめて新しいサブエージェントに渡します。前のサブエージェントを続けて使うのは、手元の作業ツリーや動いている開発サーバーのように、そのエージェントにしかない状態が要るときだけです。

/pstack:interrogate の中身

/pstack:interrogate は、設定した複数のモデルに同じ差分を読ませて弱点を探させ、その結果をリードのレビュアーが仕分けるスキルです。interrogate が返すのは判定までで、どれを直すかは利用者が決めます。

レビュアーへの指示

interrogate は、レビュアーごとに「セキュリティ担当」のような役を決めません。全員に同じテンプレートの指示を渡し、指摘の違いはモデルの癖の違いに任せます。ガイドによれば、癖が違えば見落としも違うので、別々のモデルがそろって挙げた指摘は偶然の一致ではない見込みが高くなります。

指示には、作者の意図が入っています。レビュアーは意図そのものを疑わず、意図を実現できているかだけを疑います。

観点は、正しさ、根本原因と症状の区別、構造の整合性、検証、複雑さの上限、セキュリティの6つで、当てはまらない観点を無理に使わないよう指示されています。これに加えて、コード品質の観点が渡ります。この観点は、動作を変えずに構造を大きく簡素化できる変更を積極的に探させ、1,000行未満だったファイルを1,000行超えにする PR を、強い理由がない限り止めるべきものとして扱わせます。

指摘には、3段階の深刻度と、該当箇所と、問題だと考える理由を付けさせます。深刻度は、バグ、データ消失、セキュリティのように実害につながるものが critical、今は壊れないが設計や保守に響くものが warning、文体や命名のように動作に関わらないものが nit です。指摘がなければ「no findings」と書いて止めることも、正しい結果として認められています。

リードの仕分け

リードは、票を数える役ではありません。指摘ごとに直す価値を判断する、経験のあるエンジニアの役を担います。別々のモデルがそろって挙げた指摘がいちばん重く、1つのモデルだけの指摘は中身を読んだうえで軽く扱います。

仕分け	意味
Act on	このまま出すと正しさ、安全、保守のどれかに実害が出るので、PR なら差し戻す
Consider	妥当だが、今やる価値があるかは利用者が決める
Noted	正しいが、今回は手を付けない
Dismissed	誤り、細かすぎる、事情を知らずに出たもののいずれかで、理由を添えて退ける

退けるときの目安は、interrogate の references/lead-judgment.md に例付きで書かれています。私の言葉でまとめると、実際の呼び出し元では起きない仮定、まだ要らない抽象化の要求、根拠のない好み、事情を知らないための誤解の4種類です。大きな問題を見つけられなかったレビュアーほど細かい指摘で数を稼ぎがちだ、という注意も添えられています。反対に、別々のモデルが一致した指摘、実行経路を具体的に示した指摘、セキュリティと正しさの指摘は、退けたくなったときほど読み直すよう求めています。

最後に、リードのレビュアーは、どのモデルが何に同意し、どこで意見が割れたかを Agreement Map として返します。

Claude Code で動く仕組み

生成されたコピーと対応表

pstack の元のスキルは、Cursor の機能名で書かれています。Task ツール、readonly: true のサブエージェント、Cloud Agents などです。Claude Code が入れるのは、この元から機械的に生成されたコピーです。cursor/plugins のマーケットプレイス定義は、pstack の取得元を、元の pstack/ から生成先の harness/pstack/claude-code に向けています。

生成スクリプトは、各スキルの Markdown を2つの条件で調べます。1つは、Task や readonly など、スクリプトが正規表現で知っている22種類の Cursor 固有の名前が出てくるかです。もう1つは、別の pstack スキルを、リンクを付けずに名指しで呼んでいるかです。どちらかに当たったスキルには、見出しの直下に次の一行を差し込みます。

In Claude Code, read the Claude Code adapter once per session before you follow this skill. It maps the Cursor names in pstack skills to Claude Code.

v0.15.29 では、56のスキルのうち23にこの一行が入っています。原則のスキルでは、Prove It Works だけが別のスキルを名指しで呼んでいるため、この一行が入っています。

スクリプトが知っている名前を使っているのに対応表にその行がなければ、生成スクリプトはエラーで止まり、生成したコピーが元より古いままだと CI が失敗します。決まった範囲の抜けを、人のレビューに頼らずに機械で止める作りです。

対応表（docs/harness/claude-code.md）は、名前の置き換えを表で定めています。主なものは次のとおりです。

Cursor	Claude Code
Task ツール	Agent ツール
readonly: true のサブエージェント	Explore サブエージェント。Explore は読み取り用だが Bash を使えるので、指示に「ファイルを編集しない」と書き、終了後に git status で確かめる
environment: "cloud"（Cloud Agents）	isolation: "worktree"。作業するブランチかコミットを指示に書く
中断したサブエージェントの再開（resume）	新しいサブエージェントを立て、前の結果を指示に貼る
claude-opus-5-5-xhigh のようなモデル名	model: "opus" と effort: "xhigh" に分け、-fast は外す
Grok など Claude 以外のモデル	model を指定せず、セッションのモデルで動かす
組み込みの PR ツール	手順が示す gh pr create などのコマンド
~/.cursor/rules/pstack-models.mdc	~/.claude/rules/pstack-models.md

pstack の56のスキルのうち、setup-pstack を除く55は、エージェントが自分の判断で呼べないよう設定されています（disable-model-invocation: true）。Claude Code では、利用者が /pstack:poteto-mode のように明示して呼びます。ほかの pstack スキルを手順の中で使うときは、エージェントが Skill ツールを使わずに SKILL.md を直接読んで従います。

Claude Code で飛ばされる手順

Cursor にしかない機能が要る手順は、Skipped in Claude Code: <手順>. <理由>. と返答に一行書いて飛ばされます。エージェントは止まらず、質問もせず、次の手順に進みます。

Cursor の機能	Claude Code での扱い
Cloud Agents	ローカルの git worktree に読み替える。クラウド上のエージェントそのものが要る手順は飛ばす
Bugbot（Cursor の PR 自動レビュー）	Bugbot が付けたコメントは普通のレビューとして仕分ける。PR に Bugbot がいなければ、起動して待つ手順を飛ばす
Automations（時刻やイベントをきっかけにエージェントを動かす機能）	飛ばす
Grok などの他社モデル	セッションのモデルで動く

対応表に行がない Cursor の機能もあります。長い作業を続けさせる Cursor の /loop、Cursor 組み込みのスキル作成機能、毎ターン有効にする Custom Mode がその例です。対応表は、行のない項目は使わずにその旨を伝えるよう定めています。Custom Mode については、/pstack:poteto-help が、Cursor 以外では新しい仕事ごとに /poteto-mode を付けるよう書いています。

レビューのパネルを別々のモデルにする

他社モデルの代わりは、Claude Code では用意できません。既定の設定は、コードを書く役割に Grok を、判断と文章に Claude Opus を割り当て、レビューのパネルも Opus と Grok の2つです。Claude Code でこのまま使うと、Grok の枠はセッションのモデルで動くので、セッションが Opus ならパネルは2つとも Opus になります。私は fable、opus、sonnet の3つを並べ、答えが1つのモデルの傾向に偏らないようにしています。

arena runners: fable high, opus high, sonnet high
architect runners: fable high, opus high, sonnet high
interrogate reviewers: fable high, opus high, sonnet high
arena cross-judge pool: fable high, sonnet high

Arena は、同じ課題を複数のモデルに並行で解かせ、互いに審査させてから良い部分を統合するスキルです。Arena がこの候補から親のチャットと違う系統のモデルを審査役に選ぶため、最後の行だけ opus を入れていません。私のメインのチャットは Opus なので、候補に opus を入れても選ばれません。学習元の違う他社モデルをパネルに混ぜる効果は、Claude のモデルを並べても同じにはならないと私は推測しています。

pstack が他と違う点

エージェントへの規約を CLAUDE.md や AGENTS.md に書く方法と比べて、pstack は次の3点が違います。

1つ目は、規約を読んだかどうかを返答で確かめられることです。CLAUDE.md の規約は、エージェントが守ったかどうかを外から確かめにくいものです。pstack では、前に述べた原則の引用の規則により、読んだ原則とその影響が返答に残ります。

2つ目は、作業の手順がリストとして残ることです。CLAUDE.md の規約だけでは、どの手順を踏み、どの手順を省いたかを返答から推し量るしかありません。pstack では TODO リストを読めば分かります。

3つ目は、エディタをまたぐ移植を仕組みで支えていることです。スキルの本文は Cursor の名前のままで、Claude Code 版との差は生成スクリプトと CI が見張ります。手で移植した規約集は、元が更新されるたびにずれていきます。

使用例

3つの例の題材は、私の個人開発とこの記事の執筆で、仕事のデータやコードは使っていません。

例1: Bug fix の型で、毎回 500 を返す API を直す

個人開発の FastAPI アプリで、常駐ループの開始 API が毎回 500 を返していました。/pstack:poteto-mode に再現と修正を頼むと、Bug fix の型が選ばれました。エージェントは修正前のコミットでアプリを起動し、5組の開始 API がすべて 500 を返すことと、サーバーのログに RuntimeError: no running event loop が5件出ることを確かめました。

原因は、開始と停止の API が同期関数で書かれていたことです。FastAPI は同期関数をスレッドプールで実行するため、関数の中の asyncio.create_task が動いているイベントループを見つけられませんでした。停止の API は 500 にはならないものの、別のスレッドから task.cancel() を呼んでいて、スレッド安全ではありませんでした。

エージェントは10個のハンドラを async def に変え、HTTP 経由で開始、状態確認、停止、再開始を確かめる26件のテストを足しました。修正前のコミットではテストのうち15件が失敗し、修正後は全件が通ります。既存のテストで失敗していた43件が修正前のコミットでも同じく失敗することも確かめ、今回の変更とは関係がないと示しました。

その後の /pstack:interrogate では、fable、opus、sonnet の3つのモデルが独立に「停止側のテストがない」と指摘しました。opus は「停止 API の直後に running: true を返している」ことも見つけました。

エージェントは、停止ハンドラを同期関数に戻すと失敗するテストを足し、running: true の件は失敗するテストを先に書いてから直しました。全ルートの非同期を強制する構造的なテストのように、レビューで挙がったが今回は見送った項目は、PR の範囲の欄に「扱わないもの」として書かれました。

例2: 検証スキルを安全に動かすため、本番への接続を遮断する

同じアプリには、エージェントが検証用のインスタンスを起動して画面を操作する検証スキルがあります。ところが、本番のマシンでこのスキルを動かすと、検証用のインスタンスがローカルで動く本番の外部 API ゲートウェイに接続し、本番と共有している取得枠を使ってしまう作りになっていました。接続先がコードに書き込まれていて、環境変数では向け先を変えられませんでした。

エージェントは、macOS の sandbox-exec で検証用インスタンスを包み、そのポートへの接続だけを拒否する設定を作りました。起動の前には同じ設定で IPv4 と IPv6 の両方から接続を試し、拒否されない環境では遮断なしで起動せずに失敗させます。確かめ方は、接続を記録する偽のサーバーをそのポートに立てる対照実験です。遮断なしで起動して該当の API を呼ぶと偽サーバーに3本の接続が来て、遮断ありでは0本でした。この差から、接続を止めているのが sandbox-exec だと分かります。

エージェントは PR に、確かめられなかったことも書きました。偽サーバーがすぐ接続を閉じるので、lsof による確認項目が実際の接続を捉えられるかは再現できていません。本番のマシンでは、まだ実行していません。

例3: この記事自体を /pstack:interrogate にかける

/pstack:interrogate はコードの差分のためのスキルですが、私は記事のレビューにも流用しています。この記事の初稿を、pstack 本体、Zenn 本の原文、私の要約の3つと照らし合わせるよう指示してレビューさせました。

fable、opus、sonnet の3つのモデルは、そろって同じ2つの誤りを挙げました。1つは「どの型も動かして確かめる手順を含む」という書き方で、Investigation のように読むだけの型があるため誤りでした。もう1つは「確かめに失敗すると原因の調査に戻る」という流れ図で、型の手順は通らなければ報告するとだけ書いていて、図のループは私が作った話でした。3つのモデルとも、指摘ごとに pstack 本体のファイル名と行番号を根拠として付けていました。

fable だけが、macOS の cp -n は既存ファイルを飛ばすと終了コード1を返すと指摘しました。私が手元で試すと、そのとおり1が返りました。この記事の導入コマンドを、3つのスキルだけを条件付きでコピーする形に変えたのは、この指摘がきっかけです。

公開前のこの版も、同じ3つのモデルで確かめました。「読み替えられないのは〜だけ」「検証の欄は必須」のように、ソースより強く言い切った箇所が7つ見つかり、すべて直しました。7つのうち6つは、初稿の誤りと同じく「全部」「だけ」「必須」と言い切った箇所で、残る1つは例2の「本番のマシンではまだ実行していない」の書き落としでした。

まとめ

導入を済ませたら、失敗しても困らない本物の小さな仕事を1つ選び、合否が出る完了条件を付けて /pstack:poteto-mode に渡してみてください。返ってきた証拠を読むところから、エージェントに任せる範囲を広げていけます。

最後まで読んでいただきありがとうございます!

参考

• cursor/plugins の pstack README
• pstack の Claude Code 用対応表（docs/harness/claude-code.md）
• Claude Code 版を生成するスクリプト（scripts/generate-pstack-harness-trees.mjs）
• kaito『【Cursor pstack】AIエージェントに開発を任せる環境をつくる』（Zenn）。本編46章で型ごとの手順と24の原則を解説していて、型の手順を読み比べるなら第3部から読めます