pstack は、AIの生成量より調査・設計・検証の深さを重視する Cursor プラグインである。中心の
/poteto-modeが依頼を22種のプレイブックへ分類し、個別スキルと21の設計原則を組み合わせて実行する。
| 項目 | 内容 |
|---|---|
| 提供者 | Lauren Tan（poteto） |
| バージョン | 0.14.5（2026-08-29確認） |
| ライセンス | MIT |
| 公式 | cursor/plugins — pstack |
| 参照コミット | 68836ddaf5697224520f1847d90cdb90ca8babaa |
/add-plugin pstack
/setup-pstack
/poteto-mode <依頼内容>
通常は /poteto-mode だけを入口にすればよい。目的が明確な場合は、以下のスキルを直接呼び出せる。
- 目的: 非自明な仕事の標準入口として、調査から検証・出荷までの進め方を統一する。
- 処理: 依頼に合うプレイブックを選び、TODOを作成し、
how、why、architect、tdd、interrogateなどを必要な段階で呼び出す。 - 特徴: 一度有効にすると後続ターンでも継続する。最小変更、根本原因、実物による検証を一貫して求める。
| 分類 | プレイブック |
|---|---|
| 調査・診断 | investigation、bug fix、perf、hillclimb、runtime forensics、trace forensics |
| 開発 | feature、refactoring、prototype、visual parity |
| スキル品質 | authoring a skill、eval |
| 運用・出荷 | babysit、shipping、autonomous run、orchestrate、autopilot-full、autopilot-stack |
| 継続・保守 | session pickup、pause safely、multi-phase plan、worktree cleanup |
- 目的: サブシステムが何で構成され、実行時にどう動くかを説明する。
- 処理: 複雑な質問ではコード探索を並列化し、入口、データフロー、所有関係、層の境界を統合する。必要なら複数の批評役に構造を評価させる。
- 用途: オンボーディング、変更前の理解、コードの配置・所有・レイヤー判断。設計理由を調べる場合は
/whyを使う。
- 目的: 「なぜこの形になったか」を、コード形状からの推測ではなく履歴と記録から明らかにする。
- 処理: 対象をgit・PRで特定し、利用可能なMCPを検出。ソース管理、Issue、文書、チャット、可観測性、エラー追跡、分析基盤を証拠カテゴリ別に並列調査する。
- 出力: 直接確認できた事実、合理的な推論、競合する仮説、不明点、調査した情報源を分離し、確信度に合う表現と出典を付ける。
- 目的: 会話履歴、共有記録、現在のGit・PR状態から、あるテーマの現在地を復元する。
- 処理: 既定では直近7日・現在のワークスペースに範囲を固定し、会話ログを並列検索する。機能やバグが指定された場合は
/whyの情報源調査も併用する。 - 出力: 最大5項目の要約、各作業の状態、繰り返す問題、次に行うべき1つの行動。
- 目的: 対象が何であり、どう動き、なぜそう作られたかを一続きの説明にする。
- 処理:
/howと/whyを実行し、読み手の目的に合わせて組み直す。要素が多い場合は、一要素ずつ追加する段階的な図を使う。 - 注意: 関数一覧や講義調の演出を避け、実際に何が起きるかを説明する。
/whyの確信度表現は崩さない。
- 目的: 利用側、型、シグネチャ、クラス、モジュール境界をコード実装前に固める。
- 処理:
/howと必要に応じて/whyで現状を把握し、/arenaで少なくとも2つの異なる案を比較。利用側の書き方から型と構造を導く。 - 判断: 実装中に同型の回避策、キャスト、特例が繰り返される場合は、継ぎ足さず設計を破棄してやり直す。
- 目的: 差分の外側で壊れる利用箇所、暗黙の契約、生成物、キャッシュ、運用フローを見つける。
- 処理: 変更シンボルから呼び出し元、データ消費者、テスト、設定、永続化、並行処理を追跡する。
- 完了条件: 重要な安全性の根拠を1つ選び、説明だけでなく実コードを動かして証明する。
- 目的: 既存プレイブックに収まらない大規模・複合的な仕事へ、監査可能な手順を作る。
- 処理: 完了条件と制約を定義し、調査・仮説・実験・判定のループを構築。
/show-me-your-workに判断を記録し、証拠に応じて手順を更新する。 - 用途: 大規模移行、複数領域の変更、人が離席している間の長時間タスク。
- 目的: 最初の案へ固定せず、同一課題の複数完成案から最良の成果物を作る。
- 処理: 3〜6個の採点基準を作り、複数モデルへ同じ依頼を渡す。全案を読み、別モデルの審査も加えて土台を選び、他案の強い部分だけを統合する。
- 出力: 統合成果物と、採用案、移植要素、却下理由、脱落、検証結果を記した合成メモ。
- 目的: 対象を分割して網羅するか、同じ課題を競争させ、結果を1つの報告へ集約する。
- 処理: 完了条件、分割方法、ワーカー数、選考方式を先に決める。各ワーカーへ独立した依頼と出力先を与える。
- 使い分け:
arenaは同じ成果物の複数案を統合する。swarmは異なる範囲の結果を集約する。
- 目的: 不具合、設計上の弱点、保守性の問題を複数の独立視点から探す。
- 処理: 差分と意図を固定し、複数モデルへ異なるレビュー観点を割り当てる。親エージェントが指摘を再確認し、重複と誤検知を除く。
- 出力:
Act On、Consider、Noted、Dismissedに分類した指摘と、レビュアー間の一致状況。
- 目的: 修正前に失敗し、修正後に成功する回帰テストを証拠として残す。
- 処理: 最小の再現テストを追加し、意図した理由で失敗することを確認してから、最小の本体変更と周辺検証を行う。
- 注意: 高価な基盤や壊れやすいモックが必要ならテストを無理に作らず、スクリプトや手動再現など最も近い実行可能な検証を使う。
- 目的: コードを言い換えるコメント、古い説明、回避策を正当化するコメントを削る。
- 処理: 読取専用の Comment Sicko が差分を評価し、親が指摘を検証。不要コードの削除や正しいAPI利用など、根本原因を最小変更で直す。
- 制約: 「削除禁止」などの主張は、型、実行時検査、テスト、CI lintへ置き換えられないか検討する。
- 目的: UI、CLI、サービスを利用者と同じ方法で操作し、機能を証明するプロジェクト専用スキルを生成する。
- 処理: リポジトリから起動方法と操作面を調査し、起動、健康診断、操作、証拠保存、終了処理、機能マップを作る。
- 完了条件: 生成したスキル自身で代表機能を実行し、証拠の保存とクリーンアップまで確認する。
- 目的: アプリ変更によってずれた検証手順、ハーネス、機能マップを監査する。
- 処理: 機能ごとにソースを並列確認し、コーディネーターが全機能をライブ操作する。文書・ハーネスのずれは直し、製品不具合は報告だけに留める。
- 結果:
clean、changed、blockedのいずれか。編集範囲は検証スキルのディレクトリ内だけ。
- 目的: 長時間・無人作業で、何を、なぜ選び、どの証拠で判定したかを監査可能にする。
- 処理:
ts / phase / decision / why / evidence / resultのTSVへ判断だけを追記し、終了時に会話ログと突き合わせる。 - 規律: 追記専用。通常はローカルに置き、大規模案件だけコミットする。最後に別モデルが証拠の弱さや検証漏れをレビューする。
- 目的: 実装、判断、調査、レビューパネルなどに使うモデルを環境へ合わせる。
- 処理: 利用可能モデルと既存設定を検出し、役割マッピングを検証して常時適用ルールへ書く。
- 特徴: 未指定の役割は既定値へ戻る。
inherit-parentまたはautoで親チャットのモデルを使える。
- 目的: 応答形式、委譲、検証基準、コード規律、Git運用などを
<name>-modeとして永続化する。 - 処理: 現在のワークスペース内の会話履歴を分割分析し、複数回現れた傾向とユーザー回答を統合。
create-skillと/unslopでスキル化する。 - 注意: 一度だけの発言へ過剰適合せず、そのユーザー固有の運用規則だけを残す。
- 目的: 成功手順、失敗経路、ユーザーの修正を、次回も使える既存スキル改善へ変える。
- 処理: 現在の会話を3モデルで並列レビューし、提案を統合。文章の追記だけでなく、lint、スクリプト、メタデータなど構造的な強制手段を検討する。
- 注意: 一度限りの出来事や、既存スキルが正しく処理できていた内容は新しい規則にしない。
- 目的: 不正状態や値の取り違えを型で表現不能にする。
- 推奨: 判別共用体、ブランド型、構成的モデリング、
unknownの境界検証、網羅性、satisfies、既存スキーマからの型導出。 - 回避: optionalフィールドの寄せ集め、検証なしの
as、any、嘘をつく型ガード、出荷コードのconsole.log。
- 目的: 抽象的な賛辞、重複、過剰な見出し、対句、定型的な導入・結論を削り、具体的で自然な文章にする。
- 処理: 事実と論理を保ち、不要な予告、言い換え、強調、メタ発言を除く。抽象名詞を具体的な主体と動作へ変える。
- 注意: 無味乾燥にはせず、根拠のある判断と書き手固有の視点は残す。ただし体験や感情を捏造しない。
- 目的: 直前の回答を、専門知識がない人にも分かる日常語で言い直す。
- 処理: 新しい調査や内容追加は行わず、意味を保って用語、抽象表現、複雑な構文を簡単にする。
- 出力: 言い直した本文のみ。変換手順や前置きは付けない。
- 目的: 文書の目的と読者に合う構造を選び、読み違えにくい技術文へ編集する。
- 処理: Diátaxisで文書種別を分け、Google developer style、Simplified Technical English、Global Englishの規則で動作・語彙・構文を明確にする。
- 対象: 文書、RFC、README、PR説明、コミットメッセージ。リポジトリ固有の用語と文体は一般ルールより優先する。
- 目的: ボタンやダッシュボードからJSONを送り、Grok Botのルーチンを起動するローカルUIを構築する。
- 処理: Webhookルーチンを作り、ローカルサーバーが認証付きPOSTを中継する。必要ならTailscale上へ公開し疎通確認する。
- 安全性: sender keyはブラウザー、チャット、ログへ出さず、サーバー側に保持する。Webhook本文は外部入力として扱い、命令として信用しない。
以下の21スキルは、通常は利用者が直接呼び出さず、/poteto-mode や個別スキルが判断基準として参照する。
削除と、問題を解く最小の変更を優先する。新しい抽象化や層を足す前に、既存構造を減らせないか考える。
ロジックの前に中心の型、データ構造、共有状態、作業順序を決め、後続コードが自然に決まる土台を作る。
新要件を継ぎ足さず、その要件が初日から存在していた前提で全体を設計し直す。
追加や書き直しの前に、死んだコード、重複検証、仮の参照を除き、単純な土台から始める。
答えまでの層と、読み手が保持する隠れた状態を減らす。1利用者だけのラッパーや広い可変状態を縮小する。
移行のフェーズ境界を明示し、一時的な互換コードを増やさず最終構造へ収束させる。
実装都合より利用体験を優先し、粗い機能を多く出すより少数の完成度を上げる。
前例のないUIや設計では、2〜3個の構造的に異なる試作を比較してから決める。
手作業を繰り返さず、codemod、スクリプト、生成器、検証スキルなど再実行可能な道具を成果物にする。
状態や形の前提を条件分岐へ散らさず、ドメインの構造として表現する。
検証と変換をCLI、設定、ネットワークなどの外部境界へ集め、内部ロジックでは型を信頼する。
不正状態を型で表現不能にし、外部データは境界で解析する。キャストで型検査を回避しない。
クラッシュ、再起動、再試行、部分実行が起きても、同じ最終状態へ収束する操作を設計する。
利用側の移行と旧API削除を同じ波で行い、恒久的な互換層を残さない。
共有状態をロックする前に共有自体をなくす。単一書き込みが真の不変条件である場合だけ直列化する。
完了前に機能、実値、差分など最終成果物そのものを確認する。コンパイル成功や自己申告は代理指標にすぎない。
症状を再現し、「なぜ」を繰り返して原因へ到達する。症状だけを黙らせるガードを避ける。
移行や反復編集を、各段階で検証できる小単位に分け、コミットやPRも正しさが積み上がる順にする。
大量出力や長い探索はサブエージェントへ任せ、主スレッドには生データではなく要約を戻す。
元に戻せる作業は許可待ちで止めず結果を提示する。確認は不可逆操作など本当に必要な場合に限る。
同じ指示が繰り返される場合、文章ではなくlint、メタデータ、実行時検査、スクリプトとして守らせる。
- poteto-agent:
poteto-modeと原則索引をすべて適用するサブエージェント。 - Comment Sicko: コメントの必要性を厳しく評価する読取専用サブエージェント。通常は
/no-comments経由で使う。 - benny: Slackの不具合報告を分類し、確認できた不具合をUI証拠付きで再現・修正する自動化パック。初期状態では無効。
/deslop、control-cli、control-uiは別のcursor-team-kitプラグインに含まれる。/create-skillはCursor組み込み。- Cursor組み込みの
/babysitもあるが、pstackではpoteto-modeのbabysitプレイブックがPR状態確認を担当する。
本資料は2026-08-29時点の公式リポジトリを、SHA-1 68836ddaf5697224520f1847d90cdb90ca8babaa に固定して要約した。リンク先はこのコミット時点の内容であり、main の更新によって変化しない。