Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →chorus-aidlc/chorus-spec-lite
Lightweight, Chorus-native local specs for Chorus PM workflows in Kiro CLI — 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 alternati
Passed 19 of 20 test cases with the skill, and 6 of 20 without it.
and 11 more in the full report
13 fixed6 passed either way1 still failing0 broke3 errored
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are creating a proposal container in Chorus for a change effort located at .chorus/specs/analytics/2026-05-10-charts/. How should the reference line in the proposal's description field be formatted?
| Checked | Without skill | With skill |
|---|---|---|
| Formats the locator line as Spec-lite: .chorus/specs/analytics/2026-05-10-charts/ on its own line without trailing punctuation | Missed | Passed |
The instructions your model reads when the skill loads.
A shared sub-procedure for the Chorus stage skills (proposal, develop, yolo) — 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.
The spec mode is computed by the agentSpawn hook (bin/resolve-spec-mode.sh), not by you — the
## Spec Mode section of your context states the resolved CHORUS_SPEC_MODE. You are here because it
resolved to lite; if it is anything else, this skill is a no-op — return to the caller. (For the
record, the hook's rule: an explicit CHORUS_SPEC_MODE wins, else OpenSpec when usable, else lite.)
<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.
spec.md---
slug: <kebab-case-capability>
title: <Capability title>
status: draft # draft | active | done
created: <YYYY-MM-DD>
---
test cases passed, vs 6 / 20 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.