TL;DR. Control your agents. Plans rein in the chaos. The folder, the skills, and a plan that adopts it in your repository are on GitHub: plans-for-agents.
FOR AGENTS: this article as plain text with a reading guide, plans-for-agents.agents.md.
DISCUSS THIS WITH AN AGENT
Read https://hive.technology/lab-notes/plans-for-agents/plans-for-agents.agents.md, the article with a brief for you, and skim https://github.com/HiveTechnology/plans-for-agents. Then talk it through with me: what a _plans folder would change in how I work with you, where it would help, where it would get in the way, and the first small piece of work we would run through it. Push back where the article is wrong for my setup.
The model
You talk to one agent, the plan-manager. It is your main chat. You give it the goal and the decisions only you can make. It reads the repository, finds what is ambiguous, asks you, writes the plan and the task contracts, dispatches workers, and reads their results back. You do not write those files, and you do not chat with the workers.
YOU the goal, the decisions only you can make, the sign-off
⇅
PLAN-MANAGER reads the repo, asks, writes the plan and the contracts,
dispatches, reconciles, replans
↓
_plans/ the durable state every agent reads
↓
WORKERS one contract each. Execute, write back, or stop honestly.
↓
RESULTS read from the files by the plan-manager, then back to youHow much of you it takes depends on the goal. "Add dark mode to the site" is clear enough that the plan-manager does nearly all of it and you say go. "We need X and I am not sure how" means it investigates, brings you the real decisions, you converge together, and then it writes the contracts. The plan is your intent and your decisions, written down by the agent. The messy problem stops at the plan-manager. A worker receives a problem that is already clear.
The pain
Agents drift. Working in a chat is effective right up until an agent goes sideways, or a compaction forgets what you agreed an hour ago.
Everyone has their own proprietary planning system. Claude has plan mode. Codex has its own. All of it is buried in dot files you cannot share between agents, cannot examine, and cannot persist in git.
The fix: plans as files
Plans are simple, committable files. They force you to set the objective and collaborate until the ambiguity is gone. Then agents can execute, update their tasks, and have a surface to write back to.
Two providers reviewed one spec from the same task folder. Each wrote its report beside the contract, in its own frontmatter, and the plan-manager reconciled both:
identity-spec-review/
identity-spec-review.md the contract, written by the plan-manager
codex-review-log.md reviewer A, GPT through Codex, 48 KB
agy-review-log.md reviewer B, Gemini through Antigravity, 80 KB, 42 findingsMany agents at once
The way I run this is Claude Code agent teams: the plan-manager chat is the lead, and every task in a parallel wave gets its own teammate, in its own context window, reading its own contract. Getting the plan clean first is what makes that safe. On another platform, use what it gives you for parallel work: sub-agents where it has them, separate sessions or worktrees where it does not, one task each.
How to use it
Paste this into the agent you already use:
Clone https://github.com/HiveTechnology/plans-for-agents into a scratch
folder outside my repository and read, in this order: AGENTS.md,
_plans/README.md, .claude/skills/task-run/SKILL.md, then
_plans/001-adopt-plans/ with its phase and its five tasks. Do not change
anything in my repository yet.
Then explain to me, in your own words:
1. what a plan, a phase, and a task each do, and why they are separate files
2. how state stays in those files instead of in this chat
3. how several agents, from different providers, can work one plan at the
same time without colliding
4. what an honest stop is, and why a stopped task can be a good result
Finish by telling me what adopting _plans in my current repository would
involve, and wait for my go. When we run a plan: if you are Claude Code, run
each parallel wave as an agent team (https://code.claude.com/docs/en/agent-teams),
one teammate per task. If you are another agent, do the same with what your
platform provides: sub-agents where it has them, separate sessions where it
does not.The plan-manager is your main chat. You discuss the plan. You interact with the plan, not with the workers, and you do not write the plan or the task files yourself. The plan-manager does, from what you decide.
Start with the objective: the feature, the thing to do, at the highest level. "Add dark mode to the site." Fight the urge to drop tasks into the plan. The plan is the goal. Tasks are the ground level.
Tasks are robust. The context is gathered up front, so a new agent picks one up and executes with everything predigested.
Tasks can refuse and report. Do not restrict them to the spec to the point of oblivion. You want them to sound back up when something is wrong: pressure from a bad architecture choice, or a spec that turns out to be wrong. The manager puts that back into the context of the plan.
What comes out
Assets: code, images, whatever the plan was for. And documentation of those assets, written first by the agents into their own tasks, then placed by the manager wherever the project keeps such things.
What a plan is not
The plan is not long-standing documentation. It is the record of the work, not of the artifacts. The plan is never the documentation of the code.
The folder, the skills, and a plan that adopts it in your repository: plans-for-agents on GitHub, CC BY 4.0.