Claude Code pstackを入れたのに変わらない時は、頭に/poteto-modeを付ける

出典: Claude Code に pstack 到来！/poteto-mode を使うだけで、開発がさくさく進む

道具を入れたら、頼み事の結果まで変わるのか。この動画は、そこから入ります。入れた事と、動く事。この2つは、同じなのでしょうか？

動画は、pstack を Claude Code に入れる話です。台本・図・声はAIで作られていて、入れた画面は動画を作った側が撮った物だと、動画の説明にあります。解説役はさとるさん、聞き役はレオさんの掛け合い。

冒頭に出る依頼の例は、JSONで出す機能を足して、今の出力は1バイトも変えないで、というもの。

AIは前後の出力を突き合わせて差分なしを見せ、使った原則の名前まで書いてきます。

覚えることは少ない、と話は続きます。setup でAIが考える量を選び、あとは頼み事の頭に /poteto-mode を付けるだけ。

動かして確かめ、証拠を見せてから終わる流れです。

ただし、入れても変わらない、とはっきり言い切ります。

/pstack まで打つとスキルが並びますが、中身は1枚ずつの手順書。人が呼び出すまで、どれにも出番は来ない作りです。

さとるさん（動画 1:13〜）

1 枚ずつの手順だけど打つまではどれも動かないんだ。

では、Cursor のものが、なぜ Claude Code で使えるのか。Cursor 公式の置き場が Claude Code 向けの入れ方を用意していて、入るのは元の pstack から自動で作られたコピーです。

中身は、入口の poteto-mode が1つ、作業の型が23本、原則が24個と画面に出ます。

ほとんどのスキルは、人が打った時だけ動く設定。例外は setup-pstack です。

/poteto-mode は、頼み事を読んで作業の型を1本選び、手順を ToDo の先頭に書きます。例はバグ修正で、再現→原因→直す→動かした証拠。どれにも合わない時は、別のスキルが手順を組み立てます。

急ぐ時は飛ばしてもかまいませんが、スキップした事と理由は残ります。聞く前に、試せば分かる事は試します。

動きや速さ、見た目で決まる事は、作ってみた結果で決めます。そういう線引きです。

さとるさん（動画 3:39〜）

人に聞くのは好みと製品の判断だけだね。

返事の書き方にも決まりがあります。主張ごとに、測った、推測した、当て推量、を書き分けます。終わると言う前に実際に動かして確かめる原則には、Prove It Works という名前が付いていて、コンパイルが通っただけでは終わりにしません。

さとるさん（動画 4:11〜）

それだと動いた証拠にならないね。

入れた事と動く事は別です。道具が動き出すのは、打った時。ここが入口です！

正直、この線引きの横には、私の4行を置いておきたいんです。

私は2026年9月23日に、文章を作る時の判断基準として、4行をAIに言い切りました。毎回事実で構成する、不足情報はヒアリングする、怪しい認識はグリルミー徹底的にする、調べてわかることは聞かない、の4行です。

私の記事より（ＡＩが聞き返してくるのは、頼りないのか・書き出しの節）

毎回事実で構成する　不足情報はヒアリングする　怪しい認識はグリルミー徹底的にする　調べてわかることは聞かない

4行の芯は、自分で確かめられる所は先に確かめて、人に聞くのは好みと判断だけに絞る、という線です。聞く線をどこに引くか、という点で、動画の線引きと同じ線を見ているんですよね。

入れた道具が動くのは、打った時。だとすると、入れた日に、頼み事の頭に何を付けるかまで決めておけば、入れただけで終わらずに済みます。

私なら、AIが試して分かることは試させて、人に聞く線は、好みと判断だけに絞ります。

同じ頼み事を、pstack ありとなしで動かしたら、何が変わるのでしょう？ 先に言ってしまうと、変わった所は意外と少なめ。その少なさに、読みどころが詰まっています。

動画は、公式ガイドの最初の例を、小さなCLIで、pstack ありとなしに分けて動かします。

