poteto-help

Poteto のヘルプ

pstack についてのユーザーの質問に答え、そのまま送信できるプロンプトを渡し、回答の出典ファイルへのリンクを示します。ヘルプに関する質問では、作業を開始しないでください。ユーザーが尋ねているのは方法であり、pstack の実行には実際にトークンを消費するため、ユーザー自身にプロンプトを送信してもらいます。

「pstack を使ってこのバグを修正して」のように作業を依頼するメッセージは、ヘルプに関する質問ではありません。poteto-mode を読み、その指示に従って作業し、カスタムモードを使うとこの設定を維持できることを一度伝えてください。

このファイルでは、質問と回答を記載したスキルおよびガイドページを対応付けています。詳細は、それらのファイルに記載されています。案内先のファイルを引用する前に読み、内容がこの対応表と異なる場合は、そのファイルを優先してください。ここにあるリンクはインストール済みプラグイン内を指しているため、ユーザーが開けない場合があります。そのため、https://github.com/cursor/plugins/blob/main/pstack/ に続けてパスを加えた、一般公開されているファイルへのリンクをユーザーに提示してください。

必要なことを確認する

メッセージと会話の内容から、必要なことを判断してください。「PR をレビューするスキルはどれ？」のように状況が明確な場合は、該当するセクションに直接進んでください。必要なことがまだ不明な場合は、次の選択肢から選ぶ形式の質問を 1 つ行い、ユーザーが選んだセクションだけに答えてください。

• セットアップする
• /poteto-mode でタスクを開始する
• 状況に合ったスキルを選ぶ
• うまくいかなかった実行を修正する
• pstack を自分向けにカスタマイズする

回答が変わる状態を確認し、該当する場合にのみ伝えてください。

• ~/.cursor/rules/pstack-models.mdc がない場合、このユーザーは /setup-pstack を実行していないため、すべてのロールでデフォルトのモデルが使われます。
• プロジェクトに verify-* スキルやその他のアプリ用ハーネスがない場合、エージェントがアプリを操作するスクリプトを使った方法はありません。変更が機能することの確認について質問された場合は、/create-verification-skill に言及してください。
• プロジェクトに形式検証スキルがない場合、テストで到達できる範囲を超えて検証されるプロパティはありません。競合、不変条件、またはテストでほとんど確認されない別のケースについて質問された場合は、/create-formal-verification-skill に言及してください。形式検証スキルがあり、その対象となるコードが、最後に同期済みとして記録されたコミット以降に変更されている場合、そのコードに関する質問には /maintain-formal-verification-skill にも言及してください。

モデルルールがなく、それが重要な場合は、ロールごとのモデルと推論予算を今選びたいかどうか、ユーザーに尋ねてください。ユーザーが初めての場合、セットアップやコストに関する質問の場合、またはどのモデルが実行されるかによって答えが変わる場合に重要です。1 回のチャットで尋ねるのは 1 度までです。必要なことも不明な場合は、2 つの質問をまとめて尋ねてください。選択肢は 2 つ提示します。

• 今：入力する /setup-pstack を案内し、質問にも答えます。
• 後で：質問に答え、/setup-pstack を実行するまではすべてのロールでデフォルトのモデルが使われることを 1 行追加します。

セットアップする

1. チャットで /add-plugin pstack を実行するか、サイドバーの「カスタマイズ」からインストールします。
2. /setup-pstack を実行します。推論予算を尋ね、各ロールにモデルを割り当てて、ルールを書き込みます。このルールは新しいチャットに適用されます。その後、プロジェクトにまだない場合は、検証スキルと形式検証スキルをそれぞれ一度だけ生成するかどうかを提案します。
3. /poteto-mode、目標、そして成功か失敗かを判定できる確認方法を指定して、実際のタスクを始めます。

ユーザーがスキルを呼び出すまでは、インストールによって何も変更されません。ユーザーの言葉から読み込まれるのは /setup-pstack だけです。詳細は README と ガイドのページ 1 をご覧ください。references/prompting.md に沿って、最初のプロンプトを一緒に考えることを提案してください。

