From harness-claude
Generates structured product specs from GitHub issues, feature requests, or descriptions: user stories with EARS criteria, Given-When-Then scenarios, and traceable PRDs. Use before implementation for clear requirements.
npx claudepluginhub intense-visions/harness-engineering --plugin harness-claudeThis skill uses the workspace's default tool permissions.
> Generate structured product specifications from feature requests, issues, or descriptions. Produces user stories with EARS acceptance criteria, Given-When-Then scenarios, and PRD documents with traceable requirements.
Generates structured Product Requirements Document (PRD) with user stories, acceptance criteria, and functional requirements from approved designs or brainstorms in quantum-loop pipeline.
Writes structured feature specs or PRDs from problem statements or ideas. Covers problem, goals/non-goals, user stories, prioritized requirements, and success metrics.
Teaches PRD structure, user stories, acceptance criteria, API specs, and non-functional requirements for clear feature definition and team alignment.
Share bugs, ideas, or general feedback.
Generate structured product specifications from feature requests, issues, or descriptions. Produces user stories with EARS acceptance criteria, Given-When-Then scenarios, and PRD documents with traceable requirements.
Resolve input source. Accept one of:
gh issue view <number> --json title,body,labels,commentsExtract core elements. From the input, identify:
Identify ambiguities. Flag any element that is missing or unclear:
Resolve ambiguities. Use emit_interaction to present questions when critical information is missing:
The feature request mentions "user notifications" but does not specify:
1. Notification channel (email, in-app, push, SMS)
2. Whether notifications are configurable by the user
3. Retry behavior for failed deliveries
Please clarify before proceeding.
Load project context. Scan the project for existing specs, user stories, or PRDs to maintain consistency in format and terminology:
docs/changes/, docs/requirements/, docs/prd/ for existing documents.github/ISSUE_TEMPLATE/ for the project's preferred issue formatClassify feature type. Categorize the feature as:
Write user stories. For each actor-goal pair, produce a story in standard format:
As a [actor],
I want to [action],
so that [benefit].
Break large features into multiple stories. Each story must be independently deliverable and testable.
Write EARS acceptance criteria. Apply the EARS (Easy Approach to Requirements Syntax) patterns:
Write Given-When-Then scenarios. For each acceptance criterion, produce at least one BDD scenario:
Given [precondition],
When [action],
Then [expected outcome].
Include:
Define edge cases. For each story, enumerate:
Assign story metadata. For each story:
Structure the PRD. Generate a document with these sections:
Write the problem statement. Include:
Define success metrics. Every metric must be:
Map requirements to stories. Create a traceability matrix:
REQ-001 -> US-001, US-003 (must-have)
REQ-002 -> US-002 (should-have)
REQ-003 -> US-004, US-005 (could-have)
Write the PRD to file. Save to the project's spec directory (detected in Phase 1 or defaulting to docs/changes/). Use a filename pattern: YYYY-MM-DD-feature-name-prd.md.
Check story independence. Verify each user story can be delivered independently:
Check acceptance criteria testability. Every EARS criterion must be verifiable:
Check coverage completeness. Verify all parsed elements from Phase 1 are addressed:
Check format consistency. Verify the output matches existing project conventions:
.github/ISSUE_TEMPLATE/ if presentOutput validation summary:
Product Spec Validation: [COMPLETE/INCOMPLETE]
Stories: N generated (M must-have, K should-have)
Acceptance criteria: N (all testable: YES/NO)
BDD scenarios: N (covering N criteria)
Coverage: all actors covered, all constraints addressed
Open questions: N remaining
Generated: docs/changes/2026-03-27-notifications-prd.md
harness skill run harness-product-spec -- Primary command for generating product specifications.harness validate -- Run after generating specs to verify project health.Bash -- Used to fetch GitHub issues via gh CLI and check existing spec files.Read -- Used to read input feature descriptions, existing specs, and issue templates.Write -- Used to generate PRD documents and user story files.Glob -- Used to locate existing spec directories, issue templates, and requirement documents.Grep -- Used to extract domain terminology from existing specs and find related stories.emit_interaction -- Used to present ambiguities for clarification and confirm spec structure before writing.| Rationalization | Why It Is Wrong |
|---|---|
| "The feature request is clear enough -- I can skip the ambiguity check and start writing stories" | The gate: no generating specs from ambiguous input without clarification. Missing actors or undefined triggers lead to untestable acceptance criteria. |
| "This acceptance criterion is understood by the team, so it does not need to be formally testable" | No untestable acceptance criteria is a hard gate. Every criterion must be verifiable by an automated test or specific manual procedure. |
| "The happy path scenarios are enough -- edge cases are unlikely" | The skill requires at least one unwanted-behavior criterion for every user-facing action. Edge cases are where production bugs live. |
| "The existing PRD is outdated, so I will just replace it with a fresh one" | No overwriting existing specs is a gate. Present the diff rather than replacing the file. |
| "We can figure out the success metrics later during implementation" | Every success metric must be measurable, time-bound, and specific at spec time. |
Phase 1: PARSE
Source: gh issue view 234 (title: "Add team notification preferences")
Actor: team admin, team member
Goal: control which notifications team members receive
Ambiguities found:
- Channel not specified (resolved: email + in-app per comment #3)
- "Important notifications" undefined (flagged as open question)
Phase 2: CRAFT
US-001: As a team admin, I want to set default notification preferences for my team,
so that new members receive appropriate notifications without manual setup.
AC-001 (Ubiquitous): The system shall apply team-default preferences to new members on join.
AC-002 (Event-driven): When a team admin updates default preferences, the system shall
prompt whether to apply to existing members.
AC-003 (Unwanted): If a team member has custom preferences, then the system shall
preserve them when team defaults change.
US-002: As a team member, I want to override team notification defaults,
so that I receive only notifications relevant to my role.
Scenario: Given a team member with default preferences,
When they disable "deployment" notifications,
Then they shall not receive deployment notifications
And their other preferences remain unchanged.
Phase 3: GENERATE
Written: docs/changes/2026-03-27-team-notifications-prd.md
Sections: problem statement, 4 user stories, 12 acceptance criteria, 8 BDD scenarios
Traceability: REQ-001 -> US-001, US-002 | REQ-002 -> US-003, US-004
Phase 4: VALIDATE
Stories: 4 (2 must-have, 1 should-have, 1 could-have)
Acceptance criteria: 12 (all testable: YES)
Open questions: 1 ("important notifications" needs product definition)
Result: COMPLETE
Phase 1: PARSE
Source: inline text "We need to handle Stripe webhooks for subscription changes"
Actor: billing system (automated), finance admin (human oversight)
Constraints: idempotency required, webhook signature verification, 5-second response SLA
Ambiguities:
- Which subscription events? (resolved via clarification: created, updated, canceled, past_due)
- Retry handling? (Stripe retries for 72 hours)
Phase 2: CRAFT
US-001: As the billing system, I want to process Stripe subscription.updated webhooks,
so that user plan changes are reflected within 60 seconds.
AC-001 (Event-driven): When a subscription.updated webhook arrives, the system shall
update the user's plan within 60 seconds.
AC-002 (Unwanted): If a duplicate webhook event ID is received, then the system shall
return 200 OK without reprocessing.
AC-003 (Unwanted): If webhook signature verification fails, then the system shall
return 400 and log a security warning.
Phase 3: GENERATE
Written: docs/changes/2026-03-27-stripe-webhooks-prd.md
Technical constraints section includes: idempotency keys, signature verification,
5-second response SLA, Stripe retry behavior documentation
Phase 4: VALIDATE
All 4 webhook event types have stories: YES
Idempotency criterion is testable: YES (duplicate event ID -> no side effects)
Result: COMPLETE