cursor

AI でモバイルアプリ開発の品質と速度を両立する 9 月に SmartTrack Golf というゴルフアプリをリリースし、App Store のスポーツカテゴリで 8 位まで上がりました。弊社はエンジニア数名で SmartScout Baseball という野球アプリも運用しており、それと並行して、開発からリリースまでを 2 ヶ月でやり切りました。 apps.apple.com その中で、複数のモバイルアプリを AI Agent で速く開発するための知見がたまってきたので共有します。 抱えていた課題 開発するプロダクトが増え、AI に複数のタスクを並行で任せるようになったことで、次の課題が出てきました。 複数プロダクトに同じ Agent Skills や Plugin が混在 いくつものタスクを並行で進めており把握と管理が大変 AI の出力に対して人間のレビューがボトルネックになる 現時点での対策 1. 複数プロダクトに同じ Agent Skills や Plugin が混在 現在 SmartScout Baseball と SmartTrack Golf という 2 つのプロダクトを運営しています。モバイルアプリではこの 2 つに加え、共通のサブモジュールが数個あり、これらはモノレポではなく複数のリポジトリに分かれています。Claude Code や Codex 用の Agent Skills や Plugin、PR の template もリポジトリごとに分かれていました。 そこでモバイルアプリ関連の共通の仕組みをまるごと保持する mobile-app-development というリポジトリを別途用意しました。 以降、このリポジトリを「ハブ」と呼びます。ハブは各メンバーの Claude Code と Codex に plugin として登録します。社外には公開しておらず、各メンバーの手元に clone したハブのパスを参照させているだけです。 ハブの中身 mobile-app-development/ ├── plugins/knowhere-mobile/ # 配布する plugin 本体 │ ├── skills/ # Agent Skills │ ├── agents/ # subagent │ ├── references/ # 複数の skill が従う共通ルール（テスト戦略、PR 本文のテンプレートなど） │ └── scripts/ # skill から呼ぶスクリプト ├── manifests/ # リポジトリごとの値 ├── docs/ # 手順の正本 ├── .claude-plugin/ # Claude Code 用のマーケットプレイス ├── .agents/plugins/ # Codex 用のマーケットプレイス └── mise.toml # セットアップや検証のタスク 共通化の工夫点 1. リポジトリごとの値は manifest に分ける 複数のアプリで共通の skill を使うと、bundle id や検証のコマンドのように、プロダクトごとに違う値の置き場所が必要になります。そこで manifests/<リポジトリ名>.toml を用意しました。skill は作業中のリポジトリに対応する manifest から値を読みます。 manifests/sample.toml（例） kind = "app" product = "Sample" [github] repo = "your-org/sample" default_branch = "develop" [ios.bundle_id] prd = "jp.co.sample" [verify] analyze = "mise analyze" test = "mise test" 2. 共通のルールとテンプレートもハブに置く skill のほかにも、テストの置き場所の基準や PR 本文のテンプレートのように、複数の skill やリポジトリが従うルールがあります。 これらは references/ に 1 つだけ置き、各 skill からはリンクで読ませています。PR を作る skill が本文を組み立てるテンプレートも、5 つのリポジトリで共通の 1 つにしました。 各リポジトリのドキュメントにはテストデータのような、そのリポジトリにしかない中身だけを残しています。 3. Claude Code と Codex の両方で同じように動かす 同じ skill を両方で使うために、次の点をそろえています。 各リポジトリの指示書は AGENTS.md に一本化 plugin の定義は Claude Code 用と Codex 用の 2 系統があるので、両方を同じ内容に保つ skill の本文には「サブエージェントに任せる」のように書き、ツール名（Claude Code の Agent、Codex の spawn_agent など）の対応表を用意して読み替える 自動で起動させない skill は Claude Code 用と Codex 用の 2 つの設定を両方書く 2. タスクを並行で進めており把握と管理が大変 AI に任せる作業が増えると、1 人のエンジニアが同時に何本ものセッションを動かすようになります。 Claude Code で実装を進めながら、Codex にレビューを頼み、別のウィンドウでは Codex で調べ物をする、など。 このとき困ったことは 2 つあります。 どの作業が今どうなっているか分からない。 返事を待っているもの、止まっているもの、終わったものを確かめるために、ウィンドウを 1 つずつ回っていました。 端末を取り合う。 複数のエージェントと人が、同じ Simulator や実機を使おうとして、互いのテストを壊したり、起動待ちで止まったりしていました。 前者にはダッシュボードを、後者には device lease という仕組みを導入しました。 Claude Code と Codex の作業を 1 枚で見る ダッシュボードはその Mac で動いている Claude Code と Codex の作業を 1 枚のページにまとめて表示します。データ源は Claude Code と Codex が手元に残している会話の記録だけです。 これにより、Claude Code と Codex のように別々の Agent にタスクを頼んでいても、進捗が一目で分かります。それぞれがどの手順で何をしているかも追えます。 できる部下は上司に「このタスクの進捗どう?」と聞かれる前に報告を欠かしません。同じように、AI Agent にも進捗を見える形で出させ、人の承認待ちで止まっている時間をできるだけ短くする工夫が大切だと感じました。 ただし、このダッシュボードでできるのは進捗の把握までで、作業の指示やプロンプトの入力はできません。将来はタスクの指示もここからできるようにしたいと考えています。 端末を取り合わない: device lease モバイル開発では、Simulator や実機は 1 台を 1 つの作業でしか使えません。ところがエージェントは、空いているかを確かめずに起動中の端末を拾って使うため、次のような問題が起きていました。 共有している Flutter SDK のロック待ちで、後から来た E2E が止まる 2 つの Agent が同じ Simulator を拾い、互いのテストを壊す 人が使っている Simulator を並行しているタスクの動作確認で Agent が奪う そこで、端末を期限付きで「借りる」仕組みを作りました。これを device lease と呼んでいます。 考え方はシンプルで、PC につながっている端末ごとに、誰がいつまで使うかを記録するだけです。期限が切れれば自動で返ります。誰かが使っている端末は避け、Agent は空いている端末を使います。lease の仕組みもハブに置いているので、どのリポジトリで作業する Agent も、同じ lease を見て端末を選びます。 3. AI の出力に対して人間のレビューがボトルネックになる 最近よく議論される、AI の出力に対して人間の理解やレビューが追いつかないという問題です。 理解は別として、AI が生成した PR で人間のレビュー負荷が高い原因を以下のように分解しました。 AI が書くコードと、AI のレビューの質がばらつく AI の「この PR は問題ないです」が信用できない AI が書くコードと、レビューの質がばらつく 同じ依頼でも、メンバーやセッションによって、実装の方針、実装までの進め方、実装後のレビューにばらつきが出ます。そこで、作業の進め方には pstack を少しカスタマイズして使用しています。 変えたこと 理由 PR の作成は create-pr、端末での確認は device-verify を呼ぶ（独自の skill。後ほど紹介します） PR の形と確認の証拠を、どの作業でもそろえるため push、PR の作成、外部への送信は承認を取る。merge は人が行う 外に出るものと、main に入るものは人が決めるため 実装は Sonnet、難しい判断と文章は Opus に固定する。レビュアーは Claude と Codex の 2 系統にする モデルの違いで見落としを拾うため Claude Code と Codex で同じ本文にし、ツール名の違いだけを対応表に置く どちらで作業しても同じ手順になるため 文章の決まりを日本語向けに作り直す PR 本文や返答を、日本語で読みやすくするため Cursor 専用の機能と、承認なしで merge まで進む手順を外す 自分たちの環境と決まりに合わないため レビュー skill interrogate の工夫 : 別のモデルにレビューさせて収束させる pstack には、別のモデルに変更を敵対的にレビューさせる interrogate という skill があります。これを、PR を作る前に回すようにしました。デフォルトではレビュアーは Codex 2 体と Claude Opus 1 体にしています。複数のモデルにレビューさせるのは、モデルごとの見落としの偏りを減らすためです。 ただ、最初は「指摘が無くなるまで回す」にしていたため、ある PR では 6 周回しても、指摘は 50 → 31 → 32 → 26 → 34 → 35 件と減りませんでした。原因を調べると、次の 4 つでした。 毎周、ブランチ全体を最初からレビューしていた 「NaN が渡されたら」のような、実際には届かない入力まで直そうとして、修正の範囲が広がった 修正そのものが新しい不具合を入れた 構造の問題を、箇所ごとに 1 つずつ塞いでいた そこで、Anthropic の「Solving code review at Anthropic」にある「レビューは収束しなければならない」という考え方に沿って、次の決まりを足しました。 2 周目以降は前の周の指摘を直した commit だけをレビュー 前の周までに出た指摘を一覧で渡し、同じ指摘を出させない 直すのは、実際に呼び出し元から届く問題と、この PR が入れた不具合だけにする 上限は 3 周にする。3 周目でも残ったら、1 件ずつ直すのをやめ、構造を変えるか、PR を分けるか、直さずに明記して進めるかを人に聞く 変更の大きさでも扱いを変えています。文言だけの変更は 1 周で止めます。課金や認証のように影響の大きい変更は、周回はそのままで、PR の本文に高リスクと明記します。 3 周で直しきれなかった指摘は、PR 本文の「判断してほしいこと」に、推奨とリスクを付けて載せます。 AI の「この PR は問題ないです」が信用できない たとえば PR を作るとき、AI は自分で書いたテストが通ると「この PR は問題ないです」と報告してきます。この報告をいまいち信用できないのはなぜでしょうか。原因は大きく次の 2 つだと考えています。 AI の検査内容(テスト内容)が必要十分なのかわからない 検査内容が必要十分だとしても本当に検査したのかわからない AI の検査内容が必要十分なのかわからない AI のおかげでテストコードは簡単に書けるようになりましたが、検査の内容が適切か、適切な手段で確かめているかは別の問題です。 どこまで網羅すれば十分かを定義するのは難しいので、ガードレールとして次のルールを決めています。 使う側のコードまで読ませる。 仕様と変更したコードに加え、その値を使う画面や処理も読ませ、壊れうる振る舞いを先に挙げさせる 既存のテストを十分の根拠にしない。 変更前の振る舞いしか見ていないことがあるため 期待値は実装ではなく仕様から決める。 実装を読んで期待値を書くと、実装が間違っていてもテストが通るため 仕様が分からなければ、未確定として残す。 今の動きを正解として固めないため また、検査に使うテストの手段は、大きく次の 3 つに分けています。 手段 何を確かめるか 本物にするもの Fake にしてよいもの 例 Unit Test 1 つのクラスや関数の分岐、変換、状態の移り変わり 対象のクラス 依存するもの全部 再利用するか新しく作るかの判定 Widget Test 表示、入力、画面遷移、ダイアログなど、Flutter の中で完結する振る舞い 描画・タップ・画面遷移、アプリのコード 通信、OS、ネイティブ、時間 保存せずに戻ると確認ダイアログが出る E2E 本物のアプリを端末に入れ、操作から API・状態の更新までがつながるか ほぼすべて 課金サーバーなどの外部サービス 権限ダイアログ、カメラ、ログインの通し AI 時代はテストのメンテナンスコストが下がるので、E2E でほとんど網羅すればよい！と考え、E2E でなくてもよいテストまで E2E で書いていた時期もありました。しかし、リリースは週に 2〜3 回以上あり、そのたびに全シナリオを回すと 1 時間以上かかって地味につらかったため、E2E は必要最小限にするという古典的な戦略に戻しました。 そこで便利なのが、Flutter の Widget Test です。1 つの画面で閉じる振る舞いなら、E2E ではなく Widget Test で確かめられることが多く、実行も E2E よりずっと速いので、Widget Test を厚くしています。 x.com AI にどのテストを使うか決めさせる テストの置き場所は次の 3 つの問いに順に答えて決めています。 このテストが落ちたら、ユーザーにとって何が壊れているのか。 テストの対象を、画面やファイルの名前ではなく、ユーザーから見た振る舞いとして 1 文で書きます。たとえば「プロフィール画面のテスト」ではなく、「保存せずに戻ると確認ダイアログが出て、破棄を選ぶと変更が消える」と書きます。 その振る舞いは、何と何がつながって成り立っているか。 上の例なら、画面の移動とダイアログです。このつながりは本物のまま動かし、保存先のように振る舞いに関係しない部分は Fake に差し替えます。 そのつながりを、端末なしで本物のまま動かせるか。 動かせるなら Unit Test か Widget Test に置きます。端末が無いと動かせないときだけ、E2E に置きます。 どのテストでも見つけられる不具合なら、いちばん軽いテストに置きます。軽いテストほど速く終わり、落ちたときに原因を絞りやすいためです。 また、この 3 つのテストとは別に、見た目の差分を見る VRT、AI Agent が自分で Simulator や実機を操作して確かめる device-verify、人が操作して確かめる確認項目も使い分けています。 検査内容が必要十分だとしても本当に検査したのかわからない 上のルールで AI にテストケースを網羅させても、本当に実行したという証拠が無ければ信頼できません。そこで、それぞれの手段で検査した証拠を PR に残させています。 固定のテストを流した証拠 Unit Test、Widget Test、E2E を流したときは、次のことを記録させます。 どの commit を確かめたか。 コードが変わると証拠は無効になり、影響する確認をやり直すまで PR を進めない 走ったテストの件数。 0 件なら失敗として扱う 修正を外すとテストが落ちるか。 直した箇所をわざと元に戻してテストを流し、落ちることを確かめる。落ちないテストは修正を守っていない 毎回は起きない不具合は、何回流して何回通ったか。 1 回の合格では見逃しうるため AI が端末を操作して確かめた証拠: device-verify テストが通っても、実際の画面で正しく動くとは限りません。まだテストになっていない導線も、固定のテストでは確かめきれません。 そこで、AI が Simulator や実機を自分で操作して確かめる device-verify という skill を作りました。人が手元で動作確認するのと同じことを、AI にやらせるイメージです。 操作にはそのとき使える手段を使います。iOS Simulator なら Claude Code Desktop の Simulator のペインや Simulator 用の MCP、Android なら adb、必要なら computer use です。 AI の操作を確認として信用できるものにするため、次の決まりを入れています。 操作の前に、期待する結果を書く。 確認項目ごとに、前提（アカウント、データ、権限、通信の状態）と、観測したい結果を先に決める。操作してから「こうなったので OK」とは判断させない 今の commit のビルドで確かめる。 古いインストール済みのアプリや hot reload の画面を、今の commit の証拠にしない コマンドの成功を、確認の成功にしない。 adb のタップが exit 0 で終わっても、それは操作が送れたというだけ。状態が変わるたびに、画面や UI の情報を取り直して確かめる 見た目だけで判断しない。 保存や API の呼び出しのように画面に出ない結果は、ログや保存したデータでも確かめる 状態を変えてから撮る。 回転してから撮る、権限を外してから撮る。開いた直後の画面は変えた後の状態の証拠にならない 端末は Simulator と Emulator が基本で、実機は実機でしか確かめられない項目だけに使います。端末は device lease で借りるので、ほかの作業とぶつかりません。 見た目の変化: VRT AI が変更していない画面の見た目まで、意図せず変えてしまうことがあります。全部の画面を人が開いて見比べるのは現実的ではありません。 そこで、PR を出すたびに CI で VRT（Visual Regression Test）を流しています。Flutter の golden test で全画面のスクリーンショットを撮り、reg-suit で base ブランチと比べます。差分があれば、Before・After・差分の画像を並べたコメントを PR に付けます。 CI が PR に付ける VRT のコメント（見本。中身は架空） VRT が見つけるのは「見た目が変わった」ことまでです。その変化が意図どおりか、見た目として良いかは、人が判断します。人は全画面を見て回る代わりに、変わった画面だけを見ればよくなりました。 確認コメントにまとめる 固定のテストと AI の操作の結果は、PR の確認コメント 1 つにまとめます。人が確かめる項目を一番上に置き、AI が確かめた項目、確かめていない項目の順に並べます。 create-pr が PR に付ける確認コメント（見本。中身は架空） 人が確かめる項目は、AI が確かめられなかったものだけです。実機でしか確かめられないもの、AI の操作では届かないもの、見た目の良し悪しのように人の判断が要るものが入ります。人が迷わず確かめられるよう、書き方も決めています。 どのビルドで確かめるかを書く。 確かめたい commit を含むビルドかを AI が照合してから前提に書き、人が古いビルドで確かめてしまわないようにする 手順は番号付きで、1 手順 1 動作にする。 画面の項目名は「」で囲み、最後に「期待する結果」を書く 判断だけで足りる項目は 1 文にする。 見た目が自然か、など。比べる画像を添える AI が確かめた項目の表には、固定のテストと AI の操作を書き分けます。人は「修正を外すと」の列で、テストが修正を本当に守っているかを確かめられます。 PR を作ったあとにコードを変えたら、影響する項目を [ ] に戻します。人が確かめる項目がすべて埋まり、CI が通ったら、PR を Ready にします。 おわりに モバイルアプリは Backend や Web よりも実機での確認が必要な箇所が多いなど、まだまだ AI Agent を活用して高速にリリース、デプロイする知見が少ない分野だと思います。 これからもどうしたら高速に開発し、素早くユーザーに価値を届けつつもバグや構造的な問題を減らしていくかを日々考えながら運用していこうと思います。 x.com 並行して開発している SmartScout Baseball は App Store のスポーツランキング 11 位、SmartTrack Golf は 8 位に最高ランクインしつつ、もっと多くの方々に使っていただけるよう日々進化させています。弊社ではまだまだメンバーを募集中なので興味のある方はぜひご連絡ください ! career.knowhere.co.jp

