Openspec Aware Chorus

OpenSpec-aware Authoring (dsh plugin)

This skill is a shared sub-procedure invoked by the Chorus stage skills (proposal, develop, yolo) whenever the resolved spec mode is a usable OpenSpec CLI setup. It is one of the modes the chorus-dsh bundle resolves at load:

• Activates when the resolved spec mode is a usable OpenSpec (see §1): CHORUS_SPEC_MODE=openspec or unset, and CHORUS_OPENSPEC_MODE not off, an openspec/ directory at the project root, and the openspec CLI on PATH.
• Otherwise the calling skill follows the resolved CHORUS_SPEC_MODE — spec-lite (the default when OpenSpec isn't usable) or free-form (=off). This skill is then a no-op.

See also — spec-lite-chorus (the lightweight fallback): OpenSpec (this skill) stays the default whenever it is usable. When OpenSpec is absent or disabled — or CHORUS_SPEC_MODE=lite — the mode resolves to spec-lite: a durable local .chorus/specs/<slug>/spec.md (never synced) + per-change dated folders <slug>/<YYYY-MM-DD>-<change-slug>/ of Chorus-typed docs mirrored 1:1 into Chorus via the same --arg-file transport. See the spec-lite-chorus skill.

Tool namespace: Chorus MCP tools are exposed under a mcp__chorus__ prefix on dsh (e.g. mcp__chorus__chorus_pm_create_proposal). Bare names are used in prose for readability — prepend mcp__chorus__ when invoking the MCP tools directly. Document-mirror calls do NOT go through the MCP harness at all — they go through the chorus CLI (chorus mcp call, preferred) or the package-local chorus-mcp-call.mjs wrapper (fallback) (see §2 Rule 1), which talk to the Chorus MCP endpoint over HTTP using your API key, independent of the mcp__chorus__ namespacing.

§1. Detection — read the mode the bundle already resolved

dsh difference: the Claude Code plugin resolves the spec mode in a SessionStart hook. dsh has no SessionStart hook, but the chorus-dsh bundle resolves the mode once at plugin load (resolveSpecMode, the single source of truth — the TS mirror of the canonical bash resolver) and both (a) injects a ## Spec Mode block into your first-step context and (b) publishes CHORUS_SPEC_MODE + CHORUS_OPENSPEC_ACTIVE to the process environment, before the daemon-origin gate, so interactive and daemon-woken sessions inherit it. Consume that value — do NOT re-run detection and do NOT hand-roll an OpenSpec-only check.

The bundle marks OpenSpec active (a CHORUS_OPENSPEC_ACTIVE=1 line + CHORUS_SPEC_MODE=openspec) only when CHORUS_SPEC_MODE is openspec or unset, and all three of these hold:

1. CHORUS_OPENSPEC_MODE is not set to off (explicit opt-out wins).
2. The project root contains an openspec/ directory (i.e. someone ran openspec init here).
3. The openspec CLI is on PATH.

Both signals (2) and (3) are required because the OpenSpec authoring path needs the working directory and the CLI — having one without the other leaves the workflow unrunnable. If signal (2) holds but (3) does not, the bundle's ## Spec Mode note carries an install hint (npm i -g @fission-ai/openspec); pass it through if asked rather than silently choosing another mode.

How to read the value

Look for the ## Spec Mode section near the top of your context:

## Spec Mode

CHORUS_SPEC_MODE=openspec (default — openspec/ directory + openspec CLI both present)

CHORUS_OPENSPEC_ACTIVE=1 (openspec/ directory + openspec CLI both present)

or (resolved to lite / off — no CHORUS_OPENSPEC_ACTIVE=1 line):

## Spec Mode

CHORUS_SPEC_MODE=lite (default — OpenSpec not usable: no openspec/ directory at /path/to/repo/openspec)

Branch:

• CHORUS_OPENSPEC_ACTIVE=1 line present (equivalently the CHORUS_OPENSPEC_ACTIVE env var is 1) → follow §3 (OpenSpec authoring).
• No CHORUS_OPENSPEC_ACTIVE=1 → this skill is a no-op; return to the caller, which follows the resolved CHORUS_SPEC_MODE (spec-lite — see the spec-lite-chorus skill — or free-form when =off). Do not scaffold openspec/changes/. Do not add the slug line to the proposal description.

Manual fallback (context genuinely absent)

If you were spawned mid-session without the ## Spec Mode context, read the environment variables the bundle published — CHORUS_OPENSPEC_ACTIVE (1 ⇒ §3) and CHORUS_SPEC_MODE (lite/off ⇒ no-op, caller follows that mode). Never hand-roll an OpenSpec-only three-check that hard-codes "else free-form" — that ignores CHORUS_SPEC_MODE and mis-routes a lite repo to free-form. Only if both env vars are genuinely unset (a broken/older bundle) resolve the full mode yourself: an explicit CHORUS_SPEC_MODE (lite/openspec/off) wins; otherwise OpenSpec is active iff CHORUS_OPENSPEC_MODE ≠ off and an openspec/ dir is present and openspec --version succeeds, else the mode is spec-lite (never free-form-by-default).

# Last-resort resolution when NEITHER CHORUS_OPENSPEC_ACTIVE nor CHORUS_SPEC_MODE
# was published (broken bundle). PROJECT_DIR defaults to $PWD (dsh exports no CLAUDE_PROJECT_DIR).
PROJECT_DIR="${PWD}"
case "${CHORUS_SPEC_MODE:-}" in
  openspec|"") : ;;                       # may be OpenSpec — probe below
  lite|off) echo "no-op: follow CHORUS_SPEC_MODE=$CHORUS_SPEC_MODE"; return 0 2>/dev/null || exit 0 ;;
