Codebase to Spec
Alpha feature. Output quality varies by codebase and we’re actively iterating on prompts. Try it, and please send what you learn to support@dotrequirements.io.
When code exists but its spec doesn’t, codebase-to-spec reads the code and writes one for you. It’s useful before you refactor a legacy system, while onboarding to an unfamiliar codebase, or any time you want a readable account of what the code does without having to piece it together file by file.
It’s not the right tool for new-feature design. For that, collaborate with AI on requirements first and let them drive implementation.
Install it
codebase-to-spec runs as a Claude Code skill backed by a dynamic workflow, so you’ll need a Claude Code version with dynamic-workflow support. Install it with the dotrequirements CLI:
npx -y @popoverai/dotrequirements cts skill-install # into this project
npx -y @popoverai/dotrequirements cts skill-install --global # …or every project (~/.claude/)That drops the skill, its worker agent, and the workflow into .claude/. (Already set up with dotrequirements? Just dotreq cts skill-install.)
Use it
In Claude Code, run /codebase-to-spec — or just ask, e.g. “spec the auth module.” Then:
- You confirm the scope — a path like
src/auth, or the whole thing. - The workflow runs on its own in the background (watch it in
/workflows): it plans a behavioral-area outline, has an independent reviewer sign off on that decomposition, drafts the requirements for each area in parallel and converges each one through review, then assembles them into a single spec and runs a final cross-area review pass that removes duplication and reconciles terminology and personas across areas. - You review the result — the requirements land in
.requirements/*.requirements.md, with a summary that flags any areas worth a closer look.
You weigh in at the start (scope) and the end (review); everything between is autonomous — no step-by-step babysitting.
Scope it
Point it at a coherent slice — a package, module, or directory — rather than a whole monorepo. There’s a working-context budget: if the compressed view of your scope is too large for a single planning pass, the skill tells you and asks you to narrow it. Large codebases are best done a package at a time.
Feedback
Output quality, prompt sensitivity, and any rough edges — we want to hear about all of it. Email support@dotrequirements.io with a short description of the codebase and what the run produced (or failed to produce). Real examples drive the next round of prompt iteration.