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.