esac
if [ "${CHORUS_OPENSPEC_MODE:-}" != "off" ] && [ -d "${PROJECT_DIR}/openspec" ] && openspec --version >/dev/null 2>&1; then
  RESOLVED_OPENSPEC_ACTIVE=1              # follow §3
else
  RESOLVED_OPENSPEC_ACTIVE=0             # no-op; caller follows spec-lite (default), NOT free-form
fi
echo "RESOLVED_OPENSPEC_ACTIVE=$RESOLVED_OPENSPEC_ACTIVE"

§2. ⛔ Two non-negotiable rules

Both are enforced at review time. Both have caused incidents in past releases.

Rule 1 — Fill content from the file (CLI preferred, bash-wrapper fallback); never re-type document content from agent output

Document/draft mirror calls (chorus_pm_add_document_draft, chorus_pm_update_document_draft, chorus_pm_update_document) MUST fill the content field from the local file's bytes, never from a hand-typed body. Calling these tools directly from the agent's MCP harness with a hand-typed content field is a protocol violation for OpenSpec mode and will fail review. Use whichever transport is available, preferred first:

• Primary — the chorus CLI: chorus mcp call <tool_name> '<json-without-content>' --arg-file content=<file>. --arg-file content=<path> reads the file's raw bytes and injects them as the JSON content string, byte-exact — the CLI's built-in replacement for json_encode_file, so no helper is needed. chorus mcp call reads the same CHORUS_URL / CHORUS_API_KEY from the dsh process environment. See §3.6. Requires chorus >= 0.17.0 (the chorus mcp subcommand was added then; an older CLI errors with "unknown command"); on any version or unknown-command failure, upgrade with npm install -g @chorus-aidlc/chorus.
• Fallback — the package-local chorus-mcp-call.mjs wrapper ($CHORUS_MCP_CALL), when chorus is not on PATH: build $PAYLOAD with the json_encode_file helper and call "$CHORUS_MCP_CALL" <tool_name> "$PAYLOAD" (availability note below). Defined in the §3.6 fallback block.

New to the chorus CLI? See the chorus-cli skill for install, configuring agents (chorus agents add|remove|list), the connection env vars, and chorus mcp basics.

Acting identity — which agent the call acts as. chorus mcp call resolves the agent from, in order: CHORUS_AGENT_PROFILE (a name or UUID) → CHORUS_URL + CHORUS_API_KEY in the environment → the single agent configured in ~/.chorus/daemon.json. A daemon-woken session already has CHORUS_AGENT_PROFILE set. If a mirror call fails with Multiple agents … specify --agent (several agents configured and no profile/creds in the env), pass your own identity explicitly: chorus mcp call <tool> … --agent <your-agentUuid> — your UUID is in your chorus_checkin result, and chorus agents lists every configured name/UUID.

Reasons (they apply to both paths):

