write-prd

Included with Lifetime

$97 forever

Transform a conversation or idea into a structured PRD with user stories, testing seams, and implementation decisions. Use when the user wants to create a PRD, write a spec, or turn the current context into a product requirements doc.

Writing & Docs

What this skill does

# Write a PRD

Create a Product Requirements Document from the current conversation or a provided description.

If the user passed a file, path, or description as an argument, read it fully first.

## Process

1. **Gather context first** — ALWAYS ask 3-5 clarifying questions via `AskUserQuestion` BEFORE writing
any PRD. Never skip this step. Do NOT output PRD sections until you have answers. Ask about:
- **Users**: target users/personas?
- **Scope & non-goals**: what's in/out of scope?
- **Success criteria**: measurable acceptance criteria?
- **Technical specifics**: APIs, constraints, current state?
- **Current state**: what exists today?
2. **Explore the codebase** — understand the current state. Use the project's domain glossary
(`CONTEXT.md`) vocabulary throughout the PRD, and respect existing decision issues in the area
you're touching.
3. **Sketch the seams** — before drafting, identify the seams at which you'll _test_ the feature.
Prefer existing seams to new ones. Use the highest seam possible. If new seams are needed, propose
them at the highest point you can. **Confirm the seams match the user's expectations before
writing.** These feed the Testing Decisions section.
4. **Draft the PRD** — only after answers + seams, use the template below.
5. **Present for review** — show the draft, get feedback via `AskUserQuestion`.
6. **Output** — ask preference: save to `docs/plans/YYYY-MM-DD-<feature-name>.md` or a GitHub issue.

## PRD Template

```markdown
# [Feature Name]

## Problem Statement

What problem does this solve? Who has it? From the user's perspective.

## Goals

- Goal 1

## Non-Goals

- Explicitly out of scope

## User Stories

A long, numbered list. Each: "As a [user], I want [action], so that [outcome]". Cover all aspects of
the feature — be extensive.

## Acceptance Criteria

- [ ] Criterion 1 (specific and testable)

## Implementation Decisions

The modules built/modified, interfaces changed, architectural decisions, schema changes, API
contracts. Do NOT include specific file paths or code snippets — they go stale fast. (Exception: a
prototype-produced snippet that encodes a decision more precisely than prose — a state machine,
reducer, schema, or type shape — may be inlined, trimmed to the decision-rich parts, noted as
prototype-sourced.)

## Testing Decisions

- What makes a good test here (test external behavior, not implementation details)
- The seams at which the feature will be tested (from the Sketch step)
- Which modules will be tested
- Prior art — similar tests already in the codebase

## Open Questions

- Anything unresolved
```

## Rules

- **Questions first, always** — the first response must be clarifying questions, never a PRD draft.
- **User stories are mandatory** — every feature maps to at least one.
- **Acceptance Criteria are mandatory** — specific, testable. Write them before Implementation Decisions.
- **No file paths or code snippets** in Implementation Decisions (prototype-snippet exception aside).
- Use `CONTEXT.md` vocabulary; respect decision issues in the area.
- Keep it concise — 1-3 pages, not a novel.

Files: 1

Size: 3.4 KB

Complexity: 13/100

Category: Writing & Docs

Source: https://github.com/christowles/towles-tool/tree/main/packages/core/skills/write-prd

Related in Writing & Docs

jax-development

Included

Use this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.

Writing & Docsscripts

nature-article-writer

Included

Drafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.

Writing & Docsscripts

deckrd

Included

Document-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.

Writing & Docsscripts

clinical-decision-support

Included

Generate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.

Writing & Docsscripts

handling-sf-data

Included

Salesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).

Writing & Docsscripts

accelint-ac-to-playwright

Included

Convert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.

Writing & Docsscripts