Individual skill

product-spec

Use when the user needs to scope, write, or audit a product spec — a PRD, feature spec, user stories, acceptance criteria, or a "spec this out"/"break this into stories"/"definition of done" request — or wants an existing spec reviewed for gaps and anti-patterns. Triggers whenever a feature idea needs to become structured requirements that align a team on what to build. For the analytics behind success metrics, use data-analysis; for the technical design, use software-architect.

product-spec/SKILL.md

Read pinned source

Source commit d4d207119b9affb3cd653805c9807598841e90f2

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
Yes
Observed behavior
Instructions only
Last checked
Nov 11, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
44
Repository last updated
Jul 2, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Product Spec Writer

## Purpose

Help founders, PMs, and product teams produce thorough, well-structured product specification documents — PRDs, feature specs, and user stories — through a guided discovery process. Outputs are always markdown files. The skill also audits existing specs for anti-patterns and gaps.

## Output discipline

Deliver only what the user will actually use. Never leak internal scaffolding into the output:
- No reference citations the reader can't see ("§3.2", "per the knowledge base", "KB §1.4").
- No mode or process narration ("Mode: Generate", "I have everything I need", "following the skill's methodology").
- No skill-handoff chatter inside the deliverable.

Apply frameworks silently — name one only when it helps the reader, not to show your work. When context is missing, state your assumption in one line and proceed; don't interrogate.
Back to top