to-spec

Guides collaborative specification writing through codebase analysis, discovery interviews, and red-team refinement.

2|2|Updated Jun 28, 2015
One-click install
npx skills add https://github.com/camercu/dotfiles --skill to-spec-camercu
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: to-spec
Source: https://github.com/camercu/dotfiles/tree/main/common/.config/agents/skills/to-spec
Command: npx skills add https://github.com/camercu/dotfiles --skill to-spec-camercu

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Turning vague feature ideas into unambiguous, testable specifications is hard: requirements get missed, designs accumulate unjustified complexity, and implementation sessions lack the context to proceed independently. This Skill provides a structured process that produces a numbered-requirement spec a fresh session can implement from directly. ## Core Features & Use Cases - Structured five-step process: codebase analysis, domain research, discovery interview, draft-and-red-team loop, and final spec writing with nested-numbered requirements. - Adversarial refinement: a red-team checklist stress-tests design proportionality, edge cases, security, and operability, with each pass required to reduce or hold complexity. - Adaptive compression: skip rules for trivial changes, greenfield work, refactors, and prototypes, while never skipping discovery or numbered requirements. - Use Case: A developer planning a new API feature uses this Skill to interview stakeholders, red-team the architecture across multiple cycles, and produce a self-contained markdown spec with testable requirements like 2.14 that another engineer or AI session can implement without conversation history. ## Quick Start Ask the AI to help you write a spec for the feature you have in mind, starting with an analysis of the relevant codebase and a discovery interview.

Frequently Asked Questions about to-spec

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

FAQPage Schema
How do I write a technical specification for a new feature?▼

Follow a five-step process: analyze the codebase, research the domain, run a discovery interview covering users and failure modes, iterate the design with red-team reviews, then write a flat markdown spec with nested-numbered testable requirements grouped by capability.

What makes a good software requirement in a spec?▼

Each requirement should describe what, not how, be testable with an acceptance test, be independent of ordering, and trace back to a discovery finding. Use stable nested numbering like 2.14 and never renumber after deletions.

When should I skip the full specification process?▼

Trivial changes like renames or small bug fixes can go straight to writing the spec, and pure refactors with no behavior change should skip it entirely. Discovery interviews and numbered requirements should never be skipped for actual features.

How many red-team review cycles does a spec need?▼

Typically two to four cycles, repeating until review finds only minor issues. Each pass should reduce or hold complexity steady while improving precision and coverage across functional, technical, security, and operational categories.

Can a spec be implemented without the original conversation?▼

Yes, that is the design goal. The spec is a portable artifact with an architecture section summarizing key design decisions and rationale, so a new session or engineer can load it and begin implementation without conversation history.