writing-prds

Generates PRDs with assertable, test-verifiable acceptance criteria for Laravel and Inertia projects.

Updated Jul 14, 2026
One-click install
npx skills add https://github.com/bond23869/skills --skill writing-prds-bond23869
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: writing-prds
Source: https://github.com/bond23869/skills/tree/main/writing-prds
Command: npx skills add https://github.com/bond23869/skills --skill writing-prds-bond23869

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Vague acceptance criteria like "the feature works" cannot be verified by tests, so implementations ship unproven and regressions go undetected. This Skill turns feature ideas into PRDs where every criterion is a concrete, machine-checkable assertion tied to an automated test pipeline. ## Core Features & Use Cases - Structured PRD generation: Asks 3-5 clarifying questions with lettered options, then produces a full PRD with user stories, numbered functional requirements, non-goals, success metrics, and open questions, saved to tasks/prd-[feature-name].md. - Assertable acceptance criteria: Every criterion follows an act-then-observable-result pattern tagged by verification layer ([feature], [unit], [vitest], [browser]), with a divergent-data rule for filter and search assertions. - Verification checklist and spec files: Each PRD ends with per-change coverage, test data seeding instructions, browser end-to-end steps, and suite gates, plus a spec file created under specs/features/ with Status: planned. - Use Case: A product manager says "spec out a task priority feature." The Skill asks clarifying questions, then writes a PRD where each story names exact test files, seed data counts, and dev-browser click-paths so an agent can later prove the feature works. ## Quick Start Ask the assistant to write a PRD for your feature, for example: "Write a PRD for adding priority levels to tasks with filtering and badges."

Frequently Asked Questions about writing-prds

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write acceptance criteria that can be automatically tested?

Write each criterion as an action with specific data followed by an observable result, such as a DOM change, HTTP status, or console state. Tag it with a verification layer like [feature] or [browser] so a test or dev-browser can assert it without judgement calls.

What should a PRD for a Laravel and Inertia feature include?

Include an overview, goals, user stories with tagged acceptance criteria, numbered functional requirements, non-goals, success metrics, open questions, and a verification checklist. The checklist covers per-change layer coverage, test data seeding, browser end-to-end steps, and suite gates.

How do I verify filter and search features actually work?

Use the divergent-data rule: seed records so each filter value returns a different count, then assert the count changed. For example, with 12 total records, selecting a filter must show exactly 4 rows, not 12, proving the filter is not silently broken.

When should acceptance criteria use browser tests instead of feature tests?

Default most criteria to fast [feature] or [vitest] tests, which form the regression net. Reserve [browser] criteria for the new feature's real click-paths and anything that must visually render, since browser runs are slow.

Does this PRD workflow handle multi-tenant data isolation?

Yes. Any feature touching tenant data must include mandatory [feature] criteria proving organization scoping, such as asserting a user in org A never receives org B's records. Seed data in both organizations to prove cross-org isolation.