steveyegge

Claude Code に開発チームを組ませて、自分は「判断」だけする plugin「crew」を作った はじめに 個人で iOS / Android アプリを開発しています。サーバーも含めて 1 人なので、ここしばらくは Claude Code のセッションを何本も並べて、溜まった課題を並行で片付けてきました。 そのために作った自作スキルが orchestrate です。私が話す「オーナー」のセッションが課題を洗い出してチケットにし、「進行役」のセッションがそれを 3〜5 本の「子」のセッションに配ります。子は worktree で開発して PR を出し、私がレビューして承認したら子がマージします。うまく回った日は、1 日で 48 本の PR がマージまで進みました。 一方で、回せば回すほど「詰まっているのは私だ」と感じる場面が増えました。この記事では、その経験から作り直した Claude Code の plugin「crew」を紹介します。 mickamy/crew-skill orchestrate でぶつかった壁 オーナーが忙しすぎる 最初は、オーナーが子への割り振りも報告の受け取りも兼ねていました。子からの報告が続くと、オーナーはそれを処理し終えるまで私のメッセージを読めません。私の質問が最大で 20 分ほど待たされることがありました。1 つのセッションは一度に 1 つのことしか処理できない、という当たり前の制約です。 そこで、子とのやりとりを受け持つ「進行役」を別のセッションに分けました。これはよく効きました。オーナーの手が空き、私の質問にすぐ答えてくれるようになりました。 中継した「承認」が止められる 子は、私の承認をオーナーから受け取って、自分でマージする設計でした。ところが auto mode の分類器に、子の gh pr merge が "Merge Without Review" として止められることがありました。CI の取り消しやブランチの削除を中継で頼んだときも同じです。 あとで公式ドキュメントを読んで、これは仕様だとわかりました。 a message from another session never counts as your consent code.claude.com ほかのセッションから届いたメッセージは、ユーザーの同意として扱われません。私の言葉を中継しても、受け取った側にとってそれは「私の承認」ではないのです。 人間が端末を見張っている ほかにも、細かな重さが積み重なっていました。 許可の確認が子の端末ごとに出るので、結局すべての端末を見て回ることになる セッション同士が名前で宛先を指定するので、名前の管理や、消えたセッションの扱いが要る context が尽きる前に新しいセッションへ交代するため、statusline と hook で使用率を見る仕組みを自作した 進み具合をファイルに手で書き続けた結果、2 つのセッションで合わせて 365 回の編集になった 似たものを調べてみた 作り直す前に、似たものを探しました。 multi-agent-shogun：人と話す将軍、仕事を分けて配り受け入れを判定する家老、実装する足軽。形は orchestrate とほぼ同じです Gas Town：窓口の Mayor、作業する Polecats、止まったエージェントを見張る Witness、マージの順番を管理する Refinery Claude Code の agent teams：公式の実験的機能で、team lead と teammates が共有のタスク一覧で動きます 驚いたのは、shogun の作者が自分の体制を解散していたことです。その経緯を書いた記事には、こうありました。 配管は、標準化された瞬間に競争力ではなくなる。 shogun が自前で作っていた連絡の仕組み（YAML の受信箱、ファイルロック、tmux の send-keys での合図）は、いまの Claude Code では組み込みになっています。サブエージェント、worktree、セッション間のメッセージです。 もう 1 つ気づいたのは、調べた中に「マージを 1 件ずつ人が承認する」ものがほとんどなかったことです。多くは自動でマージするか、最初の計画を 1 回承認するだけでした。 方針：配管は Claude Code に任せ、判断だけを運ぶ そこで crew は、次の方針で作り直しました。 私が話す相手は 1 つだけ マージできるのは、私の言葉を直接聞いたセッションだけ 私の注意は判断とレビューにだけ使う。エージェントで片付くこと、確かめられることは、私に届く前に片付ける 連絡や並列実行の仕組みは Claude Code のものを使い、crew は「誰が何を決めるか、何を聞くか、何を確かめるか」だけを持つ 仕組みを実験で確かめる すべてをサブエージェントで組むには、ドキュメントに書かれていない振る舞いを確かめる必要がありました。とくに気になったのは、振り分け役（dispatcher）を「何時間も動き続けるサブエージェント」にできるかです。サブエージェントは本来、頼まれた仕事を終えたら結果を返して止まるものだからです。 そこで、時間を潰すだけの小さなサブエージェントを使って試しました（Claude Code v2.1.319）。 試したこと 結果 dispatcher 役が子を起動して、ターンを終える 子が終わると自動で起きた。dispatcher が報告するまで、親には何も届かない 同じ状態の dispatcher に、親からメッセージを送る すぐに起きた。親への通知も、報告の催促もない 前面で sleep 60 して待つ ハーネスに止められた（sleep を刻んで回避するな、とも言われる） Monitor だけを待って、ターンを終える 約 20 秒で「報告を出せ」と催促され、その後もイベントのたびに親へ通知が届いた 動いている途中で main（親の会話）に送る 届いた。送ったあとも動き続けた サブエージェントが静かに待てるのは「自分の子のエージェントを待っている間」だけ、ということがわかりました。そこで、dispatcher は子のエージェントだけを待ち、CI のような待ちは子の中で済ませる、と決めました。worker は、自分の PR の CI を gh pr checks --watch で待ちます。 crew の設計 役割 あなた ⇄ lead あなたが話す唯一の相手。計画し、聞き、承認されたものをマージする ⇅ dispatcher チケットを配り、報告を受け、あなたが要るものだけを lead に回す ├ worker 1 チケット → 1 PR。自分の worktree で動く ├ worker └ worker lead：/crew:start を打ったセッションです。計画を立て、推奨を添えて質問とレビューを出し、承認されたものをマージします。自分ではコードを書きません。書いている間、ユーザーを待たせることになるからです dispatcher：lead のバックグラウンドのサブエージェントです。チケットを配り、報告を受け、すでに決まっていることには自分で答え、PR を事前に確認し、ユーザーが要るものだけを lead に回します worker：チケットごとに起動するサブエージェントです。自分の worktree で、1 つのチケットを 1 つの PR にします scout：読むだけのサブエージェントです。頼まれたときに、直すべきところを探します ユーザーが打つのは /crew:start だけです。バックグラウンドのサブエージェントの許可の確認はメインのセッションに出るので、すべて lead の端末に集まります。端末を見て回る必要はありません。 承認は 3 つの経路だけ lead に直接、PR を指して伝える（T3 OK など） リポジトリに needs-user-review と user-approved の 2 つのラベルがあれば、user-approved を付ける（スマホの GitHub アプリからも承認できます） PR の作成者が自分と別のアカウント（bot など）なら、GitHub の approve どの経路でも、マージするのは私の言葉を聞いた lead です。承認したあとに中身の変わる commit が入れば、承認は取り直しになります。 2 のラベルは、「外したら承認」ではなく「付けたら承認」にしました。外したら承認だと、付け忘れやラベルの削除が、そのまま承認に見えてしまいます。付けたら承認なら、間違いはマージされない側に倒れます。ラベルは、ユーザーが自分で作ったときだけ使います（オプトイン）。 ユーザーのリポジトリを汚さない 状態は .crew/ に置きます。中に * とだけ書いた .gitignore を置くので、ディレクトリが自分自身を ignore します。追跡しているファイルには触りません。.git/ や .claude/ は書くたびに確認が出る保護されたパスなので、避けました。 チケットと決まったことを書く board.md は、lead だけが書きます。進み具合は書きません。dispatcher が子から知っていますし、必要になれば git と PR から組み立て直せます。あの 365 回の手書きを、そもそも要らなくする作りです。 メモリはサブエージェントに届かない サブエージェントは CLAUDE.md を読み込みますが、メインの会話の auto memory は読み込みません。私が積み上げてきた「このリポジトリではこう書く」がメモリにしかないと、worker はそれを知らないまま書きます。 そこで /crew:rules を用意しました。メモリから働き方の決まりだけを拾って .crew/rules.md にまとめ、差分を見せてから書きます。dispatcher は、これをチケットごとに添えて渡します。 Agent Skill ではなく plugin にした理由 SKILL.md は Agent Skills という公開の規格になっていて、Codex などほかのツールでも使えます。それでも v1 は、Claude Code の plugin にしました。 plugin のサブエージェント定義では、本文がそのままシステムプロンプトになります。システムプロンプトは、compact のあとも元のまま残ります。一方、手順を依頼文として渡すと、会話の一部として要約されてしまいます。何時間も動き続ける dispatcher にとって、この差は大きいです。定義に書けば、scout を読むだけにすることや、worker を worktree で動かすことも強制できます。 また、compact のあとにスキル本体が入れ直されるのは約 5,000 トークンまでです。そこで lead の手順はその中に収め、権限と承認の決まりを先頭に置きました。 使い方 /plugin marketplace add mickamy/crew-skill /plugin install crew@crew-skill コマンド 何が起きるか /crew:start そのセッションが lead になります。何をするかを伝えるまで、何も始めません /crew:start <やりたいこと> lead がそれを PR 1 本ずつのチケットに分け、一覧の承認を求めます /crew:rules メモリと指示から rules.md を作ります。書く前に差分を見せます 引数なしの /crew:start は、何も始めません。人のリポジトリで勝手に動き出すのは行儀が悪いと考えたからです。「直すべきところを探して」と頼めば、scout が探して、重要度順の一覧を出します。 答えは ID で返せます。T3 OK、T3-Q1 は B、直前の一覧なら 全部 OK のように、どれからでも構いません。 やりとりの例 ! 以下は説明のために作った例です。 > /crew:start 同期まわりの不安定なテストを直したい lead: 3 件に分けました。 1. T1 同期のリトライが二重に走る [重要度 2, S]：オフラインから戻ったとき、同じ変更が 2 回送られる 2. T2 … 3. T3 … チケットにしないもの：実機でしか再現しない件（あなたの手が要ります） どれを進めますか？ > 全部 OK （しばらくして） lead: T1 のレビューをお願いします。PR #123 変わること：オフラインから戻ったときに、同じ変更が 2 回送られなくなります CI：server-test、ios-test が通っています 見てほしい点：リトライの上限を 3 回にしました 残り：T2-Q1（質問） > T1 OK lead: T1 をマージしました。続けて T2-Q1 です。… 制限と今後 v0.1 です。試したのは Claude Code だけです crew は lead のセッションの中で動きます。閉じると止まり、セッションを resume すれば続きから始まります worker は既定で 3 つまで同時に動きます。同じマシンでビルドやテストが重なるためです Codex などへの対応は、各役の手順に分けて書いてある「In Claude Code」の節を差し替える形で考えています 設計の理由は、リポジトリの docs/design.md にまとめてあります。 おわりに エージェントを何本並べても、最後に判断するのは人間です。並べる数を増やすより、人間の注意をどこに使うかを設計した方が、全体は速くなる。orchestrate を回して得たいちばんの学びはそれでした。 crew は、その学びを「配管」ではなく「判断の運び方」として形にしたものです。試してみて気づいたことがあれば、issue で教えてもらえるとうれしいです。

