harness-product-spec

Generate structured product specifications with EARS acceptance criteria from GitHub issues.

18|11|Updated Mar 16, 2026
One-click install
npx skills add https://github.com/Intense-Visions/harness-engineering --skill harness-product-spec
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: harness-product-spec
Source: https://github.com/Intense-Visions/harness-engineering/tree/main/agents/skills/claude-code/harness-product-spec
Command: npx skills add https://github.com/Intense-Visions/harness-engineering --skill harness-product-spec

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Feature teams struggle to transform scattered feature requests and issues into precise, testable product specifications, causing misalignment and delays.

Core Features & Use Cases

  • Generate structured user stories with Given-When-Then scenarios from input descriptions
  • Produce EARS-style acceptance criteria and traceable PRDs
  • Ensure alignment between issues, requirements, and implementation

Quick Start

Run harness-product-spec to convert a GitHub issue or feature description into a complete PRD, US, and AC set.

Frequently Asked Questions about harness-product-spec

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

FAQPage Schema
How do I generate user stories with acceptance criteria from GitHub issues?

To generate user stories with acceptance criteria from GitHub issues, provide the issue text to the Skill. It analyzes feature descriptions to produce structured PRDs with traceable requirements, EARS-style acceptance criteria, and Given-When-Then scenarios.

What is the best way to turn feature requests into traceable product specifications?

The best way to turn feature requests into traceable product specifications is automating conversion using structured PRD generation. It maps requirements directly to user stories and ensures testable EARS acceptance criteria, aligning issues with implementation.

How does EARS syntax work for writing acceptance criteria in a PRD?

EARS syntax for acceptance criteria in a PRD works by structuring conditions using predefined patterns to make requirements unambiguous and testable. The Skill applies this syntax to produce Given-When-Then scenarios that ensure alignment between issues and implementation.

Can I use inline text instead of GitHub issues to generate a product spec?

Yes, you can use inline text to generate a product spec. The Skill accepts inline feature descriptions as input, analyzing the provided text to output a complete PRD, user stories, and traceable acceptance criteria without requiring a GitHub issue.

How do I map requirements to user stories and Given-When-Then scenarios?

To map requirements to user stories and Given-When-Then scenarios, the Skill processes feature requests and outputs a structured PRD. It ensures traceability by linking each requirement directly to its corresponding user story and testable scenarios.