コストが心配なら、トークンがどこで使われるのか、どうすれば節約できるのかを説明してください。pstack はサブエージェントとレビュー用パネルで追加のトークンを使います。/setup-pstack を再実行して、予算を少なくするか、より安価なモデルを選んでください。ロールを auto または inherit-parent に設定すると、チャットのモデルで実行されます。チャットが Auto またはより安価なモデルで実行されていれば、トークンを節約できます。パネルの数を減らすと、エントリーごとに 1 つずつ実行されるサブエージェントの数も減ります。厳密さが必要な作業には /poteto-mode を使ってください。

pstack は Cursor 向けに作られています。また、Claude Code でも /plugin marketplace add cursor/plugins を実行し、その後 /plugin install pstack@cursor-plugins を実行してインストールできます。Claude Code では、各コマンドに /pstack:poteto-mode のように pstack: を付けます。Claude Code アダプター が Cursor の名称に対応付けます。また、Bugbot や Automations など Cursor 専用の機能を必要とする手順は、1 行の注記を添えてスキップされます。

他のツールでも、Agent Skills 形式を使っているため、スキルを読み込めます。ただし、/poteto-mode、/how、/why、/teach など、ほとんどのワークフロースキルはロールごとにモデルを指定して Cursor のサブエージェントを起動します。また、Custom Modes と /loop は Cursor の機能です。そのため、これらの部分は他のツールでは動作しない場合があります。

/poteto-mode でタスクを始める

/poteto-mode はタスクに合ったプレイブックを選び、その手順を ToDo リストにコピーして、手順に応じて他のスキルを実行します。スキップした手順は skip: <reason> としてリストに残ります。よいプロンプトには、目標と完了したことを判断する方法が書かれています。スキルを列挙する必要はありません。手書きの手順は、プレイブックに残されている手順を省略したり、順序を入れ替えたりしがちだからです。プロンプトの作成を手伝う前に、references/prompting.md を読んでください。例はガイドのページ 2 にあります。

/poteto-mode が有効なままになるかどうかは、ユーザーの起動方法によって異なります。

• /poteto-mode に続けて Enter を押すと、そのメッセージ 1 件にスキルが適用されます。チャットが進むにつれて、適用は解除されます。
• Mac では Option+Enter、Windows では Alt+Enter を押すか、スキルの項目から「モードとして使用」を選ぶと、Custom Mode になります。ユーザーがモードを終了するまで、ターンごとにコンテキスト内で有効になり、カジュアルなターンには適用されません。
• Cursor のドキュメントでは、Agents Window と CLI に Custom Modes が掲載されています。それ以外の環境では、新しいタスクごとに /poteto-mode を開始してください。

この話題が出たら、Cursor のスキルに関するドキュメント にリンクしてください。チャットの途中で「新しいタスク」と指定すると、モードは新しいプレイブックに合わせて動作します。/poteto-mode は、プレイブックの手順で起動するサブエージェントにすでに poteto-agent を使用しています。自分で起動したサブエージェントにも同じスタイルを適用するには、subagent_type: "poteto-agent" を指定して起動してください。

スキルを選ぶ

デフォルトの回答は /poteto-mode です。手順で必要になれば、他のほとんどのスキルも実行します。プレイブックより多く、または少ない内容をユーザーが求める場合は、スキルを直接指定してください。推奨する前にスキルを読み、プロンプト例を 1 つ示してください。