pstackの謎を解く：ループを改善するループを回す、5つのスキル 1本目で考え方だけ書いた仕組みを、スキルで見る 1本目の記事では、pstackの品質を支えているのは個々のスキルではなく、スキルを改善するやり方だと書き、これを「ループを改善するループ」と呼びました。ループは2重です。内側は、エージェントが作業して自分で検証するループ。外側は、その作業の記録からスキルを改善し、次の作業を良くするループです。 1本目で書いたのは考え方だけでした。pstackには、この仕組みを自分のリポジトリで回すためのスキルが入っています。今回は、それぞれのスキルが何をし、どこを担うかを見ていきます（v0.15.25）。 人が回す2つのワークフロー 5つのスキルと3つのPlaybookは、人が回す2つのワークフローに分かれます。1つ目は内側のループを回せるようにするもの、2つ目が外側のループです。 検証する手段を作り、保つワークフロー: /create-verification-skill、/maintain-verification-skill スキルを改善するワークフロー: 入口は2つ 見つけるスキルが、そのまま改善する: /reflect、/correct、/automate-me /poteto-mode に頼んで、書き直して測る: PlaybookのAuthoring or modifying a skill、Eval、Hillclimb どちらのワークフローも、始めるのと結果を取り込むのは人で、間の作業はエージェントがします。 Playbookは /poteto-mode の中にあるタスク別の手順書で、スキルではありません（2本目）。ただ、書き直す、測る、繰り返すを担うので、ここでは一緒に扱います。 検証する手段を作り、保つワークフロー 最初にやるのは、エージェントが自分の作業を検証する手段を用意することです。pstackでは、リポジトリごとに作る専用のスキルがこれにあたり、ここでは検証スキルと呼びます。検証できるエージェントは、検証が通るまで自分で作業を続けます。できなければ、結果を毎回人に戻して確かめさせます。pstackの公式ガイドは、検証スキルを一番効くものに挙げ、こうも書いています（筆者訳、以下同じ）。 自分の作業を検証できないループは、検証していない作業を速くするだけ。先に検証スキルを動くようにする。 （10-recipes-and-pitfalls.md L145） /create-verification-skill は、リポジトリ専用の検証スキルを作ります。中身は、アプリを起動し、ユーザーと同じように操作して証拠を残す手順と、機能ごとの地図です。作ったスキルは、渡す前に1回実行して確かめます。「一度も実行していない生成スキルは、下書きであって成果物ではない」からです（create-verification-skill/SKILL.md L40）。 検証スキルには手入れも要ります。機能の地図は「アプリが変わった瞬間から古くなる」からです（maintain-verification-skill/SKILL.md L9）。/maintain-verification-skill は、地図にある機能をすべて実際に動かし、ずれを直します。直すのは検証スキルだけで、製品のコードには触りません。直しは1本のPRにまとめ、人が取り込みます。ガイドは、これを1日1回以上、できれば定期実行で回すよう勧めています（06-verify-and-ship.md L88）。 スキルを改善するワークフロー このワークフローが外側のループです。改善したスキルは次の作業から効き、その作業の記録から、また改善するところが見つかります。入口は2つあります。 見つけるスキルが、そのまま改善する 3つのスキルは、作業の記録から改善するところを見つけ、そのまま改善します。読む記録と改善する先はスキルごとに違い、どれも1回きりのことは拾いません。 読む記録 改善する先 /reflect 今の会話 その会話で使ったスキル /correct 最近のコミット、revert、レビューコメント リポジトリ /automate-me ここ数週間の会話 自分用の -mode スキル /reflect は、作業が終わった直後に呼び出します。改善の提案は「採用」「却下」「後回し」に仕分けられ、人が採用の一覧から1行ずつ選んだものだけを、その場で反映します。「スキルの変更は、組織の未来のすべてのエージェントに効く」からです（reflect/SKILL.md L47）。lintやスクリプトで強制できるものは、スキルの文章にせず「後回し」に回します。 /correct は、同じ間違いを、スキルではなくリポジトリを変えて起こせなくします。間違いの種類ごとに1コミットで直し、直し方には順番があります（correct/SKILL.md L19–22）。 構造を変えて、その間違いが起きないようにする 型で書けなくする。型で防げなければ、lintやCIで止める テストで振る舞いを確かめる 文書やエージェント向けのルールは最後。エージェントが読み飛ばしても、何も落ちないから /automate-me が作るのは、返答の好みや「完了」の基準といった自分の働き方をまとめた、/poteto-mode の自分版です。下書きを本人が読んで「自分らしいか」で確かめ、PRにします。評価は回しません。出力が主観的なものだからです（automate-me/SKILL.md L96）。 /poteto-mode に頼んで、書き直して測る もう1つの入口は、/poteto-mode に「このスキルを改善して、評価もして」と頼むことです。/poteto-mode は、頼んだ内容に合うPlaybookを選びます（poteto-mode/SKILL.md L123）。ルートは2つで、AuthoringとEvalで1回書き直して測るか、Hillclimbで数字が目標に届くまで繰り返すかです。 Authoring or modifying a skill は、スキルを書き直してPRにする手順です（authoring-a-skill.md）。この手順は評価を自分では呼ばないので、ガイドは、評価も同じ依頼の中で頼むよう勧めています（09-make-it-yours.md L82–88）。 Eval は、変える前と後のスキルに同じ課題を解かせて比べる手順です。一番気を配っているのは、エージェントに評価だと気づかせないこと。試されていると知ったエージェントは振る舞いが変わるので、課題は普通のユーザーの頼み方にし、evalやjudgeといった語も見せません（eval.md L5–21）。最後に、変更を採用するかの推薦を返します（L25）。決めるのは人です。 なぜ毎回測るのか。ガイドの答えはこうです。 1回のまずい会話から書いた直しは、その会話に寄りすぎます。それを重ねるうちに、スキルは少しずつずれていく。評価は、そのずれを出荷前に捕まえます。 （09-make-it-yours.md L88） Hillclimb は、1つの数字を目標まで上げ続ける手順です。「1つ変えて、測って、残すか戻す」を、止める条件を満たすまで繰り返します（hillclimb.md L5）。止める条件は、目標と試行回数の下限の組で決めます。運よく早く当たっても止めないためで、条件を緩めて達成したことにもしません。 スキルに使うときは、Evalの採点を数字にします。AuthoringとEvalとの違いは、1回に1つだけ変え、残すか戻すかを数字で自動で決めることです。始めるときに数字と止める条件を人と決めれば、外側のループの中に、人を待たずに回る小さなループができます。 まとめ スキルを改善するワークフローを回すと、人が繰り返していた訂正は、スキルに書き込まれたり、型やlint、テストになったりして、同じ訂正をしなくて済むようになります。 始めるなら、/create-verification-skill で検証スキルを作るところからです。エージェントが自分の作業を検証できないまま回しても、検証していない作業が速くなるだけだからです。 pstackの謎を解くシリーズ 1本目: pstackの謎を解く：Cursorの爆速開発を支えるスキルは、どう作られているか 2本目: pstackの謎を解く：たった一言の指示でPRまで。裏で何が動いているか 3本目: pstackの謎を解く：たった一人で月2,500件のPR、その秘密は速さではなかった 4本目（この記事）: pstackの謎を解く：ループを改善するループを回す、5つのスキル 参考 pstack（cursor/plugins） pstack v0.15.25（cursor/plugins）: この記事で読んだ版 Make it yours: 公式ガイドの、/reflect、/correct、/automate-me、Evalの章 Verify and ship: 公式ガイドの、検証スキルの作り方と保ち方の章

