全体の中で、今回はここ
最初はAIに何をさせるかを決めます。今回は仕事に合う手順を選び、次回はその仕事に必要な情報をそろえます。
この回のゴールはログインの不具合について「依頼の目的・変更してよい範囲・終わりの条件」を書けることです。pstackのインストールは不要です。
視点
今回の結論
/poteto-modeは万能な実装手順ではなく、依頼に合う手順を選ぶための入口です。
pstackの詳しい構造を見る
今は細部を覚えなくて構いません。各回で一つずつ、この構造に戻ります。
導入の背景と、pstackを作った人
私も以前、ECC（Everything Claude Code）やさまざまなSkillを導入していました。新しい道具を足してきた人にこそ、「今の環境では何が、いつ働くのか」を確かめながら読んでほしい講座です。
「AI環境の健康診断」「配線をほどく」は、指示・道具・検証のつながりを点検するというAMPLの比喩です。導入済みのものを全部消す話ではありません。
Anthropicはモデルの進歩に合わせて、AIを動かす周辺の仕組み（Harness）を見直す考え方を示しています。同社の開発事例では、構成を一括で簡略化すると元の性能を再現できず、一つずつ外して影響を確かめる方法へ変えています。pstackを教材に選ぶのはAMPLの判断です。
コードの細部をAIに任せる、非エンジニアのVibe Coderも、目的・変更してよい範囲・完了条件は自分で判断する必要があります。pstackが公開する手順と検証方法を手がかりに、AIへの依頼と結果の確認を練習します。
ECCやXの投稿をどう捉えるか
kaitoさんもAI開発環境の構成変更を紹介していますが、個人の選択です。今回確認できた投稿本文は一部で、ECCを外す理由までは確認できていません。
ECC自身も同じ環境への重複導入を避け、必要なルールを選ぶよう案内しています。特定の道具を一律に外すのではなく、自分の作業で何が必要かを確かめます。
なお、Claude CodeのSkillは通常、名前と説明を先に読み、本文は使用時に読み込みます。導入済みのSkillすべての本文が、常に読まれるわけではありません。
講座トップの学習地図で、全6回の学ぶ順番を確認できます。図に出てくる用語は各回で例とともに説明します。
Step 1：調査を頼んだのに修正された
ここから第6回まで、ログインボタンが反応しない練習用アプリを、共通の架空例として使います。実際の診断や検証結果ではありません。
最初の依頼は「ログインボタンが反応しない。原因を調べて。コードは変更しないで」です。それなのに、AIがよさそうな修正を始めたらどうでしょうか。
修正が正しくても、依頼とのずれがあります。原因を知りたかった段階でコードが変わると、元の状態を調べ直す手間が増えます。「調査」と「修正」は似た情報を使いますが、成果物が違う仕事です。
pstackはAIに渡す作業手順や判断基準をまとめたプラグイン、つまり追加機能のパッケージです。新しいAIモデルではありません。
この講座でいうエージェントは、依頼を受けてファイルを読んだり、道具を使ったりして仕事を進めるAIです。
/poteto-mode はAIに入口の指示を読ませる呼び出し名です。その指示を読んだAIが依頼に合うPlaybookを選びます。Playbookは仕事の種類ごとに用意した手順書。この振り分けをRouting（ルーティング）と呼びます。
自転車店で「ブレーキが利かない理由を知りたい。今日は修理しない」と頼む場面を考えてください。持ち帰りたいのは原因の説明です。「直して」と頼むなら、修理と、その結果の確認までが仕事になります。
受付で合わせるのは、説明か修理かという目的、分解や交換をしてよい範囲、何を受け取れば終わりかです。交換部品が正しくても、説明だけの依頼に勝手に修理を加えれば、依頼には合いません。
pstackでは説明を求める依頼にInvestigation、修正を求める依頼にBug fixなどを対応させます。「同じブレーキだから同じ仕事」ではないように、同じログインのコードでも目的から手順を選びます。
ただし、受付に相当する判断をするのはAIです。手順書を読ませることと、許可範囲をプログラムで強制することは別です。
Laurenさん自身はpstackを「自分を雇うようなもの」と紹介しています。本人の仕事の進め方を手順として共有する、という捉え方です。以下は作者の紹介投稿で、性能を検証した結果ではありません。
try pstack! it's like hiring me but it's free :)
lauren (@poteto)
作者の投稿をXで読む (2026-08-26)
Step 2：依頼を手順へつなぐ
依頼が曖昧なら、まずAIに「何が起きたか・どうなるはずか・まだ分からないこと」を言い直してもらいます。認識のずれを直してから、進め方を選びます。
LaurenさんがPt. 2で紹介するindirect promptingを、AMPLが学習用に整理した流れです。ここでは、すぐ修正を指示する代わりに、まずAI自身の言葉で問題を整理させる頼み方を指します。「ログインできない」という報告を、すぐ「認証のバグ」と決めつけないために使えます。
依頼ごとの成果物を比べる
同じログイン画面でも、依頼が変われば選ぶ手順も変わります。
| 依頼の目的 | 代表的な手順 | この段階の成果物 |
|---|---|---|
| どう動くかを調べたい | Investigation | 根拠付きの説明 |
| 起きている不具合を直したい | Bug fix | 修正と再検証の証拠 |
| 新しい操作を追加したい | Feature | 新しい振る舞いと検証結果 |
ここが核心です。AIに毎回ゼロから工程を考えさせる代わりに、依頼と手順の対応を読み直せる場所へ置いています。手順の抜けや取り違えを、人間も確認しやすくなります。
Step 3：実ソースで選び方を読む
GitHubでは説明書と実際のSkillを同じ場所で読めます。SkillはAIに渡す再利用可能な指示のまとまりで、/poteto-mode 自身もSkillの一つです。
cursor/plugins は複数のプラグインを収めたリポジトリです。リポジトリはコードや設定と変更履歴をまとめて管理する保管場所。今回読むのはその中の pstack フォルダです。
上のカードは最新版へつながります。以下の読解用リンクはある時点の変更記録であるcommitに固定しています。後から更新されても、講座と同じコード・行番号を読めます。
入口は pstack/skills/poteto-mode/SKILL.md の Playbooks節・L121–149 です。指示の一部を抜き出すと、次の言葉があります。
Match the task to a playbook below
自転車店で修理を引き受けたあと、該当する作業手順を開くのと同じです。仕事の種類を選べたことと、必要な工程を読んだことは別です。
続く指示もこの順序です。索引を見ただけで作業したことにはしません。
pstack/skills/
poteto-mode/SKILL.md 入口・適用条件・索引
poteto-mode/playbooks/bug-fix.md バグ修正の工程
how/SKILL.md 仕組みを調べる技法
principle-prove-it-works/SKILL.md 完了を判断する原則
たとえば Bug fix・L7–15 には、実際の操作面での再現、原因の絞り込み、修正の計画、同じ操作面での検証が並びます。ブラウザの問題ならブラウザ、文字でコマンドを入力するCLIの問題ならCLIが対象です。
原本には変更履歴を記録するGitや、変更の取り込みを提案するPRの工程もあります。本講座の演習ではそれらを実行しません。外部の手順書は利用環境の権限や依頼範囲を広げる許可にはならないためです。
Step 4：いつもの頼み方と何が違うのか
ここで比べるのは、手順や合格条件を決めず、その都度AIへ頼む使い方です。従来の開発全体との比較ではありません。
手順は poteto-mode・L121–133、完了の判断は principle-prove-it-works・L9–22、再発防止は correct・L13–30 に書かれています。後の回で順に読みます。
この設計では、AIの答えだけでなく仕事の進め方も点検できます。「原因を調べるだけか、修正まで行うか」「何を見れば完了か」を、手順と照らして確認できます。
pstackを使うときは、工程を毎回細かく指定する必要はありません。公式ガイド・L42–59も目的・完了条件・制約を伝え、進め方はPlaybookに任せる使い方を勧めています。
小さな質問なら、短い依頼で十分なこともあります。pstackの導入だけで、AIが正しく動く保証はありません。
注意
ただし、文章だけでは強制できない
/poteto-modeのルーティングは、モデルがMarkdownの指示を読んで判断する仕組みです。Markdownは、見出しや箇条書きを文字で書ける文書形式です。指示文はプログラムの分岐のように同じ結果を保証しません。依頼が曖昧な場合や、複数の仕事を含む場合は、手順を選んだ理由と作業範囲を確かめます。
Step 5：Codexで選び方を試す
以下はpstackの移植ではなく、選択の考え方を試す演習です。長めの指示はCodexで選び方を観察するための教材用です。新しいチャットを二つ用意し、同じ3件を渡します。一方は「各依頼の進め方を提案して」とだけ頼み、もう一方では次の指示を加えます。
次の依頼を分類し、最初の行動を一つずつ提案してください。
コード変更・コマンド実行・外部アクセスはしないでください。
A. ログイン処理がどう動くか、説明して。
B. ログインボタンが反応しない不具合を直して。
C. ログイン画面にパスワード再設定の導線を追加して。
候補は Investigation / Bug fix / Feature。
どれも合わなければ、その理由を書いてください。
依頼ごとに「選んだ手順・理由・最初の行動・完了条件」を示してください。
| 見る項目 | 確かめ方 |
|---|---|
| 目的との一致 | Aは説明、Bは不具合解消、Cは新しい操作になったか |
| 範囲の遵守 | 提案だけで止まり、変更を始めなかったか |
| 検証可能性 | 何を見れば完了かが具体的か |
両方の回答を比べたら終了です。正しく分類できたことだけでは、実際の修正能力やpstack全体の効果は評価できません。
セルフチェック
1. 『保存処理の仕組みを説明して。コードは変えないで』という依頼に合う進め方は？
今回持ち帰るもの
共通の架空例について、依頼を次の3点で整理できれば一区切りです。
- 仕事：原因を説明するInvestigation。
- 範囲：読み取り専用。コード変更や修理はしない。
- 完了条件：説明の根拠と、まだ分からない点を示す。
原因が分からなければ、分かったふりをせず不明点を残します。この時点で「直った」とは判断しません。
今日のまとめ
Routing：依頼の目的と範囲から手順を選ぶ。
Playbook：選んだ手順の全文を読む。
境界：手順書があっても、許可されていない操作は行わない。
次回の問いは「手順を選んだあと、どこまで情報を読ませればよいか」です。