I write most of my code with Claude Code these days. For a long time my workflow was built on obra/superpowers, a plugin of skills that steers the agent through brainstorming, planning and test-driven development. It changed how I work, and it's still a great place to start.
After a few months I had a list of things I wanted to work differently. That list became pasadena, a Claude Code plugin for spec-driven development. This post explains what it does and why.
The problem: context that lives nowhere
A spec says what you intend to build. Git history says what you merged. Neither says where the work stopped, what you already verified, or which file to open next. With agents it gets worse: every new session starts cold, and you spend the first ten minutes explaining everything again.
Pasadena keeps that context in a journal file on the task branch, .pasadena/journal/<branch>.md. It has three sections: the goal; what's happening now (current phase, blocker, the next concrete step with a verification command); and an append-only timeline. Hooks restore the journal at session start, log new commits, and mark pauses and failures. Before merge, the useful summary moves into the PR description and the file is deleted.
Built for worktrees
Pasadena is designed around git worktrees: one task, one branch, one worktree. For architectural work, sheldon creates the worktree, the journal and a draft PR right away, so several tasks can run side by side without stepping on each other, and each one keeps its own journal on its own branch.
The workflow
/pasadena picks up from whatever stage the branch is at. Under the hood it hands off to one of nine skills:
| Skill | Job |
|---|---|
| sheldon | Asks focused questions and writes an agreed spec |
| penny | Builds 2–4 browser prototypes for a UI decision |
| leonard | Splits the spec into tasks and parallel waves in plan mode |
| wolowitz | Runs the waves, verifies and commits each task, reports on the PR |
| amy | Failing tests first; proof from a fresh run before "done" |
| leslie | Root cause in four phases before any fix |
| bernie | End-to-end check in the browser, or a lasting Playwright test |
| stuart | Screenshots at several widths and a report of layout defects |
| raj | Starts, resumes, hands off and closes the journal |
What I changed compared to superpowers
1. Plan mode for the plan. Once the spec is agreed, leonard writes the plan inside Claude Code's native plan mode. I review and approve it like any other plan, and nothing runs before that.
2. Codex as a helper, not a replacement. If the Codex CLI is installed and logged in, skills delegate three kinds of work to codex exec: bulk code lookups that come back as facts with file:line; an extra review of the whole branch; and plan tasks explicitly marked for Codex. Claude stays the orchestrator and only counts findings it has confirmed itself. The main motivation is saving Claude usage on routine work.
3. Spec-driven and test-driven in one pipeline. The spec sets the acceptance criteria. amy turns them into failing tests before any production code, then takes each step through its own failing test. Nothing counts as done without a fresh test run.
4. Parallel subagents without collisions. Every task in the plan declares the files it touches. leonard groups tasks whose file sets don't overlap into waves. wolowitz runs each wave in parallel, with a separate test writer and implementer per task, verifies it, commits every task, and reviews every third wave plus the whole branch at the end.
5. Work happens in the open, on a draft PR. The draft PR is opened at the start and carries the spec. While the work goes on, progress is commented on the PR as commits land, so the PR itself shows what was built, in what order and how it was verified, long before it's ready for review.
Trying it
/plugin marketplace add dmytro-rudenko/pasadena /plugin install pasadena@pasadena Requirements: bash, git, jq, and Node.js for browser prototypes.
The plugin works on its own, but it works best together with the Codex CLI and microsoft/TokenEconomizer: Codex takes over part of the work, and TokenEconomizer helps spend fewer tokens.
Wrapping up
I use pasadena every day, and it covers everything I need in development. It keeps evolving. But that's one person's view, so I'm genuinely curious how it works for others. Any feedback is welcome, here in the comments or in issues on GitHub.
