to-spec

Synthesizes conversation context into a Spec and publishes it to the project issue tracker.

20|2|Updated May 16, 2026
One-click install
npx skills add https://github.com/reddb-io/red-skills --skill to-spec-reddb-io
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: to-spec
Source: https://github.com/reddb-io/red-skills/tree/main/plugins/dev/skills/engineering/to-spec
Command: npx skills add https://github.com/reddb-io/red-skills --skill to-spec-reddb-io

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Converting a long design conversation into a durable, structured specification is tedious and error-prone; decisions made by the human get lost or confused with agent inference. This Skill turns the current conversation context into a complete Spec and publishes it to the project issue tracker without re-interviewing the user. ## Core Features & Use Cases - Spec Synthesis: Generates a full Spec from existing conversation context, including problem statement, user stories, implementation decisions, testing decisions, and acceptance criteria. - Human Decision Capture: Records every HITL call (testing seams, trade-offs, rejected alternatives) in a dedicated Human Decisions section so downstream slicing and autonomous execution preserve human judgement. - Tracker Publishing with Labels: Publishes the Spec with type:spec and needs-slicing labels, creates territory tag:<value> labels on demand, and enforces a cascade gate that blocks publishing while .red/ docs are unlanded. - Use Case: After a design discussion about a new feature, run the Skill to produce a tracker-ready Spec that /to-tickets can later slice into implementable child issues for /afk workers. ## Quick Start Ask the agent to turn the current conversation into a Spec and publish it to the issue tracker, optionally passing territory tags with --tags a,b.

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 Spec for my issue tracker?▼

Run the to-spec Skill after the design discussion; it synthesizes the existing conversation into a full Spec template and publishes it to the project issue tracker. No new interview is conducted — it uses context already gathered.

What labels does a published Spec get in the issue tracker?▼

Published Specs receive `type:spec` and `needs-slicing` labels, plus territory `tag:<value>` labels when passed via --tags. The Skill deliberately does not apply `ready-for-agent`, since a Spec must be sliced by /to-tickets first.

Why does to-spec refuse to publish a Spec sometimes?▼

Publishing is blocked when `.red/` docs in the working tree differ from `origin/{base}`, because AFK workers branch from origin and cannot see unlanded edits. The Skill runs the doc-landing procedure first, or aborts if landing is impossible.

What is the difference between Human Decisions and Implementation Decisions in the Spec?▼

Human Decisions capture judgement calls the user made during the conversation, with reasons and rejected alternatives. Implementation Decisions record agent-inferred technical choices such as module shapes, interfaces, and schema changes.

What happens after a Spec is published?▼

The /to-tickets Skill consumes Specs labeled `needs-slicing`, generates child issues with `spec:{N}` and `ready-for-agent` labels, and removes `needs-slicing` from the parent. AFK workers then pick up the child tickets.