Coding Agent の「作り直し」と「検証ミス」を減らす：Matt Pocock Skills × pstack 最近、Coding Agent を使った開発で、Matt Pocock Skills と pstack を組み合わせて使うことが増えています。 最初は便利そうな Skill を個別に試していただけでしたが、ソースコードやドキュメント、ほかの開発者の使用例を読んでいるうちに、それぞれの設計思想にも興味を持つようになりました。 実際に使い続ける中で、両者の良いところを取り入れた、自分なりのワークフローが少しずつ固まってきました。 特に役立っているのは、Spec を書いたのに UI が想像と違ったり、Agent がこちらの意図していない判断をしたり、変更後のアプリを検証したつもりが古いプロセスを確認していたり、といった問題への対処です。 この記事では、二つの Skills から学んだことと、普段の開発でどのように使い分けているかを紹介します。 1. Matt Pocock Skills と pstack は何を解決しようとしているのか どちらも Coding Agent を使った開発の信頼性を高めるためのものですが、アプローチには違いがあります。 1.1 Matt Pocock：コードを書く前に立ち止まる Matt Pocock（@mattpocockuk） は、TypeScript の教育コンテンツ「Total TypeScript」や「AI Hero」などを手がける開発者です。彼が公開している Matt Pocock Skills の特徴は、一般的なエンジニアリングプラクティスを、小さく独立した Skill に分けている点です。 Coding Agent は短時間で機能を実装できますが、実際に使っていると、次のような問題によく遭遇します。 要件が十分に決まっていないのに、Agent が実装を始めてしまう 実装の途中で、考慮していなかったエッジケースに気づく Spec には沿っているのに、完成した UI が自分のイメージと違う 実装が終わってからテストを追加し、大幅な修正が必要になる どれもソフトウェア開発では昔からある問題ですが、コード生成が速くなったことで、むしろ遭遇しやすくなったと感じています。 Matt Pocock Skills には、こうした問題に対応するための Skill が用意されています。 Skill 主な用途 /grill-me 質問を繰り返し、未決定事項や曖昧な要件を洗い出す /grill-with-docs 要件を議論しながら、用語集やアーキテクチャ上の決定事項をドキュメントに残す /prototype 本実装に入る前に、複数の設計案を試す /to-spec、/to-tickets 議論した内容を Spec や実装タスクに整理する /tdd Red → Green → Refactor のサイクルで実装する /code-review コード品質や元の要件との整合性をレビューする /handoff 別の Agent セッションに作業を引き継ぐため、進捗や決定事項を記録する 個人的に気に入っているのは、Agent がすぐにコードを書かず、質問するための仕組みがあることです。 例えば /grill-me では、未決定の部分を Agent が勝手に補完するのではなく、質問としてこちらに返してくれます。 また、/prototype では、本実装に入る前に、使い捨てのコードでアイデアを試すことができます。 どちらも、設計を早い段階で決めつけてしまうことを防ぐのに役立っています。 1.2 pstack：Agent が実際に何を検証したのか確認する Lauren Tan（@poteto）が開発した pstack は、タスクごとのワークフローと検証をより重視しています。 機能開発、デバッグ、調査、設計、レビューなど、さまざまな開発タスクに対応した Skill が含まれています。 代表的なものをいくつか挙げます。 Skill 主な用途 /poteto-mode タスクに応じて適切なワークフローを選択する /create-verification-skill プロジェクト固有の起動・検証手順を作成する /maintain-verification-skill プロジェクトの変更に合わせて検証手順を更新する /debug 修正する前に、不具合の原因を調査する /how、/why システムの動作や設計上の判断を追跡する /architect 実装前にモジュール構成や型の設計を整理する /unslop AI が生成した UI にありがちなデザイン上の問題を見直す 特に興味を持ったのが、Verification 関連の Skills です。 Coding Agent を使っていると、作業の最後に次のような報告を受けることがよくあります。 Implementation complete. All tests passed. もちろん、テストが通ったこと自体は良いことです。ただ、最近は「実際に何をテストしたのか」を確認するようにしています。 例えば、Agent が API を修正し、ユニットテストはすべて通過したものの、アプリケーション自体は起動していないケースがあります。 あるいは、コードの変更前から動いているサーバーにリクエストを送っていることもあります。 後者は自分も実際に遭遇した問題です。 /create-verification-skill を使うと、プロジェクトに合わせた起動・検証手順を Agent に覚えさせることができます。 起動コマンドや環境設定、起動完了の確認、機能の操作方法、どのような証拠があれば成功と判断できるか、といった情報をまとめられます。 毎回 Agent に一から調べさせるより、一度決めた手順を再利用できるほうが便利だと感じています。 1.3 二つの Skills をどう組み合わせるか もちろん、両者の機能には重複があります。 Matt Pocock Skills にも TDD、コードレビュー、デバッグ関連の Skill がありますし、pstack にも計画、設計、調査のためのワークフローがあります。 そのため、「Matt はコードを書くため、pstack はテストするため」と単純に分けているわけではありません。 自分の場合は、開発の各段階で次のように使い分けています。 開発段階 避けたい問題 主に使う Skills 実装前 要件が曖昧、設計の方向性が違う Matt：要件の確認、Prototype 実装中 変更範囲が大きすぎる、Spec から外れる Matt：タスク分割、TDD、レビュー 実装後 テストは通るが、実際のアプリの動作が違う pstack：プロジェクト固有の実行時検証 継続開発 Agent がプロジェクトの動かし方を忘れる、検証手順が古くなる pstack：Verification の更新、Matt：Handoff これは公式に用意された組み合わせではなく、自分が普段の開発で使っている方法です。 2. 実際の開発での使い方 すべてのタスクで、すべての Skill を使うわけではありません。 ただ、新しい機能を作るときは、次のような流れで進めることが増えました。 Step 1：まず要件を整理する 使用する Skills：/grill-me、/grill-with-docs 複数の実装方法が考えられる機能では、まず Agent に質問してもらいます。 例えば、プロジェクトの進捗に応じて、毎日のタスクを自動調整する機能を作るとします。 「計画が変わったらタスクを自動更新する」という要件だけでは、まだ分からないことがあります。 Agent はタスクをすぐ変更してよいのか。ユーザーの承認が必要なのか。手動で編集したタスクはどう扱うのか。 こうした部分を /grill-me で整理します。 長期開発のプロジェクトでは /grill-with-docs も使い、決定事項をドキュメントに残すようにしています。 Step 2：Spec ができても、すぐに本実装しない 特に気に入っている Skill：/prototype Matt Pocock Skills の中で、個人的に最も効果を感じている Skill です。 以前は Agent と十分に議論して Spec を書いたあと、そのまま実装に進むことが多かったのですが、完成した画面を見て、「確かに指定したとおりだけど、思っていたものと少し違う」と感じることが少なくありませんでした。 特に UI やインタラクションでは、文章だけで完成形をイメージするのが難しいです。 そこで最近は、設計がまだ決まっていない場合、三つの Prototype を作ってもらうようにしています。 例えば、タスク管理画面なら次の三案です。 リスト形式：優先度やタスクの状態を一覧で確認する カンバン形式：タスクをステータスごとに管理する タイムライン形式：日々の予定やスケジュールを中心に表示する 実際に動かして比較すると、どの操作が使いやすいか、自分が何を重視しているかが分かってきます。 その結果を Spec に反映してから本実装に進むほうが、あとから大きく作り直すケースを減らせています。 Prototype は基本的に使い捨てです。データベースや本番用のアーキテクチャまで用意せず、アイデアを検証することに集中します。 Step 3：方向性が決まったら実装する 使用する Skills：/to-spec、/to-tickets、/tdd Prototype で方向性が決まったら、Spec を更新して実装タスクに分割します。 入力と出力が明確なビジネスロジックについては、/tdd を使って小さく実装していくことが多いです。 ただし、単純な UI 修正まで毎回 TDD にするわけではありません。変更の規模や性質に応じて使い分けています。 Step 4：実際のアプリで検証する 特に気に入っている Skill：/create-verification-skill 以前は、機能が完成したら Agent に「アプリを起動して確認して」と指示するだけでした。 しかし、どのディレクトリで実行するのか、どのポートを使うのか、起動完了をどう判断するのかといった情報が曖昧だと、Agent が毎回試行錯誤することになります。 そこで /create-verification-skill を使い、プロジェクト専用の検証手順を作っておきます。 基本的には、次の流れです。 フェーズ 内容 Launch アプリを正しく起動する Doctor 環境やプロセスの状態を確認する Drive 実際に API や UI を操作する Evidence レスポンスやログなど、検証結果を残す Cleanup 検証用に起動したリソースを片付ける Feature Map には、主要な機能の操作方法や確認項目も記録できます。 毎回 Agent に起動方法から考えさせるのではなく、同じ手順で検証してもらえるのが気に入っています。 Step 5：問題があれば調査し、手順を更新する 検証中に問題が見つかったら、Matt の /diagnosing-bugs や pstack の /debug などを使い、原因を調べます。 修正後は同じ手順で再検証します。 プロジェクトの構成や検証方法が変わった場合は、/maintain-verification-skill で手順を更新します。セッションをまたぐ作業なら /handoff も使います。 普段のワークフローを図にすると、おおよそ次のようになります。 機能の要望 | v /grill-me または /grill-with-docs | v 最初の Spec | +-- 設計がまだ不確か？ | | | +-- /prototype | | | +-- 複数案を比較 | +-- Spec を更新 | v /to-spec と /to-tickets | v /tdd または段階的な実装 | v プロジェクト固有の Verification Skill | +-- Launch / Doctor +-- Drive +-- Evidence +-- Cleanup | v 問題が見つかった？ | +-- 原因を調査 +-- 修正 +-- 再検証 | v 完了 または /handoff この流れは、必ず守るチェックリストというより、作業を進める際の目安です。 また、二つの Skills を組み合わせるといっても、インストールするだけで自動的に連携するわけではありません。利用する Coding Agent や実行環境に合わせて使い分けています。 3. デモ：5つのStepでタスク管理アプリを作る ここまで紹介したワークフローを、小さな Python アプリの開発に当てはめてみます。 作るのは「今日のタスク管理アプリ」です。タスク一覧を表示し、完了ボタンを押すと状態が更新される、というシンプルな機能です。 以下は各 Skill の組み合わせ方を説明するためのデモであり、実際の Agent セッションの実行ログではありません。 Step 1：/grill-me で要件を明確にする 最初に Agent に渡す要件は、これだけです。 今日のタスクを表示して、完了できる Web アプリを作りたい。 /grill-me で要件を整理すると、例えば次のような質問が出てきます。 Agent からの質問 今回の決定 タスクの追加・削除は必要？ 今回は不要 完了済みタスクはどう表示する？ 一覧に残し、「完了」と表示する 完了ボタンを押したら？ ページをリロードせずに表示を更新する データの永続化は必要？ 今回は不要。メモリ上で管理する 存在しないタスク ID は？ HTTP 404 を返す ここで決めた「ページをリロードせずに表示を更新する」という仕様が、あとで重要になります。 Step 2：/prototype で UI を比較する 次に、同じモックデータを使って三つの UI を試します。 Prototype UI 特徴 A リスト形式 タスク一覧と完了ボタン B カンバン形式 未完了・完了の2列 C タイムライン形式 時間帯ごとのタスク表示 今回は最もシンプルな A のリスト形式 を採用します。 本来であれば三つの Prototype を実際に動かして比較しますが、このデモでは UI の選定結果を前提として進めます。 Step 3：/to-spec と /tdd で実装する 今回の最小限の Spec は次のとおりです。 GET /tasks：タスク一覧を取得する POST /tasks/{id}/complete：指定したタスクを完了にする /：タスク一覧と完了ボタンを表示する 完了操作後、ページをリロードせずに表示を更新する API と UI を実装タスクに分け、まず API の動作を /tdd で確認します。 test_app.py from fastapi.testclient import TestClient from app import app, tasks client = TestClient(app) def test_complete_task(): tasks[1]["done"] = False response = client.post("/tasks/1/complete") assert response.status_code == 200 assert response.json()["done"] is True assert client.get("/tasks").json()[0]["done"] is True このテストに対応するアプリを実装します。 app.py from fastapi import FastAPI, HTTPException from fastapi.responses import HTMLResponse app = FastAPI() tasks = { 1: {"id": 1, "title": "仕様を確認する", "done": False}, 2: {"id": 2, "title": "画面を確認する", "done": False}, } @app.get("/tasks") def list_tasks(): return list(tasks.values()) @app.post("/tasks/{task_id}/complete") def complete_task(task_id: int): if task_id not in tasks: raise HTTPException(status_code=404) tasks[task_id]["done"] = True return tasks[task_id] @app.get("/", response_class=HTMLResponse) def index(): return """ <h1>今日のタスク</h1> <ul id="tasks"></ul> <script> async function refresh() { const items = await (await fetch("/tasks")).json(); document.getElementById("tasks").innerHTML = items.map(t => ` <li> ${t.title}: <span id="state-${t.id}"> ${t.done ? "完了" : "未完了"} </span> <button onclick="completeTask(${t.id})"> 完了にする </button> </li> `).join(""); } async function completeTask(id) { await fetch(/tasks/${id}/complete, { method: "POST" }); } refresh(); </script> """ 依存パッケージをインストールし、テストを実行します。 pip install fastapi uvicorn pytest httpx python -m pytest -q この API テストは通ります。 しかし、まだ一つ問題が残っています。 Step 4：Verification Skill で実際の動作を確認する Step 3 では API のテストが成功しました。しかし、ここで Agent が pytest の結果だけを見て実装完了と判断すると、問題を見逃してしまいます。 まず、Verification Skill を使わずにアプリを確認してみます。 python -m uvicorn app:app --port 8000 ブラウザで localhost を開き、「仕様を確認する」の完了ボタンを押します。 画面上の表示は、次のままです。 仕様を確認する：未完了 一方、API を確認すると、 curl localhost 次のように状態が更新されています。 [ {"id": 1, "title": "仕様を確認する", "done": true}, {"id": 2, "title": "画面を確認する", "done": false} ] API 自体は正常に動作しています。それでも、ブラウザ上では「未完了」のままです。 もし Agent が API のレスポンスだけを確認していたら、この不具合を見逃す可能性があります。 そこで、pstack の /create-verification-skill を使い、プロジェクト固有の検証手順を用意します。 今回なら、次のような内容です。 フェーズ 検証内容 Launch 現在のコードを新しいプロセスで起動する Doctor プロセスとポートを確認し、起動完了を待つ Drive ブラウザでタスクの完了ボタンを押す Evidence API と画面表示の両方を確認する Cleanup 今回の検証で起動したプロセスを終了する ここでは、その検証方法を簡単な Python スクリプトで再現します。 ブラウザ操作には Playwright を使います。 pip install playwright python -m playwright install chromium verify.py を作成します。 import json import socket import subprocess import sys import time from urllib.request import urlopen from playwright.sync_api import sync_playwright, expect 既存のサーバーを避けるため、空いているポートを選ぶ with socket.socket() as sock: sock.bind(("127.0.0.1", 0)) port = sock.getsockname()[1] url = f"http://127.0.0.1:{port}" 現在のコードを新しいプロセスで起動する server = subprocess.Popen( [ sys.executable, "-m", "uvicorn", "app:app", "--host", "127.0.0.1", "--port", str(port), ], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL, ) try: 新しいサーバーの起動を待つ for _ in range(50): if server.poll() is not None: raise RuntimeError("Server failed to start") try: with urlopen(f"{url}/tasks", timeout=1): break except OSError: time.sleep(0.1) else: raise TimeoutError("Server not ready") with sync_playwright() as p: browser = p.chromium.launch() try: page = browser.new_page() page.goto(url) 初期状態を確認する state = page.locator("#state-1") expect(state).to_have_text("未完了") 実際に完了ボタンを押す with page.expect_response( lambda r: "/tasks/1/complete" in r.url and r.request.method == "POST" ) as result: page.get_by_role( "button", name="完了にする" ).first.click() assert result.value.status == 200 API の状態を確認する with urlopen(f"{url}/tasks") as response: tasks = json.load(response) assert tasks[0]["done"] is True print("API: done=True") ページをリロードせずに表示が変わるか確認 expect(state).to_have_text("完了", timeout=2000) print(f"PASS: PID={server.pid}, UI=完了") finally: browser.close() finally: 自分が起動したプロセスだけを終了する server.terminate() try: server.wait(timeout=5) except subprocess.TimeoutExpired: server.kill() server.wait() 実行します。 python verify.py 現在の app.py では、API の検証は成功しますが、画面表示の検証で失敗するはずです。 API: done=True AssertionError: ... Expected: "完了" Received: "未完了" つまり、API は更新されているのに、UI が更新されていないことを検出できました。 この verify.py は説明用に手書きしたスクリプトであり、pstack が自動生成したものではありません。実際のプロジェクトでは、こうした検証方法を Verification Skill に組み込み、Agent が繰り返し実行できるようにします。 Step 5：/debug で修正し、もう一度検証する ここで /debug、または /diagnosing-bugs を使って原因を調べます。 Step 3 の実装では、completeTask() が API を呼び出すだけで、画面を更新していませんでした。 async function completeTask(id) { await fetch(/tasks/${id}/complete, { method: "POST" }); } そこで、await refresh() を追加します。 async function completeTask(id) { await fetch(/tasks/${id}/complete, { method: "POST" }); await refresh(); } これでコードは修正できました。 しかし、ここでもう一つ問題があります。 Step 4 でポート 8000 に起動した Uvicorn は、まだ古いコードを読み込んだままです。 今回の起動コマンドには --reload を指定していません。 そのため、app.py を修正しても、ポート 8000 で動いているプロセスには自動的に反映されません。 仮に Agent がもう一度、同じポートで起動しようとしても、 python -m uvicorn app:app --port 8000 既存のプロセスがポートを使用しているため、起動に失敗します。 それでも localhost にアクセスすれば、古いプロセスが応答します。 ここで Agent が「まだ UI が更新されない」と判断し、正しく修正したコードを再び変更してしまう可能性があります。 以前、自分もこのような問題に遭遇しました。 そこで、Step 4 で作成した verify.py をもう一度実行します。 python verify.py このスクリプトはポート 8000 の既存プロセスを利用せず、現在のコードを新しいプロセスで起動します。 修正が正しく反映されていれば、次のような結果が期待できます。 API: done=True PASS: PID=12345, UI=完了 これで、現在のコードで起動したアプリが期待どおりに動作することを確認できます。 最後に、今回の不具合を Feature Map の検証項目に残しておきます。 タスクの完了ボタンを押したあと、ページをリロードせずに対象タスクの表示が「完了」に変わること。 あわせて、検証時には既存のプロセスを安易に再利用せず、新しく起動したアプリを対象にすることも手順に含めておきます。 必要に応じて /maintain-verification-skill で検証手順を更新し、別のセッションへ引き継ぐ場合は /handoff で作業内容を整理します。 今回の例では、API のテストが成功しただけでは UI の不具合を発見できず、コードを修正しただけでは古いプロセスの問題を回避できませんでした。 Verification Skill によって、どのアプリを起動し、何を操作し、どの結果を確認するかを決めておくことで、Agent が同じ検証ミスを繰り返す可能性を減らせます。 4. おわりに コードの実装を Agent に大きく任せる開発は、すでに現実的になっています。これからは、Agent Skills を設計し、組み合わせ、使いこなす能力も、エンジニアにとって重要になると思います。成果物のコードからは見えにくい能力ですが、同じモデルを使っていても、Agent が働く環境によって開発効率は大きく変わります。 特に参考になったのが、poteto の 「How I Shipped 2,500 PRs Last Month to Production」 という講演です。 そこで紹介されていた Trust Ladder という考え方が印象に残っています。最初は人間が細かく確認していても、Agent が自分でアプリを動かし、結果を検証できるようになれば、任せられる範囲を少しずつ広げられます。繰り返し起きるミスは、Lint や CI、Skills などの仕組みに落とし込みます。 Agent の作業が速くなるほど、人間が毎回すべてを確認することがボトルネックになります。その負担を減らすには、単に Agent を信頼するのではなく、信頼できるだけの検証環境を作ることが必要なのだと思います。 自分も、開発中に発見した失敗をその場限りの指摘で終わらせず、次回から防げる仕組みに変えていきたいと考えています。 参考資料 Matt Pocock — Skills for Real Engineers Matt Pocock — The /prototype Skill Matt Pocock Skills — GitHub pstack — GitHub pstack — create-verification-skill pstack — maintain-verification-skill Lauren Tan（@poteto）— How I Shipped 2,500 PRs Last Month to Production

