spec-itlisted

Turns a raw feature idea into a `/work-issue`-ready GitHub issue with an embedded draft spec, grounded in repo + memory + external standards research. Mirrors `/work-issue`'s gated phased workflow but UPSTREAM of it — `/spec-it` produces the issue, `/work-issue` implements it. Adapts to whatever spec conventions the target repo defines (optics-style behavioral modules+journeys, unify-kit-style numbered specs, ADR-style decision records, or none → bootstrap from kit templates). Use when the user says "/spec-it <one-liner>", "/spec-it" with no args, "draft a spec for ...", "turn this idea into an issue", "I want to add <feature>", "create an issue for this", or otherwise wants to start a new feature/fix/process change from scratch. Also use proactively whenever the user describes a not-yet-tracked feature idea before `/work-issue` would have an issue number to consume. Strongly prefer this over filing an issue manually — it grounds the spec in research and enforces the project's spec discipline.
unifylabs-dev/unify-kit · ★ 0 · Code & Development · score 63

Install: claude install-skill unifylabs-dev/unify-kit

# /spec-it — Idea → spec + GitHub issue (front-door to /work-issue) Take a raw feature idea and turn it into a properly-shaped GitHub issue with an embedded draft spec, ready for `/work-issue <N>` to implement. The skill is **generic across projects** — it reads each target repo's conventions at runtime and adapts. `unify-kit` is the canonical source of spec/template conventions; this skill ships in the `unifylabs-workflow` plugin and runs anywhere the plugin is installed. **Invocation:** - `/spec-it "<one-line idea>"` — start with a seed sentence - `/spec-it` — start with no argument; first turn captures the idea - `/spec-it --quick "<paragraph>"` — minimize the brainstorm dialog when the user already has a clear write-up **What `/spec-it` produces:** 1. A draft spec in the target repo's spec format — embedded in the issue body so it ships with code in the eventual `/work-issue` PR (per the "specs ship in the same PR as code" rule). Exception: when invoked inside a repo that lands pre-implementation specs on master (e.g. unify-kit itself), the spec commits to a `spec/<slug>` branch + PR — see Phase 9. 2. A GitHub issue filled per the target repo's issue template — ACs in checkbox format, "Spec sections affected", scope, type, design notes, and any flagged unify-kit propagation note. 3. Optionally: a parallel unify-kit issue or PR when the feature introduces a generalizable pattern worth absorbing back into the kit. 4. A handoff line: `▶ Next: /work-issue <N>`. **Both cod