Spec Lite Chorus

spec-lite — durable local spec + per-change synced docs (dsh plugin)

A shared sub-procedure for the Chorus stage skills (proposal-chorus, develop-chorus, yolo-chorus) — the lightweight spec mode, modelled on superpowers (a durable spec that lives on, plus per-effort artifacts): one durable local spec per capability (<slug>/spec.md, edited in place, never synced — git history is its 留痕), plus one dated folder per change effort (<slug>/<YYYY-MM-DD>-<change-slug>/ of Chorus-typed docs — prd.md, … — that are mirrored 1:1 into persistent Chorus Documents). No new CLI, MCP tool, backend, or schema — mirroring reuses the existing document tools.

Tool namespace: Chorus MCP tools are exposed under a mcp__chorus__ prefix on dsh — prepend it when invoking the MCP tools directly (see chorus). Document-mirror calls do NOT go through the MCP harness — they go through the chorus CLI (chorus mcp call, preferred) or the package-local chorus-mcp-call.mjs wrapper resolved into $CHORUS_MCP_CALL (fallback), which talk to the Chorus MCP endpoint over HTTP with your API key. See openspec-aware-chorus §2 / §3.6 for the exact contract (same transport, same halt-on-error helper).

Mode (how you got here)

The spec mode is computed by the chorus-dsh bundle at plugin load (resolveSpecMode, the TS mirror of the canonical bash resolver), not by you — the bundle publishes it as the CHORUS_SPEC_MODE environment variable and injects a ## Spec Mode section into your first-step context stating the resolved value. You are here because it resolved to lite; if ## Spec Mode (or CHORUS_SPEC_MODE) says anything else, this skill is a no-op — return to the caller. (For the record, the rule: an explicit CHORUS_SPEC_MODE wins, else OpenSpec when usable, else lite.)

The durable local spec — <slug>/spec.md

.chorus/specs/<slug>/spec.md — <slug> (kebab-case) names a capability/feature, not one change. This is the single, cumulative, human-readable "current truth" of the capability: edited in place by every change, never mirrored to Chorus, carries no Chorus ids. Minimal frontmatter only (slug, title, status: draft|active|done, created), then plain prose — ## Intent, ## Requirements (prose + - [ ] acceptance points, no SHALL/scenario grammar), ## Non-goals. Start from the inline durable spec.md template below. Its git history is the whole record — no changelog section, no Chorus round-trip. This file NEVER enters the mirror loop.

status describes the capability, not a single change: active while any change is in flight, done when the current change delivers and none is open. A new change against a done capability reopens it to active, back to done on delivery.

Template — the durable spec.md

---
slug: <kebab-case-capability>
title: <Capability title>
status: draft            # draft | active | done
created: <YYYY-MM-DD>
---

## Intent
<what this capability is for, in prose>

## Requirements
<prose, no SHALL/scenario grammar>
- [ ] <acceptance point>

## Non-goals
- <explicitly out of scope>

Per-change dated folders — <slug>/<YYYY-MM-DD>-<change-slug>/

Each change effort is one dated folder directly under <slug>/ (no changes/ wrapper), e.g. .chorus/specs/<slug>/2026-09-08-add-export/. Date + slug so same-day changes don't collide and folders sort by date. It holds the Chorus-typed docs for THAT change — one file per Document type:

These files ARE synced — each maps to one persistent Chorus Document of its type. Their frontmatter carries the sync ids proposalUuid and documentUuid (the type is implied by the filename). Start from the inline dated-folder document template below. A different change to the same capability is a different dated folder. The current change's folder is edited and re-mirrored throughout its effort (until delivery); only previously-delivered dated folders are left frozen — you don't reach back and rewrite a past change.

Two files named spec.md, different roles. The durable <slug>/spec.md (local only, no ids) is NOT the same as a per-change spec-type doc, which would live at <slug>/<date>-<slug>/spec.md (synced, carries ids). Prefer prd.md as the per-change primary doc to avoid the confusion.

Template — a dated-folder document

The document type is implied by the filename (prd.md → prd, tech_design.md → tech_design, …), NOT a frontmatter key.

---
title: <Document title as it appears in Chorus>
proposalUuid: <uuid>      # written on first mirror
documentUuid:             # empty until the draft materializes on approval
---

# <Document title>
<body — this file's bytes are the source of truth for the Chorus Document>