Here’s one of the review skills I use a lot: github.com/cursor/plugins/blob/main/cursor-team-k… Here’s the graph tool I’m using more & more: graphify.com There’s also temperature and top-k values to tune a models probability of different things It’s easy to over simplify what a model does and draw the wrong conclusions

show me the all the cool charts you've made with /statechart! and bugs that you've found using the /create-formal-verification skill you can install pstack here: github.com/cursor/plugins/tree/main/pstack

Anthropic と Cursor に学ぶ、クラウドで AI に開発を任せる仕組み はじめに ソフトウェア開発のやり方は、これまでも何度か大きく変わってきました。機械語からアセンブリへ、アセンブリから高級言語へ。抽象度の層が上がるたびに、人は下の層のコードを自分で書かなくなりました。そのぶん人の仕事は「何を作りたいかを伝え、できたものを確認する」側へ移ってきました。 いま起きているのも同じ形の変化です。コードの書き手が人から AI に替わり、さらに AI が作業する場所も手元のマシンからクラウドへ広がることで、人は1ステップずつ付き添うのではなく「仕事を渡して、成果物を確かめる」役割へ変わろうとしています。 Cursor は、AI 支援の開発を3つの時代に分けています。Tab 補完で書く時代、エージェントと対話しながら、1回ずつ指示と確認を繰り返す時代、そして人の指示をあまり受けずにエージェントが長い時間をかけて大きな仕事をこなす時代です。Cursor がこの区分を発表した2026年2月時点で、Cursor 社内でマージされる PR の 35% は、クラウドの VM で自律的に動くエージェントが作ったものでした1。 この記事では、その3つ目の時代の開発がどう行われているかを、Anthropic と Cursor の公開情報や関連論文をもとにまとめます。はじめに背景となるボトルネックの変化を見たうえで、次のテーマを扱います。 クラウドで動くエージェントの仕組み エージェントを安全に動かすためのサンドボックス エージェントが書いたコードのレビューと検証 エージェントを信頼するための環境づくり 書く速さに確かめる側が追いつかない 各社の報告を並べると、エージェントによってコードが作られる速さと量が急増し、それを受け止める側の仕組みや人の作業が追いつかなくなっています。 Anthropic によると、社内ではもうコードを書くことがボトルネックではなくなりました。1日にマージされるコード変更は、2026年5月には平均で約2,500件でしたが、9月時点では3万件を超えています。ボトルネックは、人が作業する規模を前提に作られたソース管理・ビルド・CI に移りました。そのため Anthropic は git から独自のソース管理システムへ移行し、コードレビューなどの仕組みも新たに作っています。同社は、自社の作業量は特殊で多くの組織が今すぐ同じ問題に直面するわけではないとしつつも、AI コーディングツールを使う他の組織が同じようなボトルネックに直面するのもそう遠くはないと見ています2。 Cursor も、いま生成されている量のコードをさばくための新しいツールを開発しています。コードを作るコストが下がり続けるほど、それを安全に本番へ出す新しいやり方が要るという考えです3。 個人の単位でも同じことが起きています。SpaceXAI で Grok Bot に携わる Lauren Tan 氏は講演で、まだ SpaceXAI の一部になる前の Cursor に入社し、新しいエージェント画面の性能改善を任された当時のことを話しています。PR が壁のように押し寄せ、マージの速さに追いつけなかったといいます。アプリの性能が落ちていないかも分からず、Chrome DevTools でトレースやヒープスナップショットを見る手作業に追われたそうです。また同氏は、規約のチェックを人のコードレビューだけに頼ると、変更を1行ずつ読んで指摘し続けることになり、PR のペースが上がると回らなくなるとも指摘しています4。 コードを書く作業が速くなると、人が関わる部分がボトルネックになります。レビューや動作確認だけでなく、人が1ステップずつ付き添うやり取りや、コマンドを1つずつ承認する操作も同じように詰まります。Tan 氏も、すべてのチャットに付き添って直し続けていた頃は自分がボトルネックだったと話しています4:1。これからの章で見る3つの手法は、いずれもこの詰まりをほどくためのものです。 クラウドでの実行: 人が付き添わなくても、エージェントを並列に走らせられるようにする サンドボックスによる隔離: コマンドを1つずつ人が承認しなくても、安全に実行できるようにする レビューと検証の自動化: 人が全行を読まなくても、成果物を確かめられるようにする 手元からクラウドへ 手元で動かすときの限界 手元のエディタでエージェントを使うとき、人は1ステップごとにやり取りして結果を見ています。Cursor によると、こうしたリアルタイムのやり取りが要るうえに、エージェント同士が手元のマシンの資源を取り合うため、同時に扱えるのは数本が限界です1:1。 クラウドでは「渡して、受け取る」 クラウドのエージェントは1本ごとに専用の VM で動きます。開発者は仕事を渡したら別の作業に移り、エージェントは何時間もかけてテストと修正を繰り返します。戻ってくるのは diff だけではなく、ログ・動画・ライブプレビューといった、短時間で中身を判断できる成果物です1:2。 Cursor は、この変化によって人の役割が「1行ずつ導くこと」から「問題を定義し、レビューの基準を決めること」に移るとしています1:3。 長時間エージェントの例として、Cursor は研究プレビューの参加者による次のような実行を挙げています3:1。 既存のオープンソースツールと連携する新しいチャット基盤の構築(36時間) 既存の Web アプリをもとにしたモバイルアプリの実装(30時間) 認証と RBAC(ロールベースのアクセス制御)の仕組みのリファクタリング(25時間) 長時間エージェントは従来より大幅に大きな PR を作り、マージ率は他のエージェントと同程度だったとされています。ただし自律的に大きな仕事をさせると、最初の小さな思い違いが最後には大きな誤りになりかねません。そのため Cursor の長時間エージェントは、すぐに作業を始めず、まず計画を出して承認を待つ作りになっています。実行中もその計画を使い、複数のエージェントが互いの作業を確かめ合うことで、大きな仕事を最後までやり切ります3:2。 クラウドでエージェントを動かす構成の一例 細部は製品ごとに違いますが、Claude Code と Cursor の公開情報をもとに全体の流れをまとめると、次のようになります。 VM を起動する: 依頼ごとに隔離された VM を用意します。Claude Code のクラウドセッションでは、Anthropic が管理する VM がセッションごとに割り当てられます5。 リポジトリを clone する: リポジトリにコミットされたエージェント向けの設定も一緒に入ります。Claude Code では次のものが読み込まれます。 リポジトリの CLAUDE.md .claude/ 以下のルール・skill・サブエージェント・コマンド .claude/settings.json の hook と権限ルール(複数のセッションを束ねる Project 機能を使わず、1つのリポジトリだけを扱うセッションの場合) .mcp.json の MCP サーバー(1つのリポジトリだけを扱うセッションの場合) 一方、手元の ~/.claude/ にある個人用の CLAUDE.md や skill・コマンド、手元の設定ファイルに追加した MCP サーバーは引き継がれません。プラグインは、ユーザー設定で有効にしたものも、リポジトリの .claude/settings.json に書いたものも自動では入りません。クラウドでも使いたいルールや skill、MCP サーバーは、リポジトリに含めてコミットしておく必要があります5:16。 環境を準備する: セットアップスクリプトで依存パッケージなどを入れます。Claude Code では、スクリプトがエラーなく終わり、実行時間がおおむね5分以内であれば環境がキャッシュされ、次回から速く始まります。エラーで終了した場合は、セッション自体が始まりません5:26:1。 エージェントが作業する: 編集・テスト・動作確認を繰り返します。Cursor のクラウドエージェントは、VM の中でブラウザやアプリを実際に操作して動作を確かめます7。 ブランチに push する: 変更はブランチに push され、PR を通じて人やレビュー用のエージェントに渡ります。Cursor では動画・スクリーンショット・ログもあわせて残るため、手元で動かさなくても変更の結果を確かめられます7:15:3。 別のエージェントがレビューする: 後の「エージェントの成果をどう確かめるか」の章で詳しく書きます。auto-fix を有効にしていれば、レビューの指摘や CI の失敗を受けてエージェントが変更を直し、同じ PR に push し直します5:48。 作業中の通信は、VM の外にあるプロキシを通すのが基本です。Claude Code のクラウド環境では、ネットワークアクセスを「なし(None)」「信頼済み(Trusted)」「すべて(Full)」「カスタム(Custom)」の4種類から選びます。既定は「信頼済み」で、パッケージレジストリや GitHub など許可リストにあるドメインへ通信できます。git の本来の認証情報や署名鍵は VM の外に置かれます。VM の中の git は範囲を絞った仮の認証情報を使い、プロキシがそれを確かめてから本物のトークンに差し替えて認証します5:56:2。 ただし、これですべての通信と認証情報が閉じるわけではありません。「なし」の設定でも、Claude Code 自身が Anthropic API とやり取りする通信は残るため、そこを通じてデータが VM の外へ出る余地はあります。また、外部 API のキーなどを VM の外に置き、プロキシが付ける仕組み(Network secrets)もありますが、それを使わずに環境変数へ直接設定したトークンは、そのまま VM の中に入ります。プロキシはブランチの削除や、タグなどブランチ以外の push を拒否しますが、どのブランチに push できるかは制限しません。main などを守るには、GitHub 側のブランチ保護ルールが要ります5:66:3。 頭脳と手を分ける基盤の設計 こうしたクラウドエージェントの裏側では、実行環境と制御の仕組みがどう分けられているのでしょうか。Anthropic は、長時間動くエージェントを Claude Platform 上でホストする基盤サービス「Managed Agents」の設計を公開しています9。最初はセッション(起きた出来事のログ)・ハーネス(Claude を呼び出してツールの実行を振り分ける枠組み)・サンドボックスを1つのコンテナに入れていました。この形では、コンテナが落ちるとセッションの記録ごと失われ、応答しなくなったコンテナは手で復旧させる必要がありました。 そこで、次の3つを切り離しました。 頭脳: Claude とハーネス 手: 実際に操作を行うサンドボックスとツール セッション: イベントの追記ログ ハーネスはサンドボックスを execute(name, input) → string という共通のインターフェースで呼ぶだけになり、サンドボックスは落ちても作り直せる使い捨てのものになりました。セッションのログもハーネスの外にあるので、ハーネスが落ちてもログから続きを再開できます9:1。 この分け方は、セキュリティの境界にもなっています。以前の設計では、Claude が生成したコードが認証情報と同じコンテナで動いていたため、プロンプトインジェクションで認証情報を読まれ、制限のないセッションを勝手に起動されるおそれがありました。分けた設計では、認証情報をサンドボックスから届かない場所に置きます。git については、サンドボックスの初期化時にリポジトリごとのトークンで clone し、ローカルの git の設定に組み込んでおくので、エージェント自身はトークンを扱わずに push や pull ができます。MCP の OAuth トークンは外部の保管庫に置かれ、専用のプロキシ経由で使われるので、サンドボックスからもハーネスからも、認証情報そのものには届きません9:2。 実行環境を自社内に置く場合 規制の厳しい業界などで、コードや機密情報、ビルド成果物を自社の環境から出せない組織もあります。Cursor はそうした組織向けに、コードの保管とツールの実行を自社のネットワーク内で行うセルフホスト型のクラウドエージェントを提供しています10。Claude Code のクラウドセッションも、自社のインフラで動かすセルフホスト環境に対応しています5:7。 ただし、どちらの場合もモデルの推論は外部で行われます。Cursor のセルフホスト型では、推論と計画を Cursor 側のハーネスが受け持ち、自社内のワーカーで実行したツールの結果が、次の推論のために Cursor 側へ送られます10:1。Claude Code のセルフホスト環境も、自社のネットワークから Anthropic API を呼びます5:8。「何も社外に出ない」わけではない点に注意が必要です。 サンドボックスによる隔離 承認ダイアログでは守れない 手元でエージェントにコマンドを実行させるとき、1つずつ人が承認すれば安全に見えます。しかし Anthropic は、承認を押し続けるうちに中身を見なくなる「承認疲れ」が起き、かえって安全でなくなると指摘しています11。Cursor も同じ点を挙げ、複数のエージェントを並列に動かすと承認のたびに頭を切り替える必要があり、状況はさらに悪くなるとしています12。 そこで両社とも、エージェントをサンドボックスの中で自由に動かし、許可された範囲の外(インターネットへの通信や、作業ディレクトリの外のファイルなど)に出るときだけ承認を求める仕組みを用意しています。Anthropic の社内利用では、サンドボックスによって承認を求められる回数が 84% 減りました11:1。Cursor でも、サンドボックスで動くエージェントは承認待ちで止まる回数が 40% 減り、対応する OS ではリクエストの3分の1がサンドボックスで動いています12:1。 Claude Code の auto mode は、これとは別の仕組みです。エージェントがツールを呼ぶたびに、分類器が危険な操作かどうかを審査します。安全な操作はそのまま通し、危険な操作は止めて、Claude に別のやり方を促します。ただし分類器が危険な操作を見逃すこともあるため、Anthropic はコンテナや VM など隔離された環境での利用を勧めています13。 ファイルとネットワークの両方を閉じる Anthropic は、サンドボックスにはファイルとネットワークの両方の隔離が要るとしています。ファイルの隔離で書き込みできる場所を絞り、ネットワークの隔離で、利用者が許可していない通信先への接続を止めます。ネットワークの隔離がなければ、乗っ取られたエージェントが SSH 鍵のような機密ファイルを外に送れます。ファイルの隔離がなければ、重要なファイルを書き換えるなどしてサンドボックスを抜け出し、通信の制限まで突破できてしまいます。同社は、この2つを組み合わせることで、プロンプトインジェクションが成功しても被害をサンドボックスの中に閉じ込められるとしています11:2。 Claude Code のサンドボックスでは、作業ディレクトリや一時ディレクトリの外には書き込めません。作業ディレクトリの中でも、.claude/ や .git の hook・設定といった保護されたパスへの書き込みは止められます。一方で、読み取りは既定で広く許されています。~/.ssh や ~/.aws/credentials のような認証情報のファイルも、既定では読めます。読まれたくないファイルは、sandbox.filesystem.denyRead や sandbox.credentials の設定で別に塞ぐ必要があります。通信のほうは、許可する通信先が初めは空で、利用者が許可した先にだけつながります。 また、OS のサンドボックスが囲うのは、Bash などで実行するシェルコマンドとその子プロセスだけです。Read・Edit・WebFetch などの組み込みツールはサンドボックスの対象外で、denyRead も Read ツールには効かないため、権限ルールの側で制限する必要があります。hook やローカルの MCP サーバーも、サンドボックスの外でそのまま動きます14。 サンドボックスにも抜け道はある サンドボックスがあれば安全というわけでもありません。セキュリティ企業の Pillar Security は、開発者の手元で動く Cursor、OpenAI の Codex、Google の Gemini CLI と Antigravity について、サンドボックスを抜けたり境界を迂回したりする方法を見つけて再現しました。7件のうち5件は公表時点で修正済みですが、Antigravity の2件は Google が悪用は難しいとして重要度を引き下げています15。見つかった方法は、次の4つの失敗パターンにまとめられています。 禁止リストは環境の複雑さに負ける: 「基本は許可し、危険なものだけ禁止する」設定では、禁止の書き漏れが必ず残る ワークスペースの設定ファイルは実行コードと同じ: エージェントが書き込めるファイル(.vscode や git の設定、hook、Python の仮想環境など)を、あとでサンドボックスの外のツールが信頼して実行してしまう コマンド名だけの許可リストは引数や設定で抜かれる: git show のような読み取り専用に見えるコマンドでも、引数や設定によってはファイルを書いたり hook を動かしたりできる 手元のデーモンは箱の外にある: Docker のソケットのように、サンドボックスの外で動くサービスに届けば、隔離は意味をなさない 2つ目は特に見落としやすい点です。プロジェクトの設定ファイルは、これまで人が書いてレビューする前提でした。エージェントが書くようになると、その前提が崩れます。報告の中には、ワークスペースに置かれた .claude の hook 設定を Cursor が読み込んで実行した事例(修正済み)や、.git 以外の名前の git 設定でパスの保護をすり抜けた事例もあります15:1。製品ごとに、保護しているパスには差があります。 また、クラウドのエージェントが作った PR を手元に取り込むときは、ファイルはサンドボックスの外で書き込まれます。取り込む前に、.claude/ や .vscode/ などの設定ファイルの変更が含まれていないか、特に注意して見る必要があります。 エージェントの成果をどう確かめるか 作る役と評価する役を分ける Anthropic は、長時間動くアプリ開発のハーネスを作る中で、ある傾向を報告しています。エージェントに自分の成果物を評価させると、人から見て明らかに凡庸な出来でも自信満々に褒めるというものです。この傾向はデザインのような主観的な課題で特に強く出ます。検証できる課題でも判断を誤ることがあり、こうした自己評価の甘さに対処するため、作るエージェントと評価するエージェントを分けました16。 フロントエンドのデザインでこの仕組みを試したあと、フルスタック開発へ広げた最初の構成(Opus 4.5 を使用)では、役割を3つに分けています16:1。 planner: 1〜4文の依頼を製品の仕様に広げる generator: 仕様から1機能ずつ実装する evaluator: ブラウザ自動化ツールの Playwright で、動いているアプリを実際に操作し、UI の機能や API、データベースの状態を確かめる 実装は、1機能ずつ「スプリント」と呼ぶ区切りに分けて進めます。各スプリントを始める前に、generator と evaluator は完了条件を決めて合意します。evaluator はその完了条件に沿って動作を確かめ、見つけたバグや、デザイン・コード品質などの採点基準をもとに合否を決め、基準に届かなければ差し戻します。 ただし、役割を分けるだけで問題が解決したわけではありません。初期状態の Claude は評価役としても甘く、見つけた問題を自分で「大したことない」と判断して通してしまうことがありました。ログを読んでプロンプトを書き換え、評価役が疑い深く確かめるように調整するには手間がかかりました。また、レトロゲームの制作ツールを作った実験では、仕様を大きく広げて長く作業させたため、ハーネス全体の費用が単独で動かす場合の 20倍(20分・9ドルに対して 6時間・200ドル)を超えました。さらに、より新しいモデル(Opus 4.6)では、分割しなくても長い作業をこなせると判断してスプリントの仕組みを外し、一通り実装し終えた段階で評価と修正を回す形に簡略化しています。Anthropic は、評価役は常に置くものではなく、課題が今のモデル単独の力を超えるときに費用に見合うと結論づけています16:2。 なお、このハーネスの土台になった以前の実験では、評価役を別に置かず、作業するエージェントが十分にテストしないまま機能を完了扱いにしがちでした。このときは、人のユーザーと同じようにブラウザ自動化ツールで確かめるよう明示するだけでも、エンドツーエンドの自己検証はおおむねうまくいったと報告されています17。 レビューもエージェントがする アプリを動かして確かめるだけでなく、PR のコードレビューにもエージェントが使われています。GitHub の PR に対して動く Claude Code の Code Review(Team・Enterprise 向け)では、次の流れでレビューが行われます8:1。 複数のエージェントが diff と周辺のコードを並列に調べ、問題の候補を見つける 次の段階でその候補を実際のコードと照らし合わせ、誤検知を除く 残った指摘の重複を除き、重大度の順に並べる 結果を PR にコメントする このレビューは diff と周辺のコードを読んで行うもので、ビルドや実行はしません8:2。動かした証拠は、前の節のような検証の仕組みで別に用意します。 クラウドセッションで PR の自動修正(Auto-fix)を有効にすると、Claude が PR を監視し、直し方に確信があり、以前の指示とも矛盾しなければ、CI の失敗やレビューの指摘を自動で直して push します。指摘が複数の意味に取れる場合や設計に関わる場合は、直す前に人に確認します5:9。 Cursor の Bugbot も PR を自動でレビューするエージェントです。ベータ終了時の発表によると、期間中に 100万件以上の PR をレビューして 150万件以上の問題を見つけました。見つかったバグの 50% 以上は、PR のマージまでに解決されています18。 それでもすり抜ける レビューを重ねても、問題がすべて見つかるわけではありません。2026年4月に Anthropic が公開した、Claude Code などの品質低下についての事後分析によると、原因は3つの別々の変更でした。そのうちコードの不具合だった1つ(1時間以上放置されたセッションを再開するとき、1回だけ消すはずの古い思考の履歴を毎ターン消してしまうバグ)は、人と自動ツールによる複数のコードレビューや、単体テスト・エンドツーエンドテスト・自動検証・社内での利用をすべて通り抜けました。このバグは複数の仕組みにまたがるものでした。調査の中で、関連する複数のリポジトリまで渡して問題の PR に Code Review をかけ直したところ、Opus 4.6 は見つけられませんでしたが、Opus 4.7 は見つけました19。モデルの性能に加えて、十分な文脈をレビューに渡せるかどうかで、見つかる問題が変わるということです。 研究でも、エージェントが作った PR の扱いは調べられています。2025年前半を中心に GitHub 上で作られたエージェントの PR を集めたデータセット(AIDev)のうち、人気リポジトリを分析した研究では、エージェントは作業の速さでは人を上回ることが多い一方、機能開発やバグ修正をはじめ、全体のマージ率は人より低いとされています20。同じデータセットから約3.3万件の PR を調べた別の研究では、ドキュメント(84%)・CI(79%)・ビルド(74%)の更新はマージされやすく、性能改善(55%)とバグ修正(64%)は最もマージされにくいと報告されています。マージされなかった PR は変更範囲が大きく、CI の失敗も多い傾向がありました21。どの種類の仕事をどの大きさで任せるか、PR を出す前にどこまで検証を通させるかによっても、受け取る側のレビューの負担は変わると考えられます。 信頼を作る順番 では、エージェントに安心して仕事を任せられる環境は、何から整えればよいのでしょうか。Lauren Tan 氏は、エージェントを並列に動かす前に、まずエージェントを信頼できる状態を作る必要があると話しています。信頼がないまま 100個のサブエージェントやクラウドエージェントを動かしても、品質の低い PR やリグレッション、バグが大量に出てくるだけだといいます4:2。 Tan 氏は、エージェントを信頼するための柱として、次の3つを挙げています4:3。 正しさを確かめる検証: エージェント自身にアプリを動かさせ、機能が意図どおりに動いたという証拠を集めさせる。Tan 氏は Cursor で、検証用の skill に2つのものを入れていた。1つは、アプリにどんな機能があり、ユーザーがどう操作してたどり着くかをまとめた「feature map」で、エージェントに文脈を与える。もう1つは、実際のアプリを動かして証拠を集める CLI で、操作の手段を与える。ただし検証で確かめられるのは主に正しさで、性能が十分か、コードの質が高いかまではあまり分からない エンジニアのように働かせる skill: 性能やコードの質を保つために、デバッグや機能開発の進め方を教える skill。Tan 氏はその集まりを、Cursor・Claude Code 向けの skill 集「pstack」として Cursor のプラグイン集で公開している エージェントが扱いやすい構造への作り直し: コードベースそのものを、エージェントが既定で正しいコードを書く形に作り直す。Tan 氏はこれを最も重要な取り組みの1つとしている 間違いを直すときの5つの置き場所 Tan 氏は、エージェントの間違いを直すたびに対策をどこに置くかについて、5つの場所を挙げています。上から順に検討するよう勧めていて、上の2つは強制でき、3つ目からは導くだけの仕組みになります4:4。 コードベース: 悪いパターンを、データ構造やアルゴリズムでそもそも書けない形にする。エージェントは読んだファイルにある既存のパターンを広げるので、コードベースそのものがエージェントの記憶になる。逆に、その場しのぎのコードやそれを説明するコメントがあると、エージェントはそれを真似て広げ、事実上の標準になってしまう。エージェントはそうしたコメントを、根本の問題を直さない言い訳にも使う 静的解析(lint・コンパイラ・CI): リポジトリで強制できる制約。同じ間違いが続いたら lint ルールにする。もっと良いのは、コードベースを直して間違いを書けなくすること ルール・Bugbot: 強制ではなく、導くための仕組み。たいていは効くが、エージェントが読み忘れたり、エージェントを動かす人が無視したりすることがある skill: ルールと同じく導くための仕組みで、使われないことがある スタイルガイド(人のレビューで守らせる規約): 人のコードレビューでしか効かず、2章で触れたとおり PR が増えると回らなくなる。Tan 氏は、人のレビューは何が足りないかを見つける出発点にとどめ、上の4つに時間をかけるよう勧めている pstack のガイドによると、たいていのエージェントの作業で一番遅い工程は検証です。ふだんは人の確認を待つことになるからです。エージェント自身が検証できるようにすれば、人がボトルネックではなくなります。逆に検証を飛ばしたままエージェントを増やしても、確認されていない成果が増えるだけだといいます22。ガイドの別の章では、エージェントを放っておいて回すのは、良い状態が分かっていて、各段階で動作を証明できるといった4つの前提がそろってからにすべきだとしています。それまでは、人が見ながら回します。そのうえで、夜通し任せても安全にするための仕組みとして、エージェントが合否を判定できる完了条件、別の作業ディレクトリに切り出した Git の worktree かクラウドエージェント、朝に読み返せる判断ログの3つを挙げています23。 人の仕事は意図と検証へ 公開されている情報をたどると、エージェントに大きな仕事を任せる開発の手法は、次の4つに整理できます。 任せる前に: 何が満たされれば完了か(通すべきテストや確認の方法)を書いて渡す。長い仕事は、先に計画を出させ、人が承認してから始めさせる 動かす場所: ファイルとネットワークの両方を制限したサンドボックスか、隔離されたクラウドの VM で動かす。認証情報は VM の外に置いてプロキシに付け替えさせ、~/.ssh のように既定で読めてしまうファイルは、サンドボックスと権限ルールの両方で塞いでおく。エージェントが書き換えた設定ファイルは、取り込む前に確かめる 確かめ方: テストが通るだけでなく、実際に動かした証拠を出させる。課題が今のモデル単独では確実にこなせないときは、評価を別のエージェントに任せ、評価役が疑い深く確かめるように調整する。レビューもエージェントに任せられるが、関連するコードなど十分な文脈を渡す 繰り返す間違いへの対処: 人のレビューで繰り返し見つかる問題は、まずコードの構造や lint で書けないようにし、それができないものはルールや skill に移していく アセンブリから高級言語に移ったとき、人は機械に近いコードを1命令ずつ書いて読むことをやめ、ソースコードの上で意図を確かめるようになりました。エージェントの場合も、人が読む対象はコードの1行1行から変更の意図へ移りつつあります。2章で触れた、独自のソース管理システムへ移った Anthropic のチームも、そのシステムへの変更はすべてレビューしていますが、コードを1行ずつ読むのではなく、変更の意図を確かめるようになったといいます。ただしコンパイラと違って、エージェントの出力は毎回同じとは限らず、システムの前提を破るような間違いもします2:1。だからこそ、エージェントに仕事を任せるには仕組みが要ります。サンドボックスで行動の範囲を絞り、lint やコードの構造で間違いを防ぎ、実際に動いた証拠で確かめる仕組みです。 作業の場所が手元からクラウドへ移るほど、人は1ステップずつ付き添う役から離れていきます。人の仕事は、問題を定義して完了の条件を決め、最後にその条件が満たされたかを確かめることになります1:4。 脚注 Cursor, "The third era of AI software development" cursor.com ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ Anthropic, "Redesigning source control at Anthropic" anthropic.com ↩︎ ↩︎ Cursor, "Expanding our long-running agents research preview" cursor.com ↩︎ ↩︎ ↩︎ Lauren Tan, "here's how i shipped 2,500 PRs last month to production"(講演動画、X、2026年9月) x.com ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ Claude Code ドキュメント "Use Claude Code in the cloud" code.claude.com ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ Claude Code ドキュメント "Configure cloud environments" code.claude.com ↩︎ ↩︎ ↩︎ ↩︎ Cursor, "Cursor agents can now control their own computers" cursor.com ↩︎ ↩︎ Claude Code ドキュメント "Code Review" code.claude.com ↩︎ ↩︎ ↩︎ Anthropic, "Scaling Managed Agents with stable interfaces" anthropic.com ↩︎ ↩︎ ↩︎ Cursor, "Run cloud agents in your own infrastructure" cursor.com ↩︎ ↩︎ Anthropic, "Making Claude Code safer with sandboxing" anthropic.com ↩︎ ↩︎ ↩︎ Cursor, "Implementing a secure sandbox for local agents" cursor.com ↩︎ ↩︎ Anthropic, "Auto mode for Claude Code" claude.com ↩︎ Claude Code ドキュメント "Sandboxing" code.claude.com ↩︎ Pillar Security, "The Week of Sandbox Escapes" pillar.security ↩︎ ↩︎ Anthropic, "Harness design for long-running apps" anthropic.com ↩︎ ↩︎ ↩︎ Anthropic, "Effective harnesses for long-running agents" anthropic.com ↩︎ Cursor, "Bugbot is out of beta" cursor.com ↩︎ Anthropic, "An update on Claude Code quality reports" anthropic.com ↩︎ Hao Li ほか, "The Rise of AI Teammates in Software Engineering (SE) 3.0" arxiv.org ↩︎ Ramtin Ehsani ほか, "Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub" arxiv.org ↩︎ Lauren Tan, pstack guide "Verify the result and open a PR" github.com/cursor/plugins/blob/main/pstack/docs/g… ↩︎ Lauren Tan, pstack guide "Run work while you sleep" github.com/cursor/plugins/blob/main/pstack/docs/g… ↩︎

