to-spec

Converts agreed conversation decisions into a concise specification with acceptance criteria and scope.

Updated Jul 3, 2026
One-click install
npx skills add https://github.com/alex-jordan547/agent-setup --skill to-spec-alex-jordan547
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: to-spec
Source: https://github.com/alex-jordan547/agent-setup/tree/main/skills/to-spec
Command: npx skills add https://github.com/alex-jordan547/agent-setup --skill to-spec-alex-jordan547

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a long design discussion, decisions, assumptions, and open questions are scattered across the conversation. This Skill synthesizes what was already agreed into a concise specification with observable acceptance criteria, so implementation can start from a shared, verifiable document instead of chat history. ## Core Features & Use Cases - Decision synthesis: Distinguishes agreed decisions, reasonable assumptions, and unresolved choices, checking the relevant code and existing domain terms before writing. - Structured specification: Covers the user's problem, desired behavior, contracts, acceptance criteria, verification methods, scope exclusions, and open decisions, using the project's own spec format when one exists. - Publication handling: Uses the requested destination and existing tracker conventions, publishing directly when authorized or saving to the project's established documentation location. - Use Case: After discussing a new API endpoint with your AI assistant, ask it to turn the conversation into a spec with acceptance criteria, then publish it to your issue tracker for the team to implement. ## Quick Start Turn our conversation about the export feature into a specification with acceptance criteria and save it to the project docs.

Frequently Asked Questions about to-spec

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

FAQPage Schema
How do I turn a design conversation into a specification?

Ask the assistant to convert the conversation into a spec. It synthesizes agreed decisions, reasonable assumptions, and unresolved choices, then structures them into problem statement, contracts, acceptance criteria, and scope exclusions.

What should a good software specification include?

A specification should cover the user's problem and desired behavior, contracts or decisions needed for implementation, acceptance criteria with verification methods, and scope exclusions with unresolved decisions. Detail should scale to the size of the work.

Can the spec be published directly to an issue tracker?

Yes, when publication is authorized the spec is published without another routine confirmation and the returned item is verified. Otherwise it is saved to the project's established documentation location using existing tracker conventions.

Does it follow my project's existing spec format?

Yes, the project's own spec format is used when one is present. Only when no format exists does it fall back to a default structure covering problem, contracts, acceptance criteria, and scope.

When should I not write a full specification?

Avoid exhaustive user stories and speculative implementation plans for small changes. Detail should scale to the work; use examples or a small decision-bearing snippet only when they clarify a contract.