For the past few months, I’ve been using Claude Code to plan and build features. The pattern was always the same — figure out the problem, dig through the codebase, design something, break it into tasks. Every time I’d forget to check something or miss an edge case. So I extracted the process into three skills that I can chain together: /write-prd → /prd-to-rfc → /feature-decomposition What each one does: /write-prd — You describe the problem. Claude interviews you about it, explores your codebase to understand the current state, and writes a structured PRD. It covers user stories, implementation decisions, edge cases, and scope boundaries. The interview part is the most useful — it forces you to think through things you’d normally hand-wave past. /prd-to-rfc — Takes the PRD and turns it into a technical RFC. This is where it gets interesting. It does 4 exploration passes over your codebase: Verifies every claim the PRD makes about existing code (fields, functions, data flows) Maps the blast radius — who consumes the data you’re changing? Checks project docs for prior decisions and known pitfalls Finds reusable patterns you didn’t know existed Then it stops and shows you what it found before writing anything. Key discoveries, assumptions it’s making, and questions that would change the approach. It won’t continue until you say “go.” This is the part that’s saved me the most time — it caught wrong assumptions I would’ve built an entire design around. The questions it surfaces are the ones you’d rather not think about — “What if two requests fire concurrently for the same resource?”, “What happens when the LLM returns garbage, and there’s no fallback?”, “What if the user is mid-workflow and their session expires?” /feature-decomposition — Takes the RFC (or a PRD directly if the approach is obvious) and breaks it into small, independently shippable feature specs. Each spec includes: Exact files to create/modify Acceptance criteria Dependencies on other features Traces back to source requirements (US-1, ID-3, EC-2, etc.) At the end, it builds a coverage matrix — every user story, every implementation decision, every edge case from the source doc gets mapped to a feature. If something isn’t covered, it flags it. This has literally caught features I would have forgotten. In one decomposition, it found 2 missing features that were in the source doc but absent from my feature list. You don’t need all three. I use /feature-decomposition on its own all the time when I already have a spec and just need to break it into work. /write-prd is useful standalone for thinking through a feature before writing any code. The RFC step is for when multiple approaches are viable, and you want to document why you chose one — skip it for straightforward features. Installation: Copy a skill folder into .claude/skills/ in your project. They’re not tied to any specific stack or framework. github.com/yerzhansa/skills Happy to answer questions about how they work. If you try them and something feels off — wrong assumptions, missing steps, better ways to structure the output — I want to hear it. Comments, issues and PRs welcome. submitted by /u/Budget-Baker-9063
Originally posted by u/Budget-Baker-9063 on r/ClaudeCode