JSON出力を足し、テキスト出力は1バイトも変えず、両方確かめます。そういう頼み事です。

あり側では、変更前の出力を先に保存し、実装は別のサブエージェントへ任せます。

元のAIは待機して、戻った変更を自分で確認。比べたパターンの数を数え損ねて、自分で直す場面まで映ります。

画面には、25通りの比較、増えたのは2ファイルで31行、かかった時間は1分39秒と出ます。動画を作った側が動かした画面です。

違いは3つ。1点目は、実装を pstack:poteto-agent というサブエージェントに任せること。2点目は、返事の最後に原則の名前を書くこと。3点目は、頼んでいないのにコミットまで進むこと！

勝手にコミットして怖くないのか、とレオさんが聞きます。さとるさんの答えは、取り消せる仕事なら確認なしで先へ進み、立ち止まるのは共有ブランチへの force push やデプロイのような、取り返しのつかない操作の前だけ、というもの。

さとるさん（動画 6:14〜）

元に戻せる仕事は聞かずに進めるんだって。止まって聞くのは共有ブランチへのフォースプッシュやデプロイみたいな戻せない操作の時だけだね。

確認そのもの、つまり前後の出力の突き合わせは、pstack なしの Claude Code もやっていた、と話は整理されます。

変わったのは、任せ方と、原則名と、コミット。

返事に出る原則の名前は、操縦のハンドルにたとえられます。AIが、ビルドが通っただけで、できました、と言ったら、人が prove it works と名前で頼む。それで進め方が変わる、という話です。

さとるさん（動画 6:53〜）

あれは原則っていう本物で確かめるみたいな短い決まりのスキルだよ。

同じ頼み事を2回やらせた観察もあります。

どちらも同じ原則名を挙げたのに、1回目は切り替えの表を作らず、2回目は表にまとめていました。レオさんが突っ込むのは、まさにそこです。

レオさん（動画 7:45〜）

名前は同じなのにやったことは逆じゃないか。

だから読むのは、名前より、何を変えたかの行。その行が無ければ原則を使っていないサイン、と公式のガイドに書かれている、と話します。

いやー、こうして並べると、違いは3点に絞れます。任せ方、原則名、コミット。この整理が、この章の芯です！

でね、測った、推測した、当て推量の書き分けの横には、私の答えを1つ置いておきます。

私は2026年8月7日の魂磨きで、偽りについてこう答えています。事実じゃないことを事実のように振る舞うこと、です。

私の記事より（神様ポジションという委ね方｜縄文を生きる人間、弥生を担う分身AI・事実じゃないことを事実のように振る舞わないという一線の節）

事実じゃないことを事実のように振る舞うこと

動画の書き分けは、確かめた事と確かめていない事を分けて見せます。私が答えた一線も、事実じゃないことを事実のように振る舞わない、でした。形は違いますが、事実のように見せない、という点は重なります。

戻せる仕事は進めて、戻せない操作の前で止まります。この線が先に決まっていれば、任せる側は、途中を見張らなくて済みます。

あ、それと、名前より行を読む。ここは外せません。

私なら、できましたの一言より、何を確かめたかの行を読みます。

AIが、できました、と返してきた時。それを確かめるのは、誰でしょう？毎回、人が画面を開いて確かめていたら、任せた意味が薄れてしまいます。だから、確かめる役を先に決めておくんです。

動画の第5章。setup は最後に、検証スキルを作るかどうかを聞いてきます。

公式のガイドは、初めてなら作ると答えて、と勧めていて、いちばん元が取れる、とまで書いている、と話します。

自分で確かめられるAIは、確認が通るまで手を止めない作り。確かめる手段が無いと、そのたびに人が手で確かめる役に回ることになります。

さとるさん（動画 8:45〜）

自分で確かめられるエージェントは確認が通るまで続けるんだ。確かめられないと毎回あなたが手で確かめることになるよ。

検証スキルは、アプリを人と同じように動かして確かめる、そのリポジトリ専用のスキルと、機能の地図の組み合わせ。確かめ方は doctor や screenshot などの小さなCLIにまとめて、使い捨てのスクリプトを減らします。