ユーザーの目的	スキル
手間のかかるタスクを厳密に進める	/poteto-mode
作業を始める前に、エージェントが目標と問題を理解しているか確認する	/in-your-own-words
プロンプトを送信する前に、内容を増やすのではなく掘り下げて書き直す。トップクラスの専門家なら何を加えるか、その専門家の素材や手法、第三者による確認を盛り込む。プロンプトを返し、タスク自体は実行しない	/sharpen
コードが現在どのように動作するか、または新しいコードをどこに配置すべきかを知る	/how
コードがこの形になっている理由や、数値の出所を知る	/why
変更やサブシステムについて、平易な説明で理解する	/teach
特定のトピックに関する最近の自分の作業を振り返る	/recall
前回のメッセージ以降、このチャットで変わったことを、平易な言葉と簡単な図で把握する。自分の対応待ちの項目をすべて列挙し、返信だけで判断できるようにする	/ketchup
/ketchupと同じように状況を把握する。ただし、短い無音のスライド動画で示し、対応待ちの項目は動画の下にテキストで表示する	/ketchup-video
小さな差分が、差分の範囲外で何を壊す可能性があるか把握する	/blast-radius
関数の境界をまたぐコードを書く前に、型とモジュールの構成を決める	/architect
1つの依頼に対して複数の案を試し、最良の案にまとめる	/arena
範囲ごとに並行してチェックする、またはワーカーを競わせる。クラウドエージェントとして実行する	/swarm
複数のモデルに差分をレビューさせ、問題点を探させる	/interrogate
手軽なローカルテストがある場合に、テストを先に書いてバグを修正する	/tdd
.tsまたは.tsxの作業にTypeScriptのルールを適用する	/typescript-best-practices
執筆者とは別のレビュアーを使い、レビュー前にコメントを取り除く	/no-comments
文章からAIらしい特徴を取り除く	/unslop
ドキュメント、RFC、README、PRの説明、コミットメッセージを一定の品質基準で書く	/technical-writing
直前の返信を平易な言葉でもう一度聞く	/bro
エージェントがアプリを操作し、動作を証明するためのスクリプト化された方法を用意する	/create-verification-skill
検証スキルとその機能マップを、アプリの現状に合わせて更新する	/maintain-verification-skill
テストではほとんど到達できない競合状態、不変条件、その他の性質を形式検証する	/create-formal-verification-skill
対象コードの変更後に形式検証を現状に合わせ、失敗が乖離によるものかバグによるものかを調べる	/maintain-formal-verification-skill
モデルで検証したチャートとして、ユーザーに表示される内容をPMやデザイナーに示す。各バグを番号付きの経路として描画する。合意したチャートをTLA+のスケルトンにする。またはコードをTLA+仕様と照合する	/statechart
報告または対応の前に、パフォーマンスの数値を検証する	/benchmark-checklist
大規模な変更、広範囲に影響する変更、または時間を置いてからレビューする変更に取り組む	/figure-it-out
作業中に判断ログを記録し、終了後に振り返る	/show-me-your-work
役割ごとのモデルと推論予算を選ぶ	/setup-pstack
自分の作業習慣を、個人用のモードスキルにする	/automate-me
完了したタスクから得た学びを、スキルの編集に反映する	/reflect
このリポジトリでエージェントが同じ間違いを繰り返さないようにする	/correct
Webhook経由でGrok Botを起動するボタン付きのページを作る	/make-bot-ui
pstackの使い方を知る	/poteto-help
このディレクトリと同じ階層にあるスキルディレクトリが表にない場合は、frontmatterを読み、その説明に基づいて振り分けてください。principle-* ディレクトリは、下記の原則に含まれます。

迷いやすいもの：

• /how はコードの動作を説明します。/why はその理由を説明します。/teach はどちらか一方、または両方を実行し、結果を平易に説明します。
• /arena はすべてのワーカーに同じ依頼内容を渡し、最善の部分を統合します。/swarm は作業を分割するか競争形式にし、1つのレポートを返します。
• /architect は設計を決めた直後に実装します。コードを書く前に設計をレビューするには、「with checkpoint」を追加してください。
• /interrogate は差分をレビューします。/blast-radius は差分の範囲外で起きる問題を探し、変更が安全であることを裏付ける事実を1つ確認します。
• /recall は最近のチャットをまたいでコンテキストを再構築します。/ketchup が扱うのは、ユーザーの最後のメッセージ以降のこのチャットだけです。特定のチャットまたはブランチを再開するには、Session pickupプレイブックを使います。
• /figure-it-out は、厳密な1回の実行を設計します。Orchestrateプレイブックは、数日間にわたり多数のPRをまたぐプログラムを実行します。Autonomous runプレイブックは、タスクを完了条件まで進めます。

pstackに含まれないもの：

• /deslop、control-cli、control-ui は cursor-team-kit プラグインに含まれます。
• /loop と /create-skill はCursorの組み込み機能です。
• pstackには /orchestrate スキルはありません。Orchestrateは /poteto-mode のプレイブックです。スラッシュメニューに /orchestrate が表示される場合は、別のプラグインが提供しています。

プレイブックと原則

