/spec-compound

name: spec-compound
description: Document a recently solved problem or durable project vocabulary in docs/solutions/ or CONCEPTS.md. Use when capturing a learning after work.
argument-hint: "[optional: brief context] [mode:headless] "

spec-compound

Document a recently solved problem through role-based research; use parallel subagents only when dispatch is explicitly authorized and callable, otherwise run the same roles inline or serially.

Purpose

Captures problem solutions while context is fresh, creating structured documentation in `docs/solutions/` with YAML frontmatter for searchability and future reference. Authorized dispatch can parallelize read-only research; correctness does not depend on it.

**Why "compound"?** Each documented solution compounds your team's knowledge. The first time you solve a problem takes research. Document it, and the next occurrence takes minutes. Knowledge compounds.

Workflow Contract Summary

• **输入：** 一个最近解决且已有可回源验证的单一问题，或该问题带来的 durable project vocabulary。
• **输出：** `docs/solutions/` 下带 provenance、适用范围与失效条件的 learning，以及必要时对 `CONCEPTS.md` 的局部补充。
• **硬出口：** 问题尚未解决、验证证据不足、一次请求包含多个独立 learning、目标 repo/source owner 不明确，或 promotion gate 不满足时不得写入 durable knowledge。
• **权威：** 当前 source/test/log 和已验证 outcome 决定可沉淀事实；LLM 判断复用价值；只有 orchestrator 可写知识资产，dispatch 不授予 mutation。
• **消费者：** 后续 `spec-plan`、`spec-work`、`spec-debug`、`spec-code-review` 与项目维护者。

Usage

spec-compound                            # Document the most recent fix
spec-compound [brief context]            # Provide additional context hint
spec-compound mode:headless              # Non-interactive run for automations
spec-compound mode:headless [context]    # Non-interactive run with context hint

**One learning per run.** The workflow's grounding, overlap detection, and cross-referencing all assume a single solved problem. When a session produced multiple distinct learnings, run the skill once per learning, sequentially — each run grounds fresh against the tree. Do not batch several learnings through one run and stitch cross-references between the drafts afterward; drafting-context numbering ("Learning 3") leaking into written docs is the failure this rule prevents.

CONCEPTS.md bootstrap requests

If invoked specifically to create or bootstrap `CONCEPTS.md` from scratch rather than to document a solved problem, do not run the normal phases — `spec-compound` populates `CONCEPTS.md` only as a side effect of documenting a real learning (it seeds the *learning's area*, not the whole repo; see Phase 2.4). Repo-wide concept-map creation is `spec-compound-refresh`'s job. Redirect a standalone bootstrap request to `spec-compound-refresh` (which asks whether to build the concept map or run a refresh cycle), then exit.

Mode Detection

Check the invocation arguments supplied by the current host for the exact `mode:headless` token. Tokens starting with `mode:` are flags, not context — strip only recognized mode tokens while preserving the remainder, quoted paths, and token order before treating it as the brief context hint.

| Mode | When | Behavior | |------|------|----------| | **Interactive** (default) | No mode token present | Auto-pick Full vs Lightweight and report the choice; run the Full-mode session-history probe only with explicit restricted-read authorization; prompt for Discoverability Check consent; end with a plain summary (no "What's next?" menu) | | **Headless** | `mode:headless` in arguments | No blocking questions. Run **Full mode without session history**. Report discoverability gaps without editing instruction files. Skip Phase 2.46 optional candidate enhancement. End with a structured terminal report — no "What's next?" menu. |

Headless mode is intended for automations and skill-to-skill invocation where no human is present to answer questions. The doc itself is identical to what an interactive Full run would produce — classification work (track, category, overlap) follows the same rules and writes nothing extra into the artifact. Once detected, headless mode applies for the entire run.

Pre-resolved context

**Git branch (pre-resolved):** !`git rev-parse --abbrev-ref HEAD`

If the line above resolved to a plain branch name (like `feat/my-branch`), use it in Phase 1 session-history filtering so the orchestrator does not waste a turn deriving it. If it still contains a backtick command string, shows an error, or is empty, derive the branch at runtime.

**Repo root (pre-resolved):** !`git rev-parse --show-toplevel`

If the line above resolved to an absolute path, use it as the session-history repo filter in Phase 1. If it still contains a backtick command string, shows an error, or is empty, derive the repo root at runtime with the shell tool (`git rev-parse --show-toplevel`, falling back to the working directory outside a git repo).

Support Files

These files are the durable contract for the workflow. Read them on-demand at the step that needs them — do not bulk-load at skill start.

• `references/schema.yaml` — canonical frontmatter fields and enum values (read when validating YAML)
• `references/yaml-schema.md` — category mapping from problem_type to directory (read when classifying)
• `references/concepts-vocabulary.md` — CONCEPTS.md format and inclusion rules (read in Phase 2.4 when domain terms surface)
• `references/agents/session-historian.md` — skill-local synthesis prompt for optional session-history compounding context (read only when explicit restricted-read authorization exists and the relevance gate escalates)
• `references/grounding-validation.md` — grounding-validation protocol: flag adjudication rules and the semantic validator prompt (read in Phase 2.45)
• `assets/resolution-template.md` — section structure for new docs (read when assembling)
• `scripts/session-history/` — session discovery and extraction scripts copied into this skill so session-history support does not depend on the bundled session-history support
• `script