ここで、動画を作った側の確認が1つ。空のフォルダで setup したところ、アプリが無いので検証スキルの提案は出ず、名前の案内だけでした。

動画の第6章は、形式検証の話。まだベータです。人が操作する道は検証スキル。誰も通らない道、たとえば同じ通知が二重に届く、といった所は形式検証の受け持ちです。順番の問題を調べるのは、TLA+ という道具。

さとるさんは、渡す前に、わざと壊したコードで失敗する所を見せる、と話します。1度も失敗しない確認では、何も証明できない、という考え方です。

さとるさん（動画 10:42〜）

渡す前にわざと壊したコードで失敗するのを見せるよ。

ただし、合格と言えるのは、決めた範囲についてだけ。システム全体を保証するものではない、と念を押します。

さとるさん（動画 10:56〜）

そこは違って合格は決めた範囲についてだけ。システム全体の保証じゃないよ。

確かめる役を先に作れば、AIは確認が通るまで自分で続けられます。人の手を、確かめる作業から外していく仕組み。

正直、ここは地味な話です。でも、任せる話の土台は、この章です！

確かめた、と書けるのは、確かめた記録がある時だけ。記録の無いできましたは、まだ誰も確かめていない、という意味なんですよね。返事が、できました、だけで終わっている時。そこには、確かめた跡がまだ残っていません。

で、そう考えると、頼む側がやることははっきりします。終わりの確認を、頼む時に先に渡しておくこと。後から人が見て回るより、そのほうが頼む側の手も空きます！

合格は決めた範囲についてだけ、という念押しも、同じ向きの話かな。

どこまで確かめたのかを、言える形で残しておくこと。ここを曖昧にしないことが、任せる側の安心につながります。

形式検証のほうは、自分の仕事に、誰も通らない道があるかどうかを先に見るところから。毎日の頼み事の多くは、人が操作する道の上にありませんか？

二重に届く通知のように、人が見ていない所で起きる問題を抱えているなら、そこが形式検証の出番です。

画面を開けば確かめられる仕事なら、まず検証スキルの側で足ります。順番は、人が通る道が先。

入れ方は短いんです。では、頼み事の中身には、何を書けばいいのでしょう？さらに、寝ている間に任せられるのは、いつからなのか。

動画の第7章。入れ方は2行です。マーケットプレイスを足す /plugin marketplace add cursor/plugins と、/plugin install pstack@cursor-plugins。コマンドの頭には pstack: が付き、再起動なしで使えた、と話します。

続いて /pstack:setup-pstack。考える量の予算を、4つの段階から1つ選びます。動画を作った側が選んだのは large でした。

さとるさん（動画 12:07〜）

お金じゃなくてモデルが考える量のレベルだよ。

担当ごとのモデルの割り当てには、本来は別のAIの役も含まれます。Claude Code では、その役を今のセッションのモデルに置き換えて書く形。書き込み先は home の .claude/rules で、反映は次の会話からです。

動画の第8章は、頼み事の書き方。良い頼み事は、目的、終わったと言える確認、見せてほしい証拠、制約でできている、と話します。作者の例は、通知の重複を直して、まず再現、終わりは再試行しても通知がちょうど1回届くこと、失敗と成功の証拠を見せて、という頼み方です。

さとるさん（動画 13:52〜）

どう直すか一言も書いてない。そこが肝心だね。

スキル名を順番に全部書くのは、公式のガイドがよくある失敗の1番目に挙げているやり方です。理由は、手順の抜けや入れ替わり。順番はプレイブックが持っているので、目的と制約だけで足りる、という話でした。

迷った時は /pstack:poteto-help。作業はせず、送る文を渡してくれます。

動画の第9章は、寝ている間に任せる話。新しい worktree で、コミット前に聞かず、詰まったら止めて理由を書き、判断を記録に残します。

夜のループの順番は、終わりの条件を確かめる、小さく変える、本物で確かめる、進んだらコミット、だめなら捨てる、判断を1行記録、です。

