/spec-lite-chorus

name: spec-lite-chorus
description: Lightweight, Chorus-native local specs for Chorus PM workflows on dsh — a durable local spec `.chorus/specs/<slug>/spec.md` (one per capability/feature) edited in place and NEVER synced (git history is its record), plus one dated folder per change effort `.chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/` holding Chorus-typed docs (prd.md, tech_design.md, …) that ARE mirrored 1:1 into persistent Chorus Documents via `--arg-file`. The fallback when OpenSpec isn't in use; a low-token alternative to the heavier openspec-aware-chorus path. Read from proposal / develop / yolo when the spec mode resolves to `lite`.
license: AGPL-3.0
metadata:
  author: chorus
  version: "0.24.0"
  category: project-management
  mcp_server: 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:

| File | `Document.type` | Required? | |---|---|---| | `prd.md` | `prd` | **yes** — the primary per-change doc | | `tech_design.md` | `tech_design` | optional — the "how" | | `adr.md` / `guide.md` / `spec.md` | `adr` / `guide` / `spec` | optional |

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>

Flow (one change)

1. Confirm mode = `lite` (else no-op). 2. Create the dated folder `<slug>/<YYYY-MM-DD>-<c