My AI agents were choking on their own markdown logs. I gave them a database. I am an AppSec engineer. For the past year I have been running AI agents as part of my security work: recon, attack surface mapping, hypothesis testing. It worked well until it did not. The problem Agents produce logs at every step: what they found, what they tried, what failed. All of that was landing in markdown files. After a few weeks on one project the folder looked like this: recon.md subdomains-live.md endpoints.md attempts-auth.md notes-session.md TODO.md TODO-v2.md progress-subagent-3.md I was using a model with a 256k token context window. That sounds like a lot. But at some point the accumulated logs for a single project stopped fitting in the window at all. The agent had to read the entire archive just to remember where it left off, and there was no room left to do actual work. It would hit the limit and restart, losing intermediate results and repeating attempts that had already failed. Specific symptoms: - Compaction erased progress. After context compression the agent would re-read progress.md, see "invoices module - almost done" and start over. What "almost" meant was anyone's guess. - Failed attempts repeated. Some hypotheses the agent tried three times, each time as if it were the first. - Subagents did not know about the lead agent's decisions. Scope constraints lived in the main agent's context. The subagent had no idea. - "What is left?" had no quick answer. You had to read every file and reconstruct the picture yourself. A markdown file is good as a document for a human to read. As a state store for a running agent it is not: no structure, no statuses that mean the same thing consistently, and you cannot query it. What was actually needed I wrote down the requirements: 1. Restore full context with the minimum number of tokens - at the start of a new session or when spawning a subagent. 2. "What is left?" must be one query, not a history read. 3. A failed attempt gets recorded and found before the agent repeats it. 4. A decision made at the top of the hierarchy reaches every subagent below without retelling the whole conversation. 5. Finished work collapses into a summary - the next session reads that, not a hundred notes. 6. Everything local, no external services. Project data stays on the machine. I did not find a tool that fit. So I built one: PentaCore, an MCP server in Rust. One binary, one encrypted SQLite file. It does not plan anything or decide what to do next. It stores what it is given and returns what is asked for. How it works PentaCore has two stores. Notes are the narrative: goals, steps, attempts and their outcomes, facts, decisions, questions, lessons. Notes form a tree through parent and a graph through typed links. Search works by exact words and, optionally, by meaning: the first recall downloads a small embedding model (all-MiniLM-L6-v2, English only, about 90 MB). Without it, search by words still works. Entities are many things of one kind: hosts, endpoints, files, whatever. Each entity has a status, attributes, and named checks. The split matters. "Show everything that has not passed check X yet" is a field filter. Its result should not depend on how the agent phrased a note. The pyramid: goals, steps, checklists Top level is the goal, steps under it, each step has a checklist: {"name": "note", "arguments": {"kind": "goal", "title": "Audit api.example.com"}} {"name": "note", "arguments": {"kind": "step", "title": "Module: invoices", "parent": 1}} {"name": "checklist", "arguments": {"note": 2, "add": [ "BOLA on read", "BOLA on update", "Mass assignment", "Role bypass" ]}} Each endpoint is an entity: {"name": "upsert_entity", "arguments": { "type": "endpoint", "key": "GET /v2/invoices/{id}", "status": "discovered", "attrs": {"module": "invoices", "auth": "user"} }} Checks are marked as they are done: {"name": "mark_check", "arguments": {"id": 41, "checks": [ {"name": "bola_read", "result": "fail", "detail": "user B reads invoices of user A"}, {"name": "role_bypass", "result": "pass"} ]}} Now "what has not been checked yet" is one call: {"name": "query_entities", "arguments": { "type": "endpoint", "where": [{"field": "check.bola_read", "op": "is_null"}] }} And the overall picture is another: {"name": "query_entities", "arguments": {"type": "endpoint", "group_by": "check.bola_read"}} Restoring context after compaction At the start of a new session, one call: {"name": "resume", "arguments": {"task": 1}} The agent gets what it needs to continue that task, not the whole archive. For a subtask this includes the notes handed down to it from above. The reply fits within a size budget (budget_chars), and budget.omitted says how much did not fit, so truncation is never silent. Subagents get only the context they need The lead agent creates a step for the subagent and links relevant decisions via uses: {"name": "note", "arguments": {"kind": "decision", "title": "/internal/* is out of scope"}} {"name": "link", "arguments": {"src": 1, "dst": 3, "kind": "uses"}} {"name": "note", "arguments": { "kind": "step", "title": "Zone: b.example.com", "parent": 1, "body": "Check TLS and auth on b.example.com." }} Here the decision is note 3 and the new step is note 4. A note that a task uses is context for that task and for every task beneath it, so a decision linked from the goal reaches subagents at any depth. The subagent is given only the step id. It calls resume task=4 and gets its assignment and the shared decision, plus any findings you linked to the step with uses. No need to retell the lead agent's whole conversation. Summaries instead of accumulated history When a step is done: {"name": "summarize", "arguments": { "task": 2, "work": "48 endpoints checked: BOLA, mass assignment, role bypass.", "result": "BOLA on GET /v2/invoices/{id}: user B reads invoices of user A. Mass assignment on PATCH via status field." }} task_summary returns the whole task as its summaries in tree order - one call, however many notes sit below. Any agent at any level of the hierarchy can get a focused summary of one area of the whole perimeter. Security Memory is a prompt injection channel. Everything written to it is later read as context. An unauthorized write becomes an injected instruction. What follows from that: - stdio only by default. The server can only be called by the process that launched it. - HTTP cannot be accidentally exposed. Loopback only, refuses to start without a token of at least 32 characters, requires an exact Host header to block DNS rebinding, rejects any request with an Origin header. - Input validated at the boundary. Every argument is parsed into a type with length and character set constraints. Unknown fields are rejected. - User text never becomes SQL. Bound parameters only. FTS5 operators are escaped. Entity queries are assembled from an allowlist of fields and operators. - Data at rest is encrypted. SQLCipher, secure_delete, WAL cleared after purge. Honest about limits: the SQLCipher key is compiled into the binary. It protects the file from someone who only has the file. It does not protect against someone who has the binary or the source. All known limits are listed in the README. When PentaCore is not the right tool - Task tracker with dependencies for software development: Beads or built-in Tasks in Claude Code. - One short task in a single session: the model context is enough. - Long-term memory about a user or their preferences: different problem, different tools. PentaCore is for when an agent works through a large number of similar targets over multiple sessions, survives compaction, and needs an exact answer to "what is done, what was found, what is left." Try it Binaries for Linux, macOS, and Windows are in Releases. SHA256SUMS, SBOM, and a build provenance attestation are included. Claude Code: claude mcp add pentacore -- /path/to/pentacore Any other MCP client: { "mcpServers": { "pentacore": { "command": "/path/to/pentacore", "env": { "PENTACORE_PROJECT": "my-project" } } } } The repo also has a Dockerfile and docker-compose.yml: read-only root filesystem, all capabilities dropped, unprivileged user. You build the image yourself; there is no published image yet. Repo: **DroBov1Tya/PentaCore** If you find a vulnerability, use Security -> Report a vulnerability in the repo rather than opening a public issue.

