pstack-claude：Cursorのスキルスタックを複数のコーディングエージェントへ移植

背景と課題の所在

コーディングエージェントの性能はこの一年で大きく向上しました。それでも、同じモデルがタスクごとに大きく異なる振る舞いを見せます。多くの場合、弱点はモデルではなく手順にあります。故障を再現する前にコードを書き換える。証拠を確かめずに修正済みと宣言する。小さな変更が広範なリファクタリングに膨らむ。pstack が狙うのは、この手順の欠落です。

README によると、Lauren Tan 氏の pstack は、エージェントの成果を高めるための、意見のはっきりした Cursor 向けスキルスタックです。pstack-claude はその移植版で、Claude Code、Codex、Pi などのエージェント環境を対象にします。リポジトリの説明には OpenCode、Gemini、Prime Agent も挙がっています。移植の難所は文章の複製ではありません。Cursor が持つサブエージェント、質問、ウェイクアップといったプリミティブを、他の環境の対応物へ置き換えることです。リポジトリは「Cursor primitives translated for other harnesses」と説明しています。

これは現実的な課題です。チームは複数のエージェントツールを併用することが多く、それぞれスキルの形式も呼び出し方も違います。優れたワークフローが一つのエディタに縛られると、知見を再利用できません。移植版なら、同じ手法を環境をまたいで一貫して動かせます。なお、本稿は README の読解に基づきます。実際に導入して動かしたわけではないため、効果に関する記述は設計の分析であり、実測結果ではありません。

コアアーキテクチャと技術原理

README から、構成を四つの層として読み取れます。 第一の層は入口となるスキル poteto-mode です。たとえば「ページを切り替えると検索フィルターがリセットされる問題を直して」と目標を伝えると、適切なワークフローを選びます。README は、コードを簡潔で単純に保ち、検証済みにすると述べています。SKILL.md には、計画、機能開発、リファクタリング、性能問題、調査、プロトタイプ、PR の保守、リリース、長期プロジェクトのプレイブックが載っています。 第二の層は、組み合わせ可能なスキル群です。README の例には `how`、`why`、`architect` が出てきます。バグの場合の流れは次のとおりです。まず故障を再現します。次に `how` と `why` で調査します。修正を委任します。最後に、失敗していたケースを再実行します。修正が関数の境界をまたぐ場合は、実装の前に poteto-mode が `architect` を呼びます。利用者に届くのは、修正そのものと、失敗時と成功時の証拠です。この「証拠が先」という納品の形が、設計の中で最も価値のある部分です。

第三の層は、各実行環境への適合です。Claude Code ではプラグインマーケットプレイス経由で、`/plugin marketplace add michael-denyer/pstack-claude` と `/plugin install pstack@pstack-claude` を使います。Codex は `codex plugin marketplace add` と `codex plugin add` です。Pi は `pi install git:github.com/michael-denyer/pstack-claude` を使います。Pi ではパッケージが pstack 拡張も読み込み、サブエージェント、質問、ウェイクアップの各ツールと、`/loop` コマンド、ルーティング指示を追加します。つまり、この移植はスキルの文章を運ぶだけではなく、プリミティブが足りない環境には実装を補っています。 第四の層は、ポリシーと設定です。移植版は上流を追跡しつつ、名前付きのポリシーフォークを持ち、それぞれ `tools/forks.json` に宣言されています。`setup-pstack` スキルでモデルの既定値を変え、ロールごとに推論強度を設定できます。README の例は `arena runners: opus @xhigh, fable @max` です。Claude Code では、こうした設定がプラグインの `pstack:effort-` または `pstack:poteto-agent-` エージェント経由で振り分けられます。強度を指定しないロールはセッションの強度を引き継ぎます。ただし、設定シートの `default effort` 行に指定があればそれに従います。自動ルーティングは無効にもできます。

実用性と検証結果

注目すべき機能は三つあります。 一つ目は自動ルーティングです。Claude Code と Codex では、プラグインがルーティングフックを導入し、受けたタスクをまず poteto-mode に通します。Codex では、実行前に `/hooks` からそのフックを信頼する操作が必要です。フックはエージェントの挙動を変えるため、黙って有効にしないという点で、妥当な安全設計です。Pi では、拡張が同じルーティング指示を注入します。 二つ目は、ロールごとのモデルと推論強度の設定です。高コストで強い推論を必要なロールだけに割り当て、残りは低い強度で動かせます。品質とコストのバランスを細かく調整できます。 三つ目は、データの扱いの境界です。README は、pstack にはサーバーもテレメトリーもないと明記しています。スキルがエージェントに読ませる内容は、セッションの記録も含めて、利用者のモデル提供元に送られます。スクリプトはローカルで動き、PR 関連のツールは利用者の GitHub CLI のログインを使います。「データはマシンの外に出ない」とは約束せず、データの行き先を正直に書いている点が率直です。

使いどころとしては、失敗するテストケースとして書けるバグのように、受け入れ基準が明確なタスクに向いています。要件が曖昧な探索的な作業には、計画や調査のプレイブックのほうが合います。限界も述べておきます。手順が厳しいほど、一つのタスクに必要な呼び出しと時間が増えます。成果は、基盤モデルが指示に従う力に左右されます。プリミティブの翻訳がすべての環境で完全に等価かどうかは、利用者が自分の環境で確かめる必要があります。執筆時点でリポジトリのスターは約 1,194 です。再現可能な比較評価は見つからなかったため、成果がどれだけ改善するかについては結論を出しません。

業界への影響と今後の展望

pstack-claude は、形を成しつつある流れを映しています。スキルとワークフローが、特定のエージェント製品から独立した、持ち運べる資産になりつつあるのです。かつてプロンプトや手順は、一つのエディタの設定に閉じていました。今は、プラグインマーケットプレイス、スキルのディレクトリ、フックの仕組みが複数のツールで似た形を取り、「一度書いて、複数の場所に入れる」ことが現実的になっています。 また、上流と下流を並べて維持する方法も示しています。移植版は上流を追跡し、自分のポリシーの違いを `tools/forks.json` の明確な一覧に書き出します。黙って手を加えるより透明で、利用者は自分がどの規則を入れたのかを知ることができます。 作者は別のプラグイン agent-formal-verify も公開しています。テストでは届かない並行性のバグや不変条件に対して、TLA+ のモデル検査と Lean の証明を加えるものです。役割分担は明快です。pstack は日々のワークフローの厳密さを担い、形式検証はテストが取りこぼす隅を担います。

今後の論点は二つです。一つは、各ツールの進化に伴ってプリミティブの差が広がり、移植のコストが上がり続けないかという点です。もう一つは、ワークフローの質を客観的に測れるかという点です。公開された再現可能な評価が出て初めて、スキルスタックは「もっともらしい」から「効くと示された」へ進めます。試したいチームは、リスクの低いリポジトリで既存の失敗ケースを一つ選び、納品される証拠が手戻りを本当に減らすかを確かめるところから始めるとよいでしょう。