to-spec

Synthesizes conversation context and repository knowledge into a published spec or PRD.

Updated Jun 28, 2026
One-click install
npx skills add https://github.com/jason23452/my-skill --skill to-spec-jason23452
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: to-spec
Source: https://github.com/jason23452/my-skill/tree/main/flow/to-spec
Command: npx skills add https://github.com/jason23452/my-skill --skill to-spec-jason23452

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a long product discussion, teams often lose decisions or re-litigate settled questions when writing requirements. This Skill converts the current conversation and repository context into a structured spec/PRD and publishes it to the project's issue tracker without re-interviewing the user. ## Core Features & Use Cases - Context Synthesis: Reads existing README, AGENTS, ADRs, domain glossaries, and code to write specs in the project's own domain language. - Structured Spec Template: Produces problem statement, solution, numbered user stories, implementation decisions, test decisions, out-of-scope items, and open questions. - Test Seam Planning: Sketches testing seams before writing the spec and confirms architectural impacts with the user. - Tracker Publishing: Publishes the spec to the configured issue tracker and applies labels like ready-for-agent. - Use Case: After discussing a new checkout feature with the AI, invoke this Skill to produce a PRD that a to-issues or to-tickets skill can later split into implementable work items. ## Quick Start Ask the AI to turn the current discussion into a spec and publish it to the project issue tracker using the to-spec skill.

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 product discussion into a PRD with AI?▼

Invoke the to-spec skill after the discussion. It synthesizes the conversation and repository context into a structured spec covering problem statement, user stories, implementation and test decisions, then publishes it to your issue tracker.

How to write a spec without re-interviewing stakeholders?▼

The skill only consolidates content already discussed and never re-opens settled product questions. Anything unknown is captured as explicit open questions rather than filled in with guesses.

Does to-spec publish specs to an issue tracker automatically?▼

Yes, it publishes according to the tracker and label vocabulary configured by the project setup. If no tracker configuration is found, it reports the missing setup instead of guessing a destination.

What sections does the generated spec template include?▼

The template includes problem statement, solution, numbered user stories, implementation decisions, test decisions, out-of-scope items, and supplementary notes with assumptions and open questions.

When should I not use to-spec for requirements documentation?▼

Avoid it when product decisions are still unsettled, since it will not re-open discussion or invent new features. It is designed for documenting already-clarified scope, not for discovery or brainstorming.