任せる前の条件は4つ。条件が揃うまでは夜に任せず、まず検証スキルを持たせるところから始める、とさとるさんは話します。

さとるさん（動画 15:39〜）

夜に任せるのは4 つの条件が揃ってからまず検証スキルを持たせるところからだね。

頼み事に書くのは、手順ではなく、目的と確かめ方です。終わりの形を、先に置く書き方。どう直すかは、任された側に預けます。

私は2026年6月22日の朝LIVEで、売れるLP作って、とAIに頼むだけではガチャになる、と話しました。だから、グリルミーで材料を出し切って、設計書で、完成はここだよ、というところまで決めておく、という話でした。

私の記事より（AIに毎回お願いする、を卒業する｜grill-meで尋問、Goalで自走する仕組み・なぜグリルミーが効くのかの節）

AIに、例えば『売れるLP作って』というと、ガチャでうまくできるかもしれないけど、そんなの実践で使えないじゃんってなっちゃう。これをグリルミーして、全部自分の素材、材料を出し切る。プラス、どんなふうにしたいのか、この設計書ですよね。完成はここだよ、というところまで決める

動画の、目的と確かめ方。私の、完成の線。どちらも、頼む前に終わりの形を決めておく話なんですよね。

手順をこと細かに書くより、どこで終われば合格かを先に渡すこと。そこが重なっています！

でね、手順を書かずに任せるのって、少し心細くなりませんか？そこで気になってくるのが、任される側の条件。

私は2026年8月20日の魂磨きで、こう答えています。責任持って手を尽くしてやり切ること、正直で手抜きしないこと、分からないことは憶測なしで聞くこと、の3点です。

私の記事より（委ねたのに、また見てしまう、をやめた日｜AIのズレが感謝に変わる、メタ視点という視座・手放せた印は、安心より先に、意識しなくなることだったの節）

責任持って手を尽くしてやり切ること。正直で手抜きしないこと。分からないことは憶測なしで聞くこと。

夜に任せる前の条件を考える時、私はこれを、任される側の条件として横に並べます。動画の4つの条件と、私の答え。向いている方向は似ています。

私の記事より（委ねたのに、また見てしまう、をやめた日｜AIのズレが感謝に変わる、メタ視点という視座・手放せた印は、安心より先に、意識しなくなることだったの節・続き）

暴走して許可なく実行したり、指示したことをやらずにサボる上に嘘ついて誤魔化す

これは同じ日に、委ねられなくなる場面を聞かれて答えたものです。暴走と、サボった上での誤魔化し。どちらも、確かめた記録が残っていれば、後から見える形になります。

反対に、記録が残らない任せ方。朝に見ても、どこで何が起きたのか追えません。判断を1行ずつ残す決まりにも、だから意味が出てきます。

いやー、信頼って、気持ちで積み上がるものではないんですよね。条件が守られたかどうか。その回数で積み上がっていきます！

頼み事に書いた終わりの確認が、そのまま守られたかどうかの物差し。

夜に任せるのは、条件が揃ってから。

Cursor 由来の道具を Claude Code に持ってくると、そのままでは動かない所が出てきます。使う量も増えます。じゃあ、似た道具とは何が違うのか？

動画の第10章は、Cursor 専用の機能が Claude Code に無い話です。自動実行、コードレビューのボット、クラウドのエージェント、PRのツール。その手順は、飛ばした印と理由を1行書いて次へ進む決まりです。

ただ、動画を作った側が動かすと、その決まった形の行は出ませんでした。出てきたのは、普通の文で書かれた一言だけ。決まりと実際の出方に、少しずれがある場面。

Cursor のカスタムモードも無いので、仕事のたびに、頼む文の頭に付けます。poteto-mode が通らないという X の声は、名前に空白があるスキルが読めない別の不具合で、直しは未反映、と動画は話します。

動画の第11章は、使う量の話。増えるのは本当、とさとるさんは認めます。見比べ役が2体付く余分は、公式が言う厳密さの代金。それでも抑え方はある、と話は続きます。

