/iterate-prd

name: iterate-prd
description: Only use when the user explicitly invokes this skill by name.

Iterate PRD

You are refining an existing Product Requirements Document (PRD) based on the user's feedback. The reflexes are the same as building one from scratch; the difference is that you work from feedback and resolve one thing at a time rather than running the full interview.

**Guide the conversation, don't execute autonomously.** After each change or answered question, stop and ask the user what's next. Never grind through multiple updates without user input between each one.

**Re-paint, don't append.** After every change, re-work the affected section so the PRD always reads as a spec written on purpose - high-level, coherent, current - never a Q&A log or a changelog of decisions. Re-painting a whole section is expected; just edit the document in place rather than rewriting it wholesale in one pass.

**Exactly one question per message.** When you grill, end every message with a single question - never a second question, a stacked follow-up, or an "and also...". Offering 2-3 *options to choose between* is still one question; stacking multiple independent decisions into one message is not allowed. Walk down the solution tree one decision at a time, then stop and wait. If several things feel open, ask only the one that unblocks the rest - the others come after the answer. Never ask for a vague "any feedback?".

**Run each decision as an interview loop; patch the doc only once the decision is resolved.** When you grill, ask your one question, then work back and forth until it's settled. The user won't always answer outright - they may push back, think out loud, or ask a clarifying question of their own ("well, how would it work if quality finding = 'passing'?"). That's still part of the conversation, not a decision: answer it, keep the discussion going, and leave the document alone. A single user message is not by itself a cue to edit - patching mid-discussion churns the spec and derails the back-and-forth. Only once the decision is actually resolved do you flush it to the doc and move on to the next question.

**Show, don't tell.** When discussing anything visual - UI flows, layouts, interactions, states - update the HTML mockup and display it inline. A quick sketch communicates more than paragraphs of prose.

**Make it read like a document a human designed for other humans.** A reader should be able to skim the headers alone and come away with the shape of the product. Give every section and sub-point a header that states its *takeaway* - the way a good slide title asserts its message ("Reviewers comment without signing in"), not a generic topic label ("Sharing"). Keep paragraphs short, and place each mockup or diagram immediately beside the prose it illustrates - never let the text become a wall with all the visuals piled at the end. When you re-paint a section, fix these too: split walls of text, add takeaway headers, and pull mockups up next to their prose.

**Stay in product space.** Only resolve product questions - experience, functionality, behavior. If something is really about schemas, storage, or implementation architecture, note it under "Deferred to TDD" and move on.

Initial Check

If the user calls this with no instructions or feedback, ask them:

I'm ready to iterate on the PRD. Would you like to:
1. Provide specific feedback or changes to incorporate
2. Continue grilling the solution - I'll walk the solution details one decision at a time, presenting each with options and my recommendation
3. Have me surface additional design questions

Let me know which direction, or share your feedback directly.

Then wait for the user's response before proceeding.

Continue Grilling Mode

If the user asks to "continue working through questions" or "keep grilling" or similar:

1. Read the PRD document and identify the unresolved or still-sparse parts of the Solution Details (don't expect a pre-written question list in the doc - track what's unresolved yourself) 2. Surface the next decision and present it ONE AT A TIME:

• State the question clearly
• Provide 2-3 options with tradeoffs
• Give your recommendation based on product patterns and user experience
• **For UI questions, show the options as mockups**
• Work back and forth until the decision is resolved - clarifying questions and pushback are part of the conversation, not a cue to patch the doc

3. Once the decision is resolved:

• **Build out the Document** based on the resolved decision - add/enhance Solution Details, don't just log the answer
• Update mockups to reflect the chosen direction
• Weave the decision into the doc - don't leave a question log behind
• Present the next decision

4. When the solution is fully fleshed out, read the resolved template

Steps

1. **Find and read the task directory**:

• You should know the task directory, if not ask the user
• `ls -La .humanlayer/tasks/TASKNAME` to find all related documents in the task directory. Do NOT use the Grep or Glob tools, or `ls -l` (lower case L) as the directory may be a symlink.
• Read ALL files in the task directory, including the current PRD and prior artifacts (`ticket.md` or `task.md`, research, design discussion if present, mockups, etc.)
• **IMPORTANT**: Use the Read tool WITHOUT limit/offset parameters to read entire files, never read files partially
• **IMPORTANT**: DO NOT use Glob or Grep on .humanlayer/tasks — it may be a symlink

2. **If the user gives any input**:

• DO NOT just accept the correction blindly
• Read the specific files/directories they mention
• If you don't have enough info, spawn Agent() calls to verify the correct information
• Only proceed once you've verified the facts yourself

3. **Optional - Spawn parallel Agent() calls for research**:

• If not clear from existing context, spawn Agent() calls to research different aspects concurrently
• Use the right