to-specs

Converts requirements and conversation context into structured specification documents.

1|2|Updated Nov 25, 2017
One-click install
npx skills add https://github.com/asarchami/dotfiles --skill to-specs-asarchami
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: to-specs
Source: https://github.com/asarchami/dotfiles/tree/main/dot_config/opencode/skills/to-specs
Command: npx skills add https://github.com/asarchami/dotfiles --skill to-specs-asarchami

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Turning vague requirements or scattered conversation context into a clear, testable specification is time-consuming and error-prone. This Skill provides a repeatable framework for writing and maintaining specs that cover stakeholders, acceptance criteria, module design, testing seams, and edge cases. ## Core Features & Use Cases - Structured Spec Template: Generates requirement sections covering 15 dimensions including user stories, acceptance criteria, implementation decisions, and non-functional requirements. - Test Seam Planning: Sketches testing seams before writing the spec, preferring existing high-level seams to minimize test surface area. - Deep Module Design: Identifies opportunities to encapsulate complexity behind narrow, stable interfaces and distinguishes deep modules from shallow ones. - Guided Interviewing: Asks one question at a time, starting with foundational concerns, and explores the codebase instead of asking when answers are discoverable. - Use Case: After a design discussion about a new feature, ask the assistant to turn the conversation into a spec document with acceptance criteria, module sketches, and open questions ready for team review. ## Quick Start Ask the assistant to turn the current requirements discussion into a structured spec document using the to-specs framework.

Frequently Asked Questions about to-specs

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

FAQPage Schema
How do I turn requirements into a structured spec document?▼

Provide the requirements or conversation context and ask for a spec. The Skill explores the codebase, sketches test seams, then writes sections covering user stories, acceptance criteria, implementation decisions, and edge cases using a fixed template.

What sections should a software feature specification include?▼

This framework uses 15 dimensions per requirement: stakeholder, problem statement, solution, user stories, acceptance criteria, implementation decisions, module sketch, testing decisions, non-functional requirements, edge cases, out of scope, priority, dependencies, open questions, and notes.

What is a test seam in specification planning?▼

A test seam is a boundary where a feature can be tested. The Skill prefers existing seams and the highest-level seam possible, aiming for as few seams as possible across the codebase, ideally one per feature.

Should a spec include file paths and code snippets?▼

Generally no, because they go stale quickly. The exception is a prototype snippet that encodes a decision more precisely than prose, such as a state machine, schema, or type shape, trimmed to decision-rich parts.

When should I not use a structured spec framework?▼

Avoid heavyweight specs for trivial changes, quick prototypes, or exploratory spikes where requirements are still unstable. The framework suits features needing stakeholder alignment, test planning, and architectural decisions.