Writes product requirements documents that AI agents can act on reliably, with explicit constraints, edge cases, and acceptance criteria that minimize the gap between what you mean and what the agent builds. This skill bridges the ambiguity of natural language product specs and the precision that AI agents require to produce consistent results.
Use cases
- Writing requirements for a feature to be implemented by an AI coding assistant where vague natural language would lead to inconsistent results
- Specifying acceptance criteria for a feature where different interpreters would implement the same description differently
- Creating a PRD for an autonomous AI agent task where the agent needs to make consistent decisions in ambiguous situations
- Aligning a cross-functional team on a feature where engineers, designers, and product managers have different mental models
- Defining the boundaries of an AI feature: what the AI should handle autonomously versus what requires human escalation
Key features
- Define the user goal explicitly, including what information the user provides, what the system should produce, and what constraints apply to the output
- List edge cases explicitly—what should happen when the input is empty, malformed, ambiguous, or at the boundary of the defined scope
- State acceptance criteria in verifiable, testable terms: 'the system should X when Y' rather than 'the system should handle X appropriately'
- Include anti-examples alongside positive examples: 'when the user asks for X, the system should NOT do Y' to prevent common misinterpretations
- Review the PRD by asking a colleague or AI to act on it and noting where their interpretation diverges from your intent—those gaps reveal ambiguity to fix
When to Use This Skill
- When handing off a feature to an AI agent or an engineer who was not in the original product discussion
- When acceptance criteria need to be testable and verifiable rather than subjective
- When defining AI features where the scope of autonomous action needs to be explicit to avoid over- or under-autonomy
Expected Output
A complete PRD with explicit user goals, edge cases, verifiable acceptance criteria, anti-examples, and a review note confirming the spec is interpretable consistently.
Frequently Asked Questions
- What makes a PRD 'AI-actionable' versus a regular PRD?
- AI-actionable PRDs treat ambiguity as a defect. Where a human reviewer would ask for clarification, an AI proceeds with an assumption. Specify edge cases, output formats, and constraints explicitly—even redundantly—because what seems obvious to a human is often interpreted differently by an AI.
- Should I include UI mockups in a PRD for an AI feature?
- Yes, especially for features that involve generative output where 'good' is subjective. Mockups or examples of expected output reduce interpretation variance. Include both a best-case example and a minimum acceptable example.
- How do I handle requirements that are intentionally flexible?
- Specify the flexibility bounds explicitly: 'the system may do X or Y depending on Z, but must never do W.' AI agents handle bounded flexibility better than unbounded openness.
Related
Related
3 Indexed items
Writing implementation plans
Converts vague or frozen requirements into precise, step-by-step implementation plans with file-level touchpoints, decision checkpoints, and verifiable acceptance criteria before any code is written. This bridges the gap between what stakeholders want and what engineers can actually ship, reducing mid-sprint surprises and wasted refactors.
Receiving code review
Structures how you respond to code review feedback so the review process stays focused, respectful, and productive. This skill separates substantive feedback from nitpicks, tracks follow-ups without losing them, and produces a record that makes merges faster and post-mortems clearer.
Documentation from code
Extracts architecture decisions, API contracts, and usage patterns directly from code to produce accurate documentation that stays in sync with implementation. Documentation-from-code treats code as the source of truth and generates prose from it rather than maintaining documentation as a separate artifact that diverges over time.