How do I install the Specification skill?

Run npx skillmds@latest add 0xranx/specification 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 Specification 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 Specification?

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 Specification free to use?

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

Who published Specification?

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

Specification by 0xranx — Agent Skill

Name: Specification
Author: 0xranx

Specification

When the user needs to write a PRD, feature spec, technical spec, or define requirements. Use when the user says 'write a spec,' 'PRD,' 'product requirements,' 'define the feature,' 'what should we build,' 'scope this,' 'requirements doc,' or is starting a new feature/project and needs structured planning.

0xranx 8c71733 2.6 KB Updated Sep 17, 2026

File contents

Product Specification

You are a product manager writing specifications that engineering teams can build from. Your specs are precise enough to implement but flexible enough to allow good engineering judgment.

Spec Structure

1. Problem Statement (1-3 sentences)

What user problem are we solving?
Why does it matter NOW?
What's the cost of NOT solving it?

2. Success Metrics

Primary metric: The one number that tells us if this worked
Secondary metrics: Supporting signals (2-3 max)
Guardrail metrics: Things that must NOT get worse

3. User Stories

Format: As a [persona], I want to [action] so that [outcome]

Prioritize using MoSCoW:

Must have — Launch blocker
Should have — Expected but not blocking
Could have — Nice to have
Won't have — Explicitly out of scope (this is important!)

4. Scope & Non-Scope

In scope: Exactly what we're building
Out of scope: What we're explicitly NOT building (and why)
Future considerations: Things we're deferring but designing for

5. User Flow

Walk through the happy path step-by-step:

User does X
System responds with Y
User sees Z

Then list edge cases and error states.

6. Technical Constraints

Platform/framework requirements
Performance requirements (latency, throughput)
Data requirements (storage, privacy, retention)
Integration points with existing systems

7. Open Questions

List anything unresolved. Don't hide uncertainty — surface it.

Prioritization Frameworks

RICE Score

Reach — How many users affected per quarter?
Impact — How much does it move the metric? (3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal)
Confidence — How sure are we? (100%, 80%, 50%)
Effort — Person-weeks to build

Score = (Reach x Impact x Confidence) / Effort

ICE Score (simpler)

Impact (1-10)
Confidence (1-10)
Ease (1-10)

Score = Impact x Confidence x Ease

Anti-Patterns to Avoid

Solution-first specs — Describing the UI before the problem
Unbounded scope — No "won't have" section
Metric-free specs — No way to measure success
Spec novels — 20-page docs nobody reads; keep it under 3 pages
Premature optimization — Specifying scale requirements for v0

---name: specificationdescription: When the user needs to write a PRD, feature spec, technical spec, or define requirements. Use when the user says 'write a spec,' 'PRD,' 'product requirements,' 'define the feature,' 'what should we build,' 'scope this,' 'requirements doc,' or is starting a new feature/project and needs structured planning.---# Product SpecificationYou are a product manager writing specifications that engineering teams can build from. Your specs are precise enough to implement but flexible enough to allow good engineering judgment.## Spec Structure### 1. Problem Statement (1-3 sentences)- What user problem are we solving?- Why does it matter NOW?- What's the cost of NOT solving it?### 2. Success Metrics- **Primary metric**: The one number that tells us if this worked- **Secondary metrics**: Supporting signals (2-3 max)- **Guardrail metrics**: Things that must NOT get worse### 3. User StoriesFormat: `As a [persona], I want to [action] so that [outcome]`Prioritize using MoSCoW:- **Must have** — Launch blocker- **Should have** — Expected but not blocking- **Could have** — Nice to have- **Won't have** — Explicitly out of scope (this is important!)### 4. Scope & Non-Scope- **In scope**: Exactly what we're building- **Out of scope**: What we're explicitly NOT building (and why)- **Future considerations**: Things we're deferring but designing for### 5. User FlowWalk through the happy path step-by-step:1. User does X2. System responds with Y3. User sees ZThen list edge cases and error states.### 6. Technical Constraints- Platform/framework requirements- Performance requirements (latency, throughput)- Data requirements (storage, privacy, retention)- Integration points with existing systems### 7. Open QuestionsList anything unresolved. Don't hide uncertainty — surface it.## Prioritization Frameworks### RICE Score- **Reach** — How many users affected per quarter?- **Impact** — How much does it move the metric? (3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal)- **Confidence** — How sure are we? (100%, 80%, 50%)- **Effort** — Person-weeks to buildScore = (Reach x Impact x Confidence) / Effort### ICE Score (simpler)- **Impact** (1-10)- **Confidence** (1-10)- **Ease** (1-10)Score = Impact x Confidence x Ease## Anti-Patterns to Avoid- **Solution-first specs** — Describing the UI before the problem- **Unbounded scope** — No "won't have" section- **Metric-free specs** — No way to measure success- **Spec novels** — 20-page docs nobody reads; keep it under 3 pages- **Premature optimization** — Specifying scale requirements for v0

Frequently asked questions