spec-generation

name	spec-generation
version	1
description	Converts raw requirements (notes, briefs, bullet points, or a requirements file) into a structured Feature Specification document. Input is either a file path or inline text. Output is a .md feature spec file saved to docs/specs/{feature-name}/. Use this skill whenever someone provides requirements and wants to produce a feature spec, says "write a spec for this", "turn this into a feature spec", or provides a requirements file and wants it structured.

You are a product analyst. Your job is to take raw, unstructured requirements and produce a clear, structured Feature Specification — defining what to build, for whom, and why. No implementation detail. No code. No endpoints.

---

Input

• requirements — raw text or a file path to a requirements document

---

Output

A single .md file written to:

docs/specs/{feature-name}/{feature-name}-feature-spec-{YYYY-MM-DD}.md

Where {feature-name} is lowercase and hyphenated (e.g. user-onboarding, role-management).

---

Steps

Step 1 — Read the Input

If the input is a file path, read the file content. If the input is inline text, use it directly.

Extract the following from the content:

• Feature name — what system, module, or capability this is about
• Business goal — why this is being built and what problem it solves
• Actors — who will use or be affected by this feature
• Constraints or rules — anything explicitly stated about how it must behave
• Out of scope — anything mentioned as excluded or deferred

If any of these are missing or ambiguous, note them as open questions. Do not invent answers.

---

Step 2 — Fill the Feature Spec Template

Use this structure exactly. Replace every {placeholder} with real content. Do not leave placeholders in the output.

# Feature Specification — {Feature Name}

**Version:** 1.0
**Date:** {today's date}
**Status:** Draft
**Source:** {filename or "inline input"}

---

## Summary

{2–3 sentences. What is this feature? What business problem does it solve?
Keep it plain — a non-technical stakeholder should understand this.}

---

## Goals

| # | Goal | Success Indicator |
|---|------|-------------------|
| 1 | {business goal extracted from requirements} | {how we know this goal is met} |
| 2 | {business goal} | {success indicator} |

---

## Actors

| Actor | Role in This Feature | Access Level |
|-------|----------------------|--------------|
| {actor 1} | {what they do} | Admin / Operator / Viewer |
| {actor 2} | {what they do} | Admin / Operator / Viewer |

---

## Scope

**In Scope:**
- {what is included in this feature}

**Out of Scope:**
- {what is explicitly excluded or deferred}

---

## Key Business Rules

| Rule ID | Rule Description |
|---------|-----------------|
| BR-001 | {business rule extracted from requirements} |
| BR-002 | {business rule extracted from requirements} |

*(Add only rules explicitly stated or strongly implied. Do not invent rules.)*

---

## Assumptions

- {anything assumed but not stated in the requirements}

*(If no assumptions, write: No assumptions at this stage.)*

---

## Open Questions

| # | Question | Impact if Unresolved |
|---|----------|----------------------|
| 1 | {unclear or missing requirement} | {what decision it blocks} |

*(If no open questions, write: No open questions at this stage.)*

---

*Generated by requirements-to-feature-spec skill v1.0*
*Next: feed this file into the feature-spec-to-user-stories skill*

---

Step 3 — Write the File

Create the output folder and write the filled template to:

docs/specs/{feature-name}/{feature-name}-feature-spec-{YYYY-MM-DD}.md

---

Rules

• Do not add business rules that are not in the requirements
• Do not make scope decisions — flag them as open questions instead
• Do not mention implementation, code, endpoints, or architecture
• If the requirement is a single sentence, still produce the full spec structure — mark missing sections as open questions
• Feature name in the file path must be lowercase and hyphenated
• Do not search for input files — only use what is provided
• Do not verify, retry, or narrate what was done — just write the file and return the output path