Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →chorus-aidlc/spec-lite
Lightweight, Chorus-native local specs for Chorus PM workflows in Pi — 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
Passed 16 of 20 test cases with the skill, and 6 of 20 without it.
and 15 more in the full report
11 fixed5 passed either way3 still failing1 broke3 errored
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
For our billing capability (`billing`), we are starting a change on September 15, 2026 to add stripe webhooks. Should the per-change PRD be saved in `.chorus/specs/billing/changes/2026-09-15-stripe-webhooks/prd.md` or `.chorus/specs/billing/2026-09-15-stripe-webhooks/prd.md`?
| Checked | Without skill | With skill |
|---|---|---|
| Saves the change PRD directly under .chorus/specs/billing/2026-09-15-stripe-webhooks/prd.md | Missed | Passed |
| Omits the changes subfolder wrapper from the file path | 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 audit trail), 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 Chorus Hermes plugin's pre_llm_call session-start check-in
(spec_mode.py), not by you — the ## Spec Mode section of your injected 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 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.