How do I install the Spec Writer skill?

Run npx skillmds@latest add jkappers/spec-writer in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Spec Writer safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Spec Writer?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Spec Writer free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Spec Writer?

jkappers (@jkappers) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Spec Writer by jkappers — Agent Skill

Name: Spec Writer
Author: jkappers

Spec Writer

Write feature specifications that capture requirements and acceptance criteria. Use when (1) writing a new feature spec, (2) documenting functional requirements, (3) defining acceptance criteria for a feature, (4) capturing design goals and constraints for planned work, or (5) structuring a product idea into a formal specification.

jkappers 4c5f0e4 3 files · 4.5 KB Updated Sep 17, 2026

File contents

Spec Writing

Capture WHAT and WHY. Never prescribe HOW.

When invoked with arguments, write a spec for: $ARGUMENTS

Workflow

Gather context: Collect feature description, target users, problem statement, and constraints from user input or $ARGUMENTS. Ask clarifying questions for missing information.
Create directory: specs/feature-name/
Copy assets/spec.md to specs/feature-name/README.md
Complete every section from the Required Sections table below
Validate against the checklist before completing

Required Sections

Section	Content
Feature Overview	2-3 paragraphs: what, who, problem solved
Success Criteria	Measurable outcomes defining "done"
Design Goals	Primary (must) and secondary (nice to have)
User Experience	1-2 paragraphs: interaction, journey
Design Rationale	1-2 paragraphs: why this approach, trade-offs
Constraints/Assumptions	Technical constraints, business assumptions
Functional Requirements	FR-N format, max 6-8, with acceptance criteria
Edge Cases	Unusual inputs, failure scenarios

Acceptance Criteria

- [ ] Given [context], when [action], then [expected result]

Include 2-4 criteria per requirement: happy path + key failure cases.

Scope Check

More than 6-8 requirements = feature too large. Split: identify 3-4 core requirements, flag rest for separate spec in "Scope Notes" section.

Validation Checklist

Single MVP focus (one deliverable)
All requirements have testable criteria
No TODO/TBD placeholders
Edge cases documented

Exclusions

A spec defines WHAT to build, not HOW to build it. Exclude:

Implementation approach or technical strategy
Architecture diagrams
Code examples
Database schemas
API signatures
Technology or framework choices
Development estimates, timelines, or phase sections

Supporting Files

assets/spec.md - Spec template
references/spec-guide.md - Extended guidance on ADRs and archival

---name: spec-writerdescription: Write feature specifications that capture requirements and acceptance criteria. Use when (1) writing a new feature spec, (2) documenting functional requirements, (3) defining acceptance criteria for a feature, (4) capturing design goals and constraints for planned work, or (5) structuring a product idea into a formal specification.---# Spec WritingCapture WHAT and WHY. Never prescribe HOW.When invoked with arguments, write a spec for: $ARGUMENTS## Workflow1. Gather context: Collect feature description, target users, problem statement, and constraints from user input or $ARGUMENTS. Ask clarifying questions for missing information.2. Create directory: `specs/feature-name/`3. Copy `assets/spec.md` to `specs/feature-name/README.md`4. Complete every section from the Required Sections table below5. Validate against the checklist before completing## Required Sections| Section | Content ||---------|---------|| Feature Overview | 2-3 paragraphs: what, who, problem solved || Success Criteria | Measurable outcomes defining "done" || Design Goals | Primary (must) and secondary (nice to have) || User Experience | 1-2 paragraphs: interaction, journey || Design Rationale | 1-2 paragraphs: why this approach, trade-offs || Constraints/Assumptions | Technical constraints, business assumptions || Functional Requirements | FR-N format, max 6-8, with acceptance criteria || Edge Cases | Unusual inputs, failure scenarios |## Acceptance Criteria```markdown- [ ] Given [context], when [action], then [expected result]```Include 2-4 criteria per requirement: happy path + key failure cases.## Scope CheckMore than 6-8 requirements = feature too large. Split: identify 3-4 core requirements, flag rest for separate spec in "Scope Notes" section.## Validation Checklist- [ ] Single MVP focus (one deliverable)- [ ] All requirements have testable criteria- [ ] No TODO/TBD placeholders- [ ] Edge cases documented## ExclusionsA spec defines WHAT to build, not HOW to build it. Exclude:- Implementation approach or technical strategy- Architecture diagrams- Code examples- Database schemas- API signatures- Technology or framework choices- Development estimates, timelines, or phase sections## Supporting Files- `assets/spec.md` - Spec template- `references/spec-guide.md` - Extended guidance on ADRs and archival

Frequently asked questions