vc-generate-spec

Generates plain-language product-discovery SPEC requirements documents from research findings and user intent.

Updated Apr 9, 2026
One-click install
npx skills add https://github.com/HyuseCS/project-c --skill vc-generate-spec-hyusecs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: vc-generate-spec
Source: https://github.com/HyuseCS/project-c/tree/main/.claude/skills/vc-generate-spec
Command: npx skills add https://github.com/HyuseCS/project-c --skill vc-generate-spec-hyusecs

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Turning research findings and user brainstorms into a reviewable requirements document is often skipped or done inconsistently, leading to misaligned builds. This Skill produces a structured, user-facing SPEC artifact that captures what the user wants and why before any approach or code is chosen. ## Core Features & Use Cases - Canonical SPEC Generation: Writes a requirements document with nine mandatory sections in fixed order, including user stories, behavioral outcomes, ASCII flow diagrams, and testable acceptance criteria. - Acceptance Criteria Discipline: Every criterion carries a proven by: test scenario and a strategy: annotation, with fully-automated E2E gates required wherever behavior is automatable. - Phase Program Support: Provides an umbrella program SPEC template that governs multi-phase work, written once and frozen once planning begins. - Use Case: After researching a new feature, ask the agent to produce a SPEC so stakeholders can confirm "yes, build that" before INNOVATE or PLAN phases start. ## Quick Start Ask the agent to generate a SPEC for your feature idea based on the completed research findings and your stated intent.

Frequently Asked Questions about vc-generate-spec

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

FAQPage Schema
How do I write a product requirements document for user review?

Use this Skill to generate a SPEC from research findings and stated user intent. It produces nine canonical sections in plain language, including user stories, behavioral outcomes, and acceptance criteria, written for a non-engineer reviewer.

What sections should a product discovery SPEC include?

The SPEC requires nine sections in fixed order: Summary, User Stories/Jobs To Be Done, Behavioral Outcomes, Flow/State Diagram, Acceptance Criteria, Out Of Scope, Constraints, Open Questions, and Background/Research Findings.

How are acceptance criteria made testable in a SPEC?

Each acceptance criterion must name a test scenario via `proven by:` and declare a `strategy:` of Fully-Automated, Hybrid, or Agent-Probe. Fully-automated E2E gates are required wherever behavior is automatable, and vacuous-green outcomes are banned.

Can a SPEC be edited after planning begins?

No. Once INNOVATE or PLAN begins, the SPEC is frozen and never edited. Scope gaps discovered later are recorded in the phase report under a SPEC Gaps heading plus a backlog note.

What happens if open questions remain when finalizing a SPEC?

In an interactive session the Skill emits SPEC_INTENT_BLOCKED and stops instead of writing the file. Under a /goal run, each open question is recorded as a backlog note and the workflow continues.