sunrain520/spec-first/spec-compound

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.

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
• scripts/validate-frontmatter.py — frontmatter parser-safety validator plus the opt-in --promotion exit gate for provenance/invalidation (run against the private candidate in Phase 2 step 6 through the existence guard documented there; resolves via the loaded skill directory anchor SKILL_DIR, with a manual-checklist fallback elsewhere)
• scripts/validate-doc-claims.py — mechanical claims validator: cited paths, commit SHAs, relative links, dangling drafting scaffold (run in Phase 2.45 via the SKILL_DIR anchor)

When spawning subagents, pass the relevant file contents into the task prompt so they have the contract without needing cross-skill paths.

Dispatch Authorization Boundary

在派发 repo profiler、research role、session-history synthesizer、semantic validator 或 specialized reviewer 前，记录：

worker_dispatch_authorization: authorized | missing
capability_probe: not_applicable | attempted | unavailable
worker_dispatch_capability: available | missing | unknown
worker_context_isolation: isolated | inherited | unknown
worker_model_override: supported | unsupported | unknown
worker_bounded_parallelism: supported | unsupported | unknown

workflow invocation does not authorize dispatch。Full/headless mode、上下文预算、scratch directory、权限设置或 prompt asset 存在都不构成授权。只有当前用户或可见 upstream handoff 明确请求 subagent、delegated work、persona 或 parallel work 时才可派发。缺授权时不得探测 tool schema，固定为 capability_probe: not_applicable + worker_dispatch_capability: unknown，依次 inline 或 serial 执行相同 role prompts 并记录 dispatch_authorization_missing。只有授权后才把 current-session registry/schema 作为 provider_untrusted evidence 检查：确认缺失时记录 subagent_capability_missing；surface 不可用、schema 不完整或候选不唯一时记录 worker_capability_unproven，均使用同一 fallback。隔离、模型覆盖和有界并发只取 live facts；required isolation 未满足时保持依赖 gate 打开，model unknown 时继承，parallelism unknown 时串行。记录 worker_dispatch_outcome。Fallback 保留 Context Analyzer、Solution Extractor、Related Docs Finder 等角色合同，但不得声称 independent subagent、fresh-context 或 parallel coverage。无论哪种路径，只有 orchestrator 可以写 docs/solutions/、CONCEPTS.md、instruction files 或任何 tracked path。

Execution Strategy

spec-compound does not ask the user which mode to run. Mode depends on context budget the agent can observe. Cross-session history is different: reading private session stores is a restricted-read boundary, so the workflow probes it only when the current user or visible upstream handoff explicitly authorizes that read; it never infers authorization from a compound request, Full mode, local file access, or tool availability. Missing authorization skips the probe with restricted_read_authorization_missing rather than opening another question. The only interactive prompt in the normal workflow is the Discoverability Check consent, because that one edits a tracked instruction file.

Mode selection (Full vs Lightweight) — decide it, don't ask it.

• Default to Full: the complete workflow (research, cross-referencing, overlap detection, grounding validation). This is the right choice for essentially every documented learning — its token cost is small next to the engineering work that produced the learning and is dwarfed by the value of a doc that compounds.
• Choose Lightweight (single-pass, no subagents — see Lightweight Mode) only when the learning is low-risk, bounded, source-grounded, and already backed by verification evidence, and either the session is near its context limit or the fix is trivial enough that cross-referencing would add nothing. Context pressure alone never waives promotion obligations. A learning is high-risk when a wrong or stale claim could materially weaken security/authorization, data integrity, migration/release safety, privacy, compliance, or irreversible mutation boundaries. High-risk learnings use Full mode; if the remaining context cannot support Full mode, leave a handoff or emit Documentation skipped instead of writing durable knowledge.
• State the chosen mode and a one-line reason as the first line of the completion output (e.g., "Ran Full mode." / "Ran Lightweight mode — session context was tight."). If Lightweight was the wrong call for the user's taste, re-running is a rare, cheap correction — cheaper than taxing every run with a prompt.

In headless mode, skip mode selection entirely and run Full Mode with session history disabled (Phase 1 step 4 omitted). Headless does not elevate dispatch authority; when the package-local boundary is not satisfied, proceed through the serial inline Full fallback.

Session history — an authorization-gated probe in Full mode. When explicit restricted-read authorization exists, Full mode runs the cheap discovery+metadata probe (Phase 1 step 4) and escalates to extraction+synthesis only when the probe surfaces genuinely relevant candidate sessions. Without that authorization, record restricted_read_authorization_missing and continue without session context; do not inspect session roots or tool schemas. Lightweight and headless modes skip session history entirely. There is no standalone session-history product surface; this support exists only inside the compounding workflow.

Full Mode

<critical_requirement> The primary deliverable is ONE file - the final documentation.