DEV Community

codingKrills
codingKrills

Posted on

Vibe Coding with claude code

#ai #productivity #coding #claude

PRD to PRODUCTION

Working from a Notion PRD is a great source of truth — the key is not dumping the whole PRD into one prompt and asking Claude to "build it." That tends to produce shallow, half-matching code. Better to break it into stages that mirror how a good engineer would actually work through it.

Here's the step-by-step workflow:

Step 1: Ingest & clarify (don't skip this) 

Here's the PRD for a new feature: [paste PRD content or Notion link/export]

Before writing any code:
1. Summarize the feature in your own words — what problem it solves, who it's for
2. List all functional requirements as a checklist
3. List all non-functional requirements (performance, security, tenant isolation, etc.)
4. Identify ambiguities, missing edge cases, or things the PRD doesn't specify
5. Ask me clarifying questions on anything that would change the implementation approach

Do not propose an implementation yet — just confirm understanding first.
Enter fullscreen mode Exit fullscreen mode

This step alone catches most misunderstandings before they become wasted code. If the PRD has gaps, Claude will surface them instead of guessing.

Step 2: Plan the implementation 

Based on the confirmed requirements, propose an implementation plan:
1. Which existing modules/files/services this touches (search the codebase, don't assume)
2. New files/modules needed
3. Database schema changes (tables, columns, migrations, RLS policy updates if tenant-scoped)
4. API contract (new/modified endpoints, request/response DTOs)
5. Frontend components affected (if applicable) and state management approach
6. Third-party/internal dependencies needed
7. Suggested order of implementation (backend first, then frontend, or parallel)
8. Risks or breaking changes

Present this as a plan for my approval before writing code.
Enter fullscreen mode Exit fullscreen mode

This is the point where you catch architectural mismatches — cheap to fix here, expensive after code exists.

Step 3: Implement in slices, not all at once 

Implement step [1] from the approved plan only: [specific slice, e.g. "the database migration and entity/DTO layer"].

Follow existing conventions in the codebase (check similar existing modules for patterns).
After this slice, stop and summarize what was done before moving to the next step.
Enter fullscreen mode Exit fullscreen mode

Repeat this per slice (migration → service layer → controller → tests → frontend). Reviewing incrementally is much easier than reviewing a 2000-line diff at the end.

Step 4: Self-review against the PRD 

Review the implementation against the original PRD requirements checklist from Step 1.
For each requirement, confirm: implemented / partially implemented / not implemented, with file references.
Flag anything implemented differently than specified, and why.
Enter fullscreen mode Exit fullscreen mode

This closes the loop — makes sure nothing from the PRD got silently dropped.

Step 5: Tests 

Write tests for this feature:
- Unit tests for service/business logic
- e2e tests for new endpoints
- Cover edge cases identified in Step 1
- If tenant-scoped, add a test verifying RLS/tenant isolation
Enter fullscreen mode Exit fullscreen mode

Step 6: Docs + PR (using what you already set up) 

Now generate the documentation for docs/ folder per our documentation policy, and prepare the PR (branch name, title, description, checklist) per our PR policy.
Enter fullscreen mode Exit fullscreen mode

Make this a slash command too

Since this is a recurring workflow, worth saving as .claude/commands/feature.md:

Given a PRD (pasted or linked), follow this process:
1. Summarize requirements + list ambiguities, ask clarifying questions — do not code yet
2. Propose implementation plan (files, schema, API contract, risks) — wait for approval
3. Implement in reviewable slices, stopping after each for confirmation
4. Self-review implementation against the PRD checklist
5. Write tests
6. Generate docs/ and PR per project policy
Enter fullscreen mode Exit fullscreen mode

Then it's just /feature + paste the PRD.

One practical note on the Notion piece: if you paste a Notion export/link, Claude reads it as text — but Notion docs sometimes have nested toggles, linked databases, or embedded tables that don't flatten cleanly. Worth a quick skim of Step 1's summary to make sure nothing got dropped in translation.

Want me to draft the actual .claude/commands/feature.md file fully fleshed out so you can drop it straight into a project?

Top comments (3)

Collapse
 
web_equipe_6ce39cc961f26b profile image
Webequipe •

Nice workflow. I like the “don’t dump the whole PRD and ask it to build” point — that is where AI coding can easily go wrong.

We follow a similar approach while building and releasing our WordPress Webequipe PDF Search plugin. AI helps us move faster, but we still break work into clear requirements, reviewable development parts, staging QA, Free/Pro compatibility checks, changelog preparation, and release monitoring.

For plugin development, vibe coding is useful only when the release process is disciplined. The code can be AI-assisted, but the responsibility for quality, security, and user trust still stays with the team.

Collapse
 
synfinity-dynamics-pvt-ltd profile image
Synfinity Dynamics Pvt Ltd •

This is a great workflow. Breaking the process into understanding → planning → implementation → review → testing mirrors how experienced engineering teams actually ship reliable features. Thanks for sharing!

Collapse
 
synfinity-dynamics-pvt-ltd profile image
Synfinity Dynamics Pvt Ltd •

Excellent workflow! Breaking feature development into clear stages makes AI-generated code much more reliable and maintainable. Thanks for sharing!