プレイブックは /poteto-mode 内の手順リストであり、スキルではないため、スラッシュコマンドはありません。/poteto-mode 内では、タスクの説明に基づいてプレイブックが選ばれます。また、次のフレーズを使うと特定のプレイブックを直接指定できます。

• 「babysit this pr」または「check on pr 123」はBabysitを実行します。PRをマージ可能な状態まで進め、そこで停止します。ユーザーがマージ、取り込み、またはリリースを依頼しない限り、マージはしません。
• 「land the stack」はShippingを実行します。
• 「take over this branch」はSession pickupを実行します。
• 「pause safely」はPause safelyを実行します。
• 「full autopilot on this queue」はAutopilot-fullを実行します。「stack them, don't ship」はAutopilot-stackを実行します。
• 「run the eval playbook」はEvalを実行します。

/poteto-mode を使わない場合、「babysit this pr」のようなフレーズで、同じ作業を行うCursor独自のスキルが起動することがあります。poteto-mode の「Playbooks」セクションには、すべてのプレイブックと適用条件が記載されています。ガイドの6ページでは、PRの作成、進捗確認、取り込みについて説明しています。

pstackには計画用のスキルはありません。CursorのPlan Modeはpstackと併用できます。複数のフェーズや積み重ねたPRにまたがる作業の場合、/poteto-mode に計画を依頼すると、Multi-phase planプレイブックが計画を作成しますが、実装はしません。設計上の疑問については、Prototypeプレイブックまたは /architect が、まずコードで解決します。

原則は、/poteto-mode が読み込み、返信で引用する、1つのルールに特化したスキルです。ユーザーが原則を直接呼び出すことはほとんどありません。代わりに、「apply prove it works. show me the real output.」のように、原則の名前を使って指示します。/principle-<name> と入力すれば、引き続き必要に応じて原則を読み込めます。ガイドの8ページに、原則の一覧があります。

うまくいかなかった実行を修正する

症状	修正方法
数ターン後にモードが適用されなくなった	Enter で開始されています。カスタムモードとして開始するか、各タスクの開始時に /poteto-mode を実行してください。
質問が前のタスクの続きとして扱われた	「新しいタスク」と伝えるか、そのターンではモードが不要だと伝えてください。
新しいモデルを選んでも反映されなかった	/setup-pstack のルールは新しいチャットに適用されます。新しいチャットを開始してください。
実行コストが予想より高かった	「セットアップ」のコストに関する段落を参照してください。
スキルが自動で読み込まれなかった	ユーザーの言葉から読み込まれるのは /setup-pstack だけです。それ以外は、ユーザーが入力したとき、または /poteto-mode が実行したときに読み込まれます。ただし、すべてのスキルが実行されるわけではありません。
並列エージェントがお互いの変更を上書きした	各エージェントに専用の worktree を割り当てるか、それぞれ専用のマシンが割り当てられるクラウドエージェントとして実行してください。
一晩の実行で進んだものの、何も完了しなかった	/loop には所要時間ではなく、成功または失敗を判定できるチェックが必要です。ガイドページ 7を参照してください。
ビルドが成功しただけで、完了したと返答された	実際のコマンド、フロー、保存された値、またはプロファイルを確認するよう依頼してください。これが「動作を証明する」原則です。

実行が脱線した場合は、references/prompting.md に一行で指示を修正する方法があります。ガイドページ 10には、ほかの落とし穴と、コピーして使えるレシピが記載されています。

pstack を自分向けにする

• /automate-me は、ユーザー自身の履歴から個人用モードスキルの草案を作成します。/poteto-mode と併用できます。
• セッション後に /reflect を使うと、そこで得た教訓が、ユーザーの承認を得てスキルの編集に反映されます。
• /poteto-mode write a skill for <workflow> は、スキル作成用のプレイブックを実行します。評価用プレイブックでは、スキルの変更をブラインドテストします。
• 問題のあるスキルは、問題が起きた機能の作業に含めず、独自の PR で修正してください。

ガイドページ 9で、これらすべてを説明しています。

返答

まず答えを述べてください。コードブロック内のプロンプト例は最大 1 つにし、適したものがあれば references/recipes.md を参考にして調整してください。その後にこのファイルへのリンクを示してください。ユーザーが全体像を求めていない限り、簡潔にしてください。