AI coding assistants are amazing—until you point them at a legacy codebase.
"What does this module do?"
"I don't have enough context."
Sound familiar?
The Problem
Claude Code (and similar tools) hit context limits fast on existing projects. No documentation means no context, which means the AI can't help effectively.
You could spend weeks writing docs manually. Or you could automate it.
The Fix: Generate Docs First
Instead of fighting the AI, I ended up building a workflow that:
- Scans your codebase for features
- Generates PRD + Design Docs automatically
- Verifies docs against actual code
- Now AI has context to work with
Quick Start
# Start Claude Code
claude
# Add the marketplace
/plugin marketplace add shinpr/claude-code-workflows
# Install the plugin
/plugin install dev-workflows@claude-code-workflows
Then point it at your legacy code:
/reverse-engineer "src/auth"
That's it.
What Happens
The workflow runs through multiple specialized agents:
- scope-discoverer finds what features exist in your code
- prd-creator generates product docs for each feature
- code-verifier checks if the docs match reality
- document-reviewer catches inconsistencies
Each step verifies against the actual code—so you get docs that reflect what the system actually does, not what someone thought it did years ago.
What You Get
- PRD for each feature (what it does, why it exists)
- Design docs (how it's built, what depends on what)
Now when you ask the AI to modify something, it has context.
Before/After
Before: "Explain the auth module" → Context limit, vague answers
After: AI reads generated docs → Specific, actionable suggestions
When to Use This
Works best when:
- You've inherited a codebase with missing docs
- Institutional knowledge has left with previous developers
- You want to onboard AI assistants to existing projects
It's not magic—complex legacy systems still need human review. But it gets you 80% there automatically.
I built this while trying to make Claude Code usable on projects where no one knows how things work anymore.
shinpr
/
claude-code-workflows
Production-ready development workflows for Claude Code, powered by specialized AI agents.
Claude Code Workflows 🚀
End-to-end development workflows for Claude Code - Specialized agents handle requirements, design, implementation, and quality checks so you get reviewable code, not just generated code.
⚡ Quick Start
This marketplace includes the following plugins:
Core plugins:
- dev-workflows - Backend and general-purpose development
- dev-workflows-frontend - React/TypeScript specialized workflows
Optional add-ons (enhance core plugins):
- claude-code-discover - Turns feature ideas into evidence-backed PRDs
- metronome - Detects shortcut-taking behavior and nudges Claude to proceed step by step
- dev-workflows-governance - Enforces TIDY stage and human signoff checkpoint before deployment
Skills only (for users with existing workflows):
- dev-skills - Coding best practices, testing principles, and design guidelines — no workflow recipes
These plugins provide end-to-end workflows for AI-assisted development. Choose what fits your project:
Backend or General Development
# 1. Start Claude Code
claude
# 2. Install the marketplace
/plugin marketplace add shinpr/claude-code-workflows
# 3. Install backend plugin
/plugin install dev-workflows@claude-code-workflows
#…
Top comments (4)
The "80% there automatically, still needs human review" framing is the right way to think about this — I've noticed the same thing building in this space: docs-as-context solves the understanding problem, but it doesn't automatically solve the trust problem once the AI starts acting on that context.
Full disclosure, I build DevFlux.pro, a lighter-weight take on a similar idea — instead of generating PRD/design docs upfront, our workflows stop and ask for context first, then require explicit approval on a proposed change before anything gets implemented, then verify the diff against what was actually approved. Different shape (one file per task vs. a full agent pipeline), but I think we landed on the same underlying belief: an AI that explains itself and waits for a yes/no is fundamentally more trustworthy than one that just goes and does it, docs or no docs.
Curious whether you've found cases where even with generated PRDs/design docs in place, you still want an explicit human checkpoint before implementation — or whether good-enough docs make that less necessary in practice?
Yes. I still want an explicit checkpoint before implementation.
The docs in this post are mainly descriptive: they tell the agent what already exists. They don't decide what the next change should deliver, what we're not going to build, or whether the proposed change is bigger than it needs to be. Those are the things I want to confirm before implementation starts.
Good docs do make that checkpoint narrower. Once the agent understands the current system and has clear constraints and verification criteria, it can handle most implementation decisions without coming back to me. For me, the workflow is about making that boundary clear: what the agent can decide for itself, and what should come back to me.
So yes, the checkpoint remains, but good docs reduce what needs to come back to me. I want the agent to ask for a yes/no when it reaches a decision I haven't delegated, not before every implementation decision.
That's a sharp way to name it, and it matches what the proposal step is actually for, not a gap in it: the proposal — root cause, exact lines, what's explicitly out of scope — is the undelegated decision that needs your yes/no. Everything downstream of that (implementation, matching code style, updating tests) the workflow already lets run without another check-in. So the shape you're describing — checkpoint narrows to the judgment call, not a gate on every step — is the design, not something I'm discovering mid-conversation.
Where I'd actually push back a little: I don't think doc quality is what narrows that boundary. Even with excellent docs, "is this fix minimal enough" or "is this actually the root cause" isn't answerable from documentation — it's a judgment call in the moment. That's why the checkpoint stays fixed regardless of how good the surrounding docs get, rather than assuming it eventually becomes optional.
Do you find good-enough docs actually make you willing to delegate that judgment call too, or does it stay a hard line for you regardless of doc quality?
I’d put the line in a slightly different place. Root cause and minimality are judgment calls, but I don’t think a human always has to make them.
When I say good docs, I don’t mean documents that are correct enough to follow literally. I mean they carry the current thinking: the outcome we’re after, what we’ve decided not to build, and why the important design choices were made. That gives implementation and review something fixed to compare against when asking whether a change is still minimal.
The document is a working reference, and it can be wrong. That’s become more important as models have improved, because they can implement a bad design very thoroughly. In my workflow, if implementation shows that part of the design was wrong but the agreed outcome and scope still hold, the design gets updated and the affected checks run again.
I’m willing to delegate more of that judgment when the agent has enough context and the workflow can revisit earlier technical decisions as new evidence appears. Inside the agreed product boundary, the agent can own reversible technical decisions. If new evidence would change the outcome, requirements, or non-goals, that decision comes back to me.
The human checkpoint isn’t fixed for me; the product boundary is. I don’t treat the design as final until the PR is approved.