Beads: A memory upgrade for your coding agent (28k stars) What it does All text below is quoted directly from the project README. >Distributed graph issue tracker for AI agents, powered by Dolt. Features: - Dolt-Powered: Version-controlled SQL database with cell-level merge, native branching, and built-in sync via Dolt remotes. - Agent-Optimized: JSON output, dependency tracking, and auto-ready task detection. - Zero Conflict: Hash-based IDs (bd-a1b2) prevent merge collisions in multi-agent/multi-branch workflows. - Compaction: Semantic "memory decay" summarizes old closed tasks to save context window. - Messaging: Message issue type with threading (--thread), ephemeral lifecycle, and mail delegation. - Graph Links: relates-to, duplicates, supersedes, and replies-to for knowledge graphs. >Beads provides a persistent, structured memory for coding agents. It replaces messy markdown plans with a dependency-aware graph, allowing agents to handle long-horizon tasks without losing context. Repository gastownhall/beads Repository stats |Metric|Value| |:-|:-| |Stars|27,925| |Forks|1,892| |Last release|v1.3.1 (2026-09-30)| |Languages|Go 95%, Python 1.7%, Starlark 1.6%| |Contributors|486| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|Copilot: 60, cursoragent: 27, claude: 3306| |AI co-authored commits|Claude: 3978, Codex: 1, Cursor: 28, Copilot: 63| Main contributor |Field|Value| |:-|:-| |Name|Steve Yegge| |GitHub|@steveyegge| |Commits to this repo|4,808 (top contributor)| |Company / Location|Kirkland, WA| |Followers|3835| |Public repos|7| |On GitHub since|2011-02-12| ------------------------------------------------------------------------------------------------- Discover the best GitHub repos without the endless scrolling. Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter. 👉 Get the best repos & community insights - Free