1. Token cost. Re-typing a multi-thousand-line markdown body through the LLM burns input + output tokens for every draft. Both the CLI's --arg-file and the fallback's json_encode_file (§3.6, Node JSON.stringify) stream the file's bytes into the JSON string — content never enters LLM context. A typical 3-doc proposal mirror costs roughly zero content-tokens this way; via direct MCP with a re-typed body it routinely costs 20k+.
2. Byte-equality. A file-fill path (CLI --arg-file, or the fallback's JSON.stringify of the file's UTF-8 bytes) is a byte-faithful encoder: backslashes, quotes, newlines, code-fence content, zero-width chars all survive. LLM re-emission has a non-zero failure rate on long markdown — table alignment drifts, fence escapes get "fixed", long URLs wrap. The byte-equality guarantee (modulo trailing \n) holds only on a file-fill path, never on LLM re-emission.
3. Single source of truth. With a file-fill mirror, the local openspec/changes/<slug>/*.md is authoritative and Chorus is a mirror. With agent re-typing, authority splits between local file and whatever the LLM happened to output — a future diff cannot tell which one is correct.

Wrapper availability on dsh (fallback path). When you fall back to the wrapper, the npm bundle publishes its path in CHORUS_MCP_CALL at plugin load. Validate it before authoring:

if [ -z "${CHORUS_MCP_CALL:-}" ] || [ ! -x "$CHORUS_MCP_CALL" ]; then
  echo "ERROR: OpenSpec mirroring requires the package-local CHORUS_MCP_CALL wrapper; reload the Chorus dsh bundle." >&2
  exit 1
fi

The wrapper reads CHORUS_URL and CHORUS_API_KEY from the dsh process environment (so does chorus mcp call). If both chorus and the wrapper are missing, halt visibly. Do not reproduce it ad hoc and do not retype document content through the model.

Rule 2 — Halt on error via chorus_check_response

Every wrapper call must check three signals: wrapper exit code, "error": in body, empty body. Bare RC=$? is insufficient — the wrapper exits 0 on HTTP 401 (auth failure) with empty body, so a single-signal check silently misses the most common runtime failure. See §6 for the helper definition.

§3. OpenSpec mode authoring

3.1 Pick a slug

openspec/changes/<slug>/ is the local change folder. The slug must be:

• kebab-case (add-export-csv, not addExportCsv or add_export_csv),
• derived from the source Idea title,
• unique within openspec/changes/.

Record it for later steps:

SLUG="add-export-csv"

3.2 Scaffold the change folder

openspec new change "$SLUG" --description "<one-line idea summary>"

This creates openspec/changes/$SLUG/ with README.md and .openspec.yaml. Then author by hand:

Use openspec instructions <artifact> --change "$SLUG" (artifacts: proposal, specs, design, tasks) for templates.

3.3 Spec file shape (verified against openspec instructions specs)

A delta spec lists one or more block headers — ## ADDED Requirements, ## MODIFIED Requirements, ## REMOVED Requirements, ## RENAMED Requirements — and within each, ### Requirement: entries. Mix freely in the same file; only include the blocks you actually need.

## ADDED Requirements

Append a brand-new Requirement to the long-term spec.

## ADDED Requirements

### Requirement: <name>
<requirement text — use SHALL / MUST for normative behavior>

#### Scenario: <name>
- **WHEN** <condition>
- **THEN** <expected outcome>

## MODIFIED Requirements

Whole-block replacement, not merge. Whatever you write here completely replaces the existing same-named Requirement in the long-term spec — title, description, and all scenarios. Half-writing it deletes the rest.

## MODIFIED Requirements

### Requirement: <existing name>
<full updated requirement text>

#### Scenario: <name>
- **WHEN** <condition>
- **THEN** <expected outcome>

#### Scenario: <other name>
- **WHEN** <condition>
- **THEN** <expected outcome>

Always include every scenario you want the post-archive spec to have, even ones that were already present and unchanged.

## REMOVED Requirements

Delete a Requirement from the long-term spec. The block under the heading is just the requirement name(s) you're removing — no scenarios needed.

## REMOVED Requirements

### Requirement: <existing name>

## RENAMED Requirements

Rename a Requirement's title. Body and scenarios are preserved as-is in the long-term spec; use MODIFIED instead if you need to change anything besides the title.

## RENAMED Requirements

### Requirement: <old name> -> <new name>

Critical formatting rules (verified):

• Scenarios MUST use exactly 4 hashtags (#### Scenario:). 3 hashtags or a bullet list silently fail validation.
• Every ### Requirement: under ADDED or MODIFIED MUST have at least one #### Scenario:.
• MODIFIED blocks MUST include the full updated content — they overwrite, not patch.
• Use SHALL / MUST for normative requirements; avoid should / may.
• The merge into openspec/specs/<capability>/spec.md happens at openspec archive time (§3.9), not at proposal time. While the proposal is in flight, Chorus only sees the delta file as one spec Document — there is no half-merged state for the skill to reason about.

Optional:

openspec validate "$SLUG"

3.4 Filling the content field byte-exact

The document content must be inserted byte-for-byte from the local file — never re-typed by the LLM. Two mechanisms, preferred first:

• Primary — chorus mcp call … --arg-file content=<path> (§3.6). The CLI reads the file's raw bytes and injects them as the JSON content string. This is the byte-faithful replacement for json_encode_file, so on the CLI path no helper is needed — pass the base JSON without a content field and let --arg-file fill it.
• Fallback — json_encode_file (defined in the §3.6 fallback block, used only when chorus is not on PATH). It encodes the file into a byte-faithful JSON string with Node's JSON.stringify — Node is guaranteed present under dsh (it is the harness runtime), so no jq is required.

Round-trip: the Chorus backend appends a single \n to draft content on write, so server content is byte-equal modulo a trailing newline. Reviewers diffing local file vs server should ignore that one byte.

3.5 Create the proposal container with the slug provenance line

Use the regular chorus_pm_create_proposal MCP tool (no wrapper required for this single call — the description is short, the LLM-emitted version is fine). The description must carry exactly one line:

OpenSpec change slug: <slug>

• on its own line (no other text on that line),
• literal prefix OpenSpec change slug: (capital O, capital S, single space after colon),
• no trailing punctuation,
• value matches the slug passed to openspec new change.

This line is machine-grep-able by future runs of this skill and by the §3.9 archive trigger.