さとるさん（動画 17:21〜）

使う量が増えるのは本当だけど抑え方もあるよ。

抑え方は4つ。予算を medium か small に下げる、サブエージェントを inherit-parent で親のモデルにそろえる、見比べ役を減らす、軽い直しには付けない、と並びます。

/cost を見ても、出るのはプランの使用率だけ。他のセッションも混ざるので、1回の作業で使った量は分からない、と動画を作った側は確かめています。

さとるさん（動画 18:08〜）

お金じゃなくてプランの使用率だったよ。他のセッションも混ざるから1回の作業で使った量は分からないね。

動画の第12章は、似た道具との比較。superpowers は、計画してから作り、自動で動く道具。grill-me は、作る前に質問する道具。gstack は、レビュー係のいる仮想チームです。

pstack との違いは2つ、と動画は整理します。計画の代わりに、試作して確かめること。打った時だけ動くこと。移植版の pstack-claude は、会話の始まりに指示を差し込む作りで、ここも違います。

まとめは、入れただけでは何も変わらない、の一言から。入れる（2行）、setup で予算を1つ、頭に /pstack:poteto-mode と、目的と確かめ方。最初の1回は、合否がはっきり出る頼み事がよい、と話します。

さとるさん（動画 20:00〜）

入れただけだと実は何も変わらないね。コマンドを打った時だけ動く作りだよ。

並べてみると、似た道具の違いは入口の違い。計画から入るのか、質問から入るのか、試作から入るのか？pstack は、試作から入る側に立つ道具です！

正直、ここが見えると、前の章までの話も一本につながります。

入れても動かない、打った時だけ動く、動かして確かめてから終わる、という3点です。どれも、試作から入る作りから出てくる話でした！

Claude Code で使う時の限りは、Cursor 由来の道具を持ってきた所から出る話。入口の違いとは別の軸として、分けて見ておくと迷いにくいです。

私は2026年6月22日の朝LIVEで、グリルミーは、問いを出してもらい、それをプランにまとめ、指示書を作って、ここで初めて実行を任せる、と話しました。問いが先で、実行は最後。

私の記事より（AIに毎回お願いする、を卒業する｜grill-meで尋問、Goalで自走する仕組み・今日のテーマの節）

グリルミー、尋問って書いてあるんですけど、要は問いを出してもらって、それをプランにまとめてきます。指示書を作っていって、ここで初めて実行を任せる。

引用を読み返すと、私のふだんの順番は、問いから入る側にあります。問いを出してもらってから、プランの形にしていく運び。

動画の比べ方で言えば、grill-me の入口。pstack は、計画の代わりに試作から入ります。

質問が先か、試作が先か？私はこれを、入口の違いとして並べておきます。

道具を選ぶ時に見るのは、道具の名前より、自分の頼み事の形。

決まっていない所が多いのか、動かせば合否が出るのか？そこを見てから、質問から入るか、試作から入るかを決めます。

次に何かを頼む時、それは質問から始めたい頼み事ですか？それとも、まず動く物を見たい頼み事ですか？

でね、使う量は、先に決め打ちしなくて大丈夫。予算を下げる道があるので、増えた分を見てから決めれば足ります！

入口が違う道具は、頼み事の形で選びます。

動画は、入れただけでは変わらない所から始まり、頭に付けて型を選ぶ、あり・なしの違い、検証スキル、入れ方と頼み方と夜の任せ方、そして限りと他の道具との違いへ、順に進みました！

いやー、持ち帰りは6つです。入れた事と動く事は別。返事は、できましたの一言より、確かめた行を読むこと。確かめる役を先に作ること。頼み事は目的と確かめ方で書くこと。夜に任せるのは条件が揃ってから。似た道具は入口が違うこと。

ここまでに引いた私の言葉は、聞く線を絞る、偽りの一線を引く、終わりの形を決める、委ねる条件を決める、問いを出してから任せる、の5つです！

次の頼み事に、終わったと言える確かめ方を、1行書き足せますか？