My 6 year old daughter designed a fully-fledged unicorn game and Claude Sonnet built it in under a month. Every sprite, sound and map is made from scratch We built a private unicorn game for my six-year-old daughter, with Claude Sonnet 5.5 as the coding agent for all of it. I'm a quantitative engineer with 20+ years of experience but i never made a game before. My daughter designed most of the maps and the playground games, and she gave the notes that shaped the rest. The initial thing was just a small forest map and finding all the 6 unicorns. What it is: A pixel-art sandbox that runs in a phone/tablet browser, installs to the Home Screen and plays offline. You lead a unicorn around 8 places, find 5 friends who follow in a herd, and cast 6 kinds of magic that affect certain items in the game. There are playground mini-games, and an optional spelling mode that a parent switches on. Saves stay on the device, with optional cloud backup. What Sonnet did: Claude wrote all the code: about 136k lines of TypeScript across the game, the build tools, a Cloudflare Worker and 3,000+ tests. That includes: - A software 3D renderer. Unicorns, buildings and trees are small 3D models written as code. The renderer draws them at 4x size with a fixed light and ambient occlusion, then reduces them to hard-pixel sprites on atlases. No Blender, no sprite packs. - A sound synthesizer. All 75 effects and 9 music loops are generated from code, with no samples. - A map compiler that proves every door, spawn and friend is reachable. - A game loop, pathfinding, and a herd that follows the leader. How we worked. The loop was simple. My daughter played the latest build and told me what she liked and what to change. I wrote her notes down (sometimes 25 items in one round, from "a place with a slide" to what a door should do) and gave them to Sonnet. The next day she played the result. Then again. She also learned how software gets made, because she could see her idea turn into a thing she could play and also I explained a lot about how stuff works to her. Around that loop, a few things made it work: - A written plan first: We started from a tech spec, and Claude built small throwaway spikes before committing to anything. Before using Phaser it ran a seven-check test of the engine (animation, tile maps, depth sorting, pixel sampling, touch under zoom, audio unlock). It did the same for the Cloudflare backend. - A style check before scale. Before rendering hundreds of frames, Claude drew one unicorn, then a forest clearing, and checked that they looked like the same world. It also dropped an idea that failed: a pure 3D face looked blank, so the eyes and mouth became hand-placed pixels. - A decision log. Claude kept a row for every proactive choice with the reason and the evidence: 245 rows over 11 deploys. It also kept a handoff file so a new session could pick up exactly where the last one stopped. - Tests that found real bugs: When the followers flickered between walking and standing, Claude measured it in the running game (20 flips in 103 seconds), fixed it, and measured again (none in 128 seconds). It also wrote a test that failed on the old code. When a browser test failed once, it worked out the odds of what the test assumed before blaming the machine. - Checking what it couldn't see or hear: Claude couldn't watch the game or listen to it, so it screenshotted and read the pictures. It measured the sound with loudness meters and a signal analyser at the output. - One thread: I always asked Claude not to use subagents, so I could follow a single conversation and audit what it did so that I always understand what is happening. - Some notes: The repo has a file listing what is built, what was tested and what wasn't. It has run on two iPhones and a Mac, and we mostly play it on a Kindle Fire. When the Kindle felt choppy during spells, Claude added a low-end mode that draws fewer pixels and fewer particles, and it switches itself on for Fire tablets automatically detecting low fps. You can play it entirely for free here: unicorn-academy-game.github.io Source: Unicorn-Academy-Game/Unicorn-Academy-Game.github.io I will make everything fully open-source once i polish the educational engine. Overall I'm just INSANELY impressed by what Sonnet can do. I haven't felt like this since I was a teenager coding bots doing Mephisto runs in Diablo 2. I'm going to start making silly games for myself when I have the time :D And this game will probably be growing up with my daughter and develop into an open world game to help her with reading/writing/math skills. This is fan-made and inspired by characters from a book/Netflix series I don't own (Unicorn Academy). The Phaser engine and the Fredoka font are the only parts not made by Sonnet here. Well, and all the other open source libraries. But no other 3rd party graphical assets were used. I'm not a fan of image-gen. I like everything procedural. I'm here to answer any questions about prompting, planning, skills I'm using, etc. Ask me anything. Edit: look into github.com/cursor/plugins/tree/main/pstack. it's a game-changer, imo. there is a claude version.

Every official Cursor plugin lives in one repo, from GitHub and Playwright to parallel cloud agents, plus a tool to scaffold your own. 🔗 cursor/plugins #cursor #cursorplugins #typescript

How to Make Your AI Coding Agent Prove Its Work Your AI agent says "Done." The build is green. The tests pass. Did it actually work? Did it do the correct thing? Most of the time, you only find out when you check it yourself. That makes you the verifier for every task, and the agent is only as fast as your review. I spent the last few weeks with pstack, a plugin by Lauren Tan (poteto) that changes this. I turned the official guide into a 19-minute video and 24 Shorts. In this post, I will teach you the core habit, show you the prompts that make it work, and point you to the part of the video for each topic. TL;DR If you remember one thing: give the agent a goal and a way to check it. /poteto-mode the export writes duplicate rows when a retry lands mid-run. repro first, then fix and verify. 1. Install pstack and run /setup-pstack. Say yes when it offers a verification skill. 2. Write prompts that can fail. A goal, a done check, and the proof you want to see. 3. Steer with principle names. "apply prove it works" redirects the agent better than a paragraph. The Problem Here is a prompt most of us have typed: fix the export bug Can you spot what's wrong? There is no way to know when it is done. The agent will change some code, run the build, and report success. A green build proves the code compiles. It does not prove the export stopped writing duplicate rows. So you open the app, run the export, and count rows yourself. Every task ends with you checking by hand. The scary part is that this gets worse as agents get faster. More output with no proof only means more unchecked work for you. The Solution pstack is a set of skills, playbooks, and principles for AI coding agents. It started in Cursor, and it now installs in Claude Code too. The entry point is one command, /poteto-mode. You give it a goal. It matches one of 23 playbooks, copies that playbook's steps into a todo list, and calls the other skills as each step needs them: your prompt └── /poteto-mode ├── question → Investigation ─┐ ├── defect → Bug fix ├─→ verify and show evidence ├── new behavior → Feature │ ├── structure only → Refactoring │ └── measured slowness → Perf issue ─┘ Notice how every route ends in the same place. The reply carries the evidence: the commands run, their output, the stored value, the row count. You read proof instead of producing it. Now the bad prompt becomes this: /poteto-mode the csv export drops its last row since yesterday's deploy. failing job id is 4812. repro first, then fix. done means the 60k-row fixture exports every row. show me the row counts before and after. It is longer, but every part does work. And once the conversation has context, your follow-ups shrink to continue or keep going until done. Here is the full walkthrough, from setup to overnight runs: {% embed youtube.com %} How to Use It 1) Install and pick your models In Cursor: /add-plugin pstack /setup-pstack In Claude Code, add the marketplace, install, and then every pstack command takes a pstack: prefix: /plugin marketplace add cursor/plugins /plugin install pstack@cursor-plugins /pstack:setup-pstack /setup-pstack detects your models, asks for a reasoning budget, and writes a small rule file every skill reads. At the end it offers to create a verification skill for your project. Say yes. > Important: The verification skill is the part that pays off the most. An agent that can drive your app checks its own work and keeps going until the check passes. An agent that can't hands every result back to you. In the video: setup at 0:26, the verification skill at 10:33. 2) Write a prompt that can pass or fail A useful prompt carries up to five things: - The goal. What is wrong, or what you want. - The done check. It must be able to fail. "Make it better" is not a check. - The proof you want. Command output, a video of the flow, a before and after number. - What you already know. A log line, a job id, a repro step. - The real constraints. "repro first", "zero behavior change", "don't change any code yet". Leave out two things: the how, and your theory of the cause. A stated guess narrows the search to wherever you pointed. Let the agent restate the problem first: /poteto-mode read this thread. restate the underlying issue in your own words, in plain english. don't change any code yet. A misreading shows up in the restatement, before any code exists. In the video: writing a good prompt at 2:39. 3) Steer with principle names pstack ships 24 principles. You never call them directly. /poteto-mode reads them on every multi-step task, and you use their names to redirect the agent mid-task: apply prove it works. run the real import flow and show me the written records. use subtract before you add. delete the obsolete adapters first, then design what's left. One name points at a full rule the agent already read. That is why a single line is enough. This is what the 24 Shorts are for. Each one is about 80 seconds: the rule, a small example, and how to tell if the agent applied it. Good ones to start with: - #17 Prove It Works: check the real thing, not a proxy, a self report, or "it compiles". - #18 Fix Root Causes: trace the problem to its cause and fix it there. - #1 Laziness Protocol: the most result with the least code and complexity. - #22 Guard the Context Window: every token in the session should be worth its cost. - #24 Encode Lessons in Structure: turn a repeated correction into a tool, a check, or a lint. All 24 are in one playlist. 4) Leave it running overnight This is the payoff. An agent that verifies its own work is an agent you can leave alone with a hard task. The handoff does not need to be long: /poteto-mode im going to bed. migrate every caller to the new parser in a fresh worktree off main. done means zero old callers, all parser fixtures pass, old api deleted. keep a decision log. don't ask me before committing. /loop until done. if you're truly stuck after a few hours, stop and write up why. Each line buys you something: 1. "im going to bed" tells the agent to stop asking and keep going. 2. "done means..." gives every loop iteration a check it can run. 3. "fresh worktree" keeps it away from anything else you have open. 4. "keep a decision log" gives you something to audit in the morning. 5. The escape hatch lets it stop at a real dead end instead of reinterpreting the goal for eight hours. > Caveat: A loop you don't trust only produces unchecked work faster. Do the task once while you watch, and get the verification skill working, before you walk away. In the video: the overnight chapters start at 11:51. Tradeoffs pstack is not free. Here is what you pay. Pros - Replies carry evidence, so you review proof instead of re-running everything. - Short prompts work, because the playbook holds the structure. - Principle names give you a precise way to correct a drifting agent. - Safe long runs become possible once verification works. Cons - More tokens. Subagents and review panels cost money. /setup-pstack lets you pick a smaller budget or cheaper models. - Slower on small edits. A one-line change does not need a playbook. Save /poteto-mode for work that needs rigor. - Setup work. The verification skill needs a way to drive your app, and that takes a first run to get right. Best Practices 1. Don't list skills in the prompt. "use /how then /architect then /arena" fights the order the playbook already has. State the goal; name a skill only to override a default. 2. Never accept a green build as proof. Ask for the real command, flow, or stored value. 3. Ask for prototypes before you pick a design. The first design is only the first shape the model thought of. 4. One worktree per parallel agent. Otherwise they overwrite each other. 5. Vet numbers before you share them. A warm cache can fake a speedup; run /benchmark-checklist. 6. Fix the repo, not the chat. /correct turns a repeated mistake into a check, so the next run can't repeat it. The video ends with 6 common mistakes at 18:10, if you want them in under a minute. Conclusion pstack does not make the model smarter. It changes what "done" means. A goal plus a way to check it is the whole idea, and everything else in the plugin builds on that. Start with one real, small task: /poteto-mode add a --json flag to this command. text output stays byte-identical. verify both. Then watch the full guide for the rest: understanding code with /how and /why, comparing designs with /arena, landing a stack of PRs, and building your own mode. pstack was created by Lauren Tan (poteto). My videos are an unofficial explainer based on the official guide; they are not made by or affiliated with Cursor. I drafted this post with help from an AI agent and reviewed it myself. If you made it this far, thank you for reading. What evidence do you ask your coding agent for before you trust a change?

yeah this is pretty much mandatory for any length of text I need to read from them github.com/cursor/plugins/blob/main/pstack/skills…