Agent coding workflows make AI code development repeatable and reviewable: the same stages, the same files left behind, the same points where a person signs off. Teams should pick one now instead of waiting for Claude Code and Codex to build the workflow in.
We tested two popular frameworks (Superpowers and Agent-Skills) by building the same 311 municipal government application. Superpowers finished in 49 minutes for $4.76. Agent Skills took about 90 minutes and cost $6.30, we then used the frameworks to add additional features to the app.
What a coding agent workflow is
A workflow helps organize a loop. The frameworks below differ in style, but most follow the same stages:
A skill is one instruction file (SKILL.md) that teaches the agent a step. A framework is a pack of skills that adds up to a workflow. Claude Code and Codex read the same open skills format. Commit a project’s skills folder (.claude/skills for Claude Code, .agents/skills for Codex) and every developer’s agent gets the same playbook (Claude Code, Codex). Skills are cheap to keep around: the agent sees only each skill’s name and description until it needs one, then loads the full instructions.
Scaffolding your project
While you can get away with creating a claude.md file, scaffolding, and starting in plan mode, without using a framework, a framework adds repeatability and standards that the team needs.
Superpowers installs a hook that reloads its rules every time a session starts, is cleared or is compacted, because it is built to run unattended (Superpowers). Agent Skills ships a similar script but leaves it off in Claude Code and Codex, so it doesn’t stack a second router on top of the tool’s own. It relies on its files and your commands (Agent Skills). Pocock’s Skills sizes each ticket for one fresh context window and has a handoff skill that writes a note for the next agent (to-tickets). Osmani concedes that none of the three has solved memory across sessions (comparison). Clear a session only between tasks, after the last one is committed.
The three frameworks
All three are frameworks are free, MIT-licensed, and document installs for both Claude Code and Codex. Superpowers calls its skills “Mandatory workflows, not suggestions,” and they trigger on their own. Pocock rejects frameworks that “own the process,” arguing they take control away from the developer. That is a fair hit on Superpowers and much less so on Agent Skills, where you start each phase yourself.
Don’t run two at once. Osmani’s comparison warns they fight over command names and testing styles, and recommends one framework plus borrowed single skills (comparison).
The coding workflows in practice
We used Superpowers and Agent Skills to build a 311-style pothole tracker for a fictional city: residents report, staff move reports from new to assigned to fixed. Same opening prompt, same model (Sonnet 5.5), same written answers, pinned framework versions, one run each.
Four lessons beyond the table.
The framework picks your model. The session ran on Sonnet 5.5, but Superpowers sent its final code review to Fable 5.1. That is by design: its rules call for “the most capable available model, not the session default” (Superpowers). That one review cost $2.78 of the $4.76, more than all the building.
Checkpoints are the management feature. Superpowers asked its questions up front, then built for 26 minutes without stopping. Agent Skills ran its first three tasks one at a time, stopping after each, then switched to its automatic mode, which still stopped for a sign-off before the login code (Agent Skills). For a team, the stops are where a lead reviews the work.
Suggested answers are a trap. Agent Skills opened with multiple-choice questions, each with a recommended answer. Its picks (TypeScript and Next.js, email on every status change) didn’t match the written requirements (Python and Flask, no email), and accepting them cost rounds of spec corrections. Superpowers asked open questions, one per message. Write your requirements on one page before the session, and answer from that page.
One outside single-run test, on an older model, found both took about 22 minutes, but Agent Skills started coding sooner (8 minutes against 12) and its extra validation caught a compatibility problem outside the feature (Om Mishra).
The verdict: Superpowers is the better autopilot. Agent Skills is easier to manage, and management is the point for a team.
Adding new features
Most work on a real system is adding to something that already exists, and here the frameworks’ instructions differ most. Superpowers reruns its whole design-and-plan loop for each new feature and files a new dated plan, so you end up with a folder of plans and no single description of the app (Superpowers). Agent Skills updates the spec first, then adds tasks to its running task list and won’t overwrite unfinished work (Agent Skills). Pocock’s Skills triages incoming requests and cuts them into tickets. Only Agent Skills was tested on day two.
The request: add a “Download open requests as CSV” button for public works staff to the finished app, which had no CLAUDE.md.
Define. Asked to spec the feature, the agent declined to overwrite the approved
SPEC.mdand asked what to change. It then revised the spec and added a new phase to the existing task list, leaving the ten finished tasks alone.The suggested answers came back. Its questions again carried recommended answers, three and then four. The operator declined both rounds and pasted written requirements instead, which asked for “the whole open list.” The agent still assumed each staff member should get only their own district’s requests, asked about it, and kept that scope when told to use its judgment.
Build. It added something nobody asked for, and labeled it. Text typed by residents that starts with
=,+,-or@gets an apostrophe in front, so Excel can’t run it as a formula. The security review later noted the side effect: legitimate text starting with-or+shows a stray apostrophe.Ship. Three reviewers ran in parallel: code, security and testing. None found anything critical. The test engineer broke the new code on purpose 19 ways, and three of those breakages slipped past the tests, including dropping the tie-break on equal timestamps. The verdict was go for prototype use, not public deployment, with eight recommended fixes, none required.
The change added 26 tests, and the full suite of 522 passed when re-run afterward. A downloaded file was opened in Excel and passed the operator’s check. The run took about 33 minutes and cost $2.13. That isn’t comparable to the first build, since it was one feature on an existing app.
The living spec, task list and review stage all worked. The scope drift is the warning: the requirements said one thing, the agent decided another, and only a person reading the spec would catch it.
The future of coding workflows
It is inevitable that the functionality of these workflows will be baked into models in the near future, and they will become a setting or a built-in skill. Using a model today, gets you to AI coding standardization quickly, and will enable the team to switch quickly once this functionality becomes standard.
Do it yourself
Install one framework in one repo. For Agent Skills in Claude Code:
/plugin marketplace add addyosmani/agent-skills, then/plugin install agent-skills@addy-agent-skills. For Superpowers:/plugin install superpowers@claude-plugins-official. In Codex, Agent Skills’ slash commands aren’t available, so call the skill by name, for example@spec-driven-development.Write the requirements page before the session (the companion has a template), and answer the agent from it, not from its suggestions.
Define and plan. Run
/spec, then/plan, and read both files before any code is written.Build. Run
/buildone task at a time for the first few tasks. Once the plan holds up,/build autoruns the rest after one approval, still testing and committing each task and pausing on failures or risky steps. Use/agent-skills:review, since/reviewcollides with a built-in Claude Code command.Check the bill. Look at which models the framework calls, and set a budget before the first run.
Ship, then write the memory file. Run
/shipand note whether the verdict says prototype or production. The day the first version works, add a shortCLAUDE.md: how to run it, how to test it, where the spec lives, what not to touch. None of the three frameworks writes one.On day two, start with the spec. Run each new feature through
/specand/planas backlog items, one task at a time, so a lead can review each one.
The day-two run is the most useful part of this. The district scope is the moment I'd underline: the written requirements said "the whole open list", the agent asked anyway, and "use your judgment" handed the decision straight back to it. That is a scope change made by default with a question attached. The CSV button and the new permission boundary also got the same process, which is the cost of a fixed set of skills: it can't tell a small change from a scope change. We built Halfcycle to size the questions to the change and keep each answer on record for the next feature. If you run day two again, try npx halfcycle on the same CSV request and see what it asks. Did anyone notice the scope narrowing before testing?
Suggested answers being a trap is the finding I'd pass on to teams: a recommended default in a multiple-choice question gets accepted like a cookie banner. Answering from a one-page spec written before the session fixes that, and it gives the reviewer at each checkpoint something to check against.