How I built a skill to cut PRD writing from 8 hours to 2
At Insurfact, we needed to rebuild a series of data management pages. These are backend maintenance screens, the kind where admins can add, edit, and delete records from a table. Every page follows the same structure. A list with filters and pagination, a form to add or edit, a delete confirmation, validation rules.
The first one took me seven to eight hours to write a PRD for.
Not because the page was complicated. Because writing a thorough PRD from scratch is slow. You have to think through every field, every edge case, every validation rule, every state. It is easy to miss things, and the things you miss always come back as bugs or back-and-forth with engineering later.
After finishing that first one, I knew I was going to write five or six more pages just like it. So I built a skill instead of repeating the process.
What a skill actually is
In Claude Code, a skill is a markdown file that gives Claude a specific role and a specific workflow to follow. When you invoke it, Claude stops being a general assistant and becomes whatever the skill defines.
Mine defines Claude as a PRD guide for backend maintenance pages. It knows what these pages look like, what they almost always need, and what tends to get skipped. When I start a session with it, it does not wait for me to dump information. It asks.
Five rounds of questions
The skill works in five batches. Each batch waits for my answers before moving to the next.
First batch covers the basics. Page name, entry path, what the page manages, and what the overall layout is.
Second batch covers data. The main table, which fields are system-generated, any lookup tables for dropdowns, any related tables used for counts or delete protection.
Third batch covers fields in detail. What shows in the list, what shows in the form, which fields are required, which autofill, and whether add mode and edit mode behave differently.
Fourth batch covers list behavior. Default sort order, how sorting changes when filters change, whether users can click column headers to re-sort, how search works, and when pagination should reset.
Fifth batch covers validation and edge cases. Delete confirmation text, uniqueness rules, field length limits, format constraints, and anything still pending from the backend team.
By the end of five rounds, Claude has everything it needs. It runs through an internal checklist, then writes the full PRD.
Here is one of the questions from the fourth batch, on list behavior:
Does the page have any filters? If so, does the sort order change depending on which filter is active? For example: Active=Y sorts by Start Date DESC, Active=N sorts by End Date ASC.
That question would never make it into a casual briefing. It is too specific. But it is exactly the kind of thing engineers ask about three weeks later when they are building the table.
A different part of the skill handles what happens after the five rounds are done. Before writing anything, Claude runs through an internal checklist. Part of it looks like this:
Does the overview include the entry path?
Are there fields that behave differently in Add mode versus Edit mode? Has that been stated clearly?
If there are multiple filters, has the sort rule for each filter state been specified? Not just the default, every state.
Are there cross-field validation rules? If A is set to a certain value, does B become required?
The checklist exists because I kept missing the same things across different pages. Writing it down once means I stop discovering those gaps during QA.
Then the output follows a fixed template. Every PRD starts with an overview, covers data sources and SQL mapping, defines every field in a table with columns for required, input type, autofill rules, and Add versus Edit differences, then closes with validation rules, a test checklist, and a section for anything still pending from the backend team.
The template is not generic. It was built from the first PRD I wrote manually, the one that took eight hours. Everything I rewrote the same way across pages is now baked in.
Then the prototype
Once the PRD is done, I hand it back to Claude and ask for an HTML prototype. Because the PRD already defines every field, every state, every interaction rule, Claude is not guessing. It is just building what was already specified. The prototype comes out accurate enough to use for engineering handoff and stakeholder review.
The two together, PRD plus prototype, used to take most of a day. Now the total time is under two hours.
Where the time actually goes now
About an hour of that is still real work, and it should be. That hour is me reviewing the draft PRD, confirming things with engineering, checking the API endpoints, and catching anything that needs to be adjusted before Claude touches the prototype.
That part does not compress further, and I do not want it to. That is the part where I am actually thinking about the product.
The rest, the formatting, the structure, the checklist of edge cases I would otherwise forget, the template sections I would rewrite from scratch every time, that is what the skill handles now.
What made this worth building
The pages are similar enough that the skill generalizes well. If every page were completely different, a skill like this would not make sense. But maintenance CRUD pages share enough structure that one set of questions covers almost everything.
The other thing that helped was having a real PRD to learn from. The first one, the one that took eight hours, became the template. Every section heading, every validation format, every bit of language I kept rewriting the same way, it is all baked into the skill now. The skill is not generating generic output. It is generating output shaped by how I actually write these documents.
What I would tell someone considering this
Build the skill after you have done the task once manually. You need to know what the edge cases are before you can write a skill that catches them. A skill built from scratch without that experience will miss the things that matter.
Keep the questions batched. If you ask everything at once, it is overwhelming and people skip things. Five rounds with a pause in between feels like a conversation, not a form.
Do not skip the self-check. My skill has an internal checklist that Claude runs through before writing the PRD. That checklist exists because I kept forgetting the same things across different pages. Writing them down once means I stop discovering them during QA.
The first page took eight hours. The ones after it take two. The difference is not working faster. It is not repeating the thinking I already did.