Spec-Driven Development With Claude, Codex, and the Superpowers Plugin

The prompt scrolls away, the spec stays

I still prompt agents directly. That is the interface. But when the work has more than one step, the prompt should not be the only place where the decision lives. It disappears into chat history, blends with exploration, and becomes hard to review after the diff exists.

The spec is the commitment layer. It names the problem, the boundary, the files likely to move, the checks that will prove the change, and the things the agent must not do. The agent can help draft it. The human has to approve it.

Where Claude, Codex, and Superpowers fit

Claude Code and Codex now overlap in the shape of work they can do: read a codebase, edit files, run commands, and carry project memory. Claude Code documents CLAUDE.md memory, skills, hooks, and sub-agents. Codex documents AGENTS.md, skills, and subagents. The overlap is useful. It means the process can be tool-shaped without being tool-owned.

Superpowers sits above that as workflow discipline. I treat it as a way to force named steps into the work: brainstorm the shape, write the plan, execute against the plan, run tests, request review, and verify before completion. The value shows up because the obvious gates stay visible at the exact moment they are easy to skip.

The spec carries the decisions

A useful spec is not long by default. It is precise enough that a second agent, or the same agent in a fresh session, can implement without rediscovering the decision from scratch.

What the spec buys you

The spec looks like overhead, but it is what makes the work portable. When the credits run out mid-task, or you switch from one agent to another, the next session does not start from zero. It reads the spec and picks up the decision instead of re-deriving it from a chat log it never saw.

The same portability shows up in smaller ways every day. A wrong decision is caught in a fifteen-line spec instead of a six-hundred-line diff. An interruption, a context limit, or a crash does not erase the plan. A teammate can implement from the spec without your conversation, and steps the spec marks as independent can run in parallel across sessions or subagents.

The agent gets a plan, not a wish

My preferred loop is simple: write the spec, inspect the repo, turn the spec into a small plan, run the implementation, then review the result against the spec instead of against the assistant's confidence.

For Angular work, that means the plan names the actual boundary: component state, RxJS stream, provider scope, route behavior, hydration edge, test runner, or MCP setup. A plan that only says 'modernize the component' is still a wish, not an instruction: it leaves the agent to guess the rest.

Verification beats confidence

I do not accept 'done' from an agent without evidence. For code, that usually means tests, build, lint, content validation, screenshots, or a specific command output. For writing, it means the voice filters, source checks, and banlist scans. Different work, same rule.

At review time, I look for the concrete result: the repo contains the behavior the spec asked for, evidence is attached, and the change did not damage the surrounding code.