
ce-compound
Document a solved problem as a durable repo learning. Use when verified work produced non-obvious reasoning absent from its final code, tests, or existing docs; avoid routine fixes whose artifacts already explain the lesson.
- Installs
- 3.7K
- Last 24h
- +10
- Trending rank
- #8640
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-compound- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads ce-compound automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
/ce-compound
Outcome: one qualifying solved problem is written as a durable learning under <root>/solutions/, grounded against the current tree, discoverable by the next agent.
Done: a qualifying doc is written or updated, its frontmatter and claims validated, vocabulary capture recorded, and the mode's completion report emitted; when no learning qualifies, nothing is written and the report says why.
One learning per run. A session that produced several gets several sequential runs, never one batched run. Read references/research.md; it explains what batching breaks.
Preconditions
Document only a problem that is solved and verified.
<!-- ce-durable-bar:start -->A learning earns its place only when it holds durable project reasoning that is not readily recoverable from the final code, tests, types, comments, or existing documentation, and losing it would plausibly cause recurrence, material risk, or substantial rediscovery. Apply this counterfactual: if the learning document disappeared, would a future engineer reading the final implementation still be likely to repeat the mistake or redo substantial investigation? Completion, effort, and diff size do not establish eligibility.
<!-- ce-durable-bar:end -->If the counterfactual fails, write nothing and report why. Judge this from the session rather than asking. An explicit invocation requests the judgment now but does not lower the bar.
An existing learning that became materially inaccurate or incomplete qualifies because leaving it would mislead. Update that learning instead of creating a duplicate.
ce-compound does not bootstrap CONCEPTS.md. It seeds the learning's own area as a side effect, never the whole repo. Send a standalone request to create or bootstrap that file to ce-compound-refresh, then exit.
Mode Detection
/ce-compound [brief context]
/ce-compound mode:non-interactive depth:lightweight [context]
/ce-compound mode:non-interactive depth:full [context]
Enter non-interactive mode when either holds: the arguments you were invoked with contain the mode:non-interactive token or its deprecated alias mode:headless, or the invocation makes non-interactive intent unmistakable, such as a caller or standing instruction asking to run ce-compound "headless", "non-interactively", "unattended", or "without prompts/questions". Both tokens together is not a conflict. Bare "automatically" or "auto-run" is not on its own a non-interactive signal: it speaks to invoking the skill, not to suppressing its prompts. An ambiguous or absent signal defaults to interactive. Tokens starting with mode: or depth: are flags, not context: strip them before treating the remainder as the brief context hint. Once detected, non-interactive mode applies for the entire run.
Depth is chosen only by an explicit token, only in non-interactive mode, and at most one depth token is accepted. depth:lightweight routes directly to Lightweight Mode. depth:full or no depth token enters Full Mode, including its automatic session-history probe. A non-interactive call carrying no depth token therefore behaves as it always has. Non-interactive lightweight asks no blocking questions and launches no subagents. If the invocation carries an unknown depth: token, multiple depth: tokens, or a depth: token without non-interactive intent, do not guess: emit the non-interactive failure report with the reason and end with Documentation skipped.
Non-interactive mode asks nothing. It asks no blocking question of any kind, in any phase, because a caller reaching this path has no human to answer one. Every non-interactive exit, including one taken before any phase runs, ends on a terminal signal a caller parses: Documentation complete, or Documentation skipped with the reason when no doc was written. Interactive mode asks only where the step's own reference says to, which is the Discoverability Check consent and, when several stale docs are in play, which refresh to run.
Artifact Root
Resolve <root> when you first compose a <root>/solutions/ path, and pass a subagent the resolved path rather than the config.
Resolve the CE artifact root <root> before composing any artifact path.
- Read
docs_rootfrom<repo-root>/.compound-engineering/config.yamlonly (<repo-root>=git rev-parse --show-toplevel). Do not read it fromconfig.local.yaml. Unset -><root>isdocs, exactly as before. - Validate a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under
.git/. Otherwise stop with an error namingdocs_rootand the value -- never fall back todocs. - Use
<root>as the sole artifact location: create it if absent, compose each path as<root>/<subdir>with this skill's own subdirectory, and never also readdocs.
Write boundary
Only the orchestrator writes product files. Phase 1 subagents write to per-run scratch only, and never touch <root>/, project instruction files, or any other tracked path.
The orchestrator writes the one learning under <root>/solutions/, plus two maintenance side effects that its own step describes: CONCEPTS.md during vocabulary capture, and — only in interactive Full mode after consent — a small discoverability line in a project instruction file. Two further writes exist only in interactive Full mode when the user selects them at the assembly destination step: a rule file inside a writable declared Compound Pack, and the packs: entry appended to .compound-engineering/config.yaml. Creating CONCEPTS.md when it is absent is expected rather than a violation. An instruction file is only ever edited, never created. Nothing else in the tree is written. Edits to other docs belong to ce-compound-refresh, which this skill recommends or invokes with a narrow scope but never stands in for.
Choosing the path
Read references/modes.md before step 1. An interactive run picks its own depth rather than asking the user, and that reference says why neither the depth choice nor session history is a question. Default to Full. Choose Lightweight only when the session is near its context limit.
Lightweight mode skips session history entirely; non-interactive Full runs the same automatic probe, which asks nothing and so preserves the non-interactive contract.
Full Mode
Run these in order. Each reference is a required read at the step that names it.
- Research — read
references/research.md. - Session history — read
references/session-history.md, and start it after dispatching the Related Docs Finder so it overlaps your drafting rather than serializing. Session history is the final Phase 1 input, not a workflow stop. When it returns, including with "no relevant prior sessions", go straight to assembly without pausing or summarizing. - Assembly and write — wait for every Phase 1 input, then read
references/assembly.md. - Refresh check and discoverability — read
references/refresh-and-discoverability.md. - Optional enhancement — read
references/enhancement.md. Interactive only. - Report — read
references/report.mdfor the report shape your mode must emit and how the skill ends.
Lightweight Mode replaces steps 1-6 with a single pass; read references/lightweight.md, which defines its own completion output for both modes.
FAQ
What does the ce-compound skill do?
Document a solved problem as a durable repo learning. Use when verified work produced non-obvious reasoning absent from its final code, tests, or existing docs; avoid routine fixes whose artifacts already explain the lesson.
How do I install ce-compound?
Run npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-compound in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/ce-compound/ (personal) or .claude/skills/ce-compound/ (project).
Which AI agents can use ce-compound?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is ce-compound safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains ce-compound?
It is published by everyinc in everyinc/compound-engineering-plugin. It has 3,678 recorded installs.
More from everyinc/compound-engineering-plugin
ce-brainstorm
everyinc/compound-engineering-plugin
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or scope what to build. Not for executing already-specified work. Use ce-pov for a verdict on adopting a named external technology.
ce-code-review
everyinc/compound-engineering-plugin
Review a named diff or PR for bugs, regressions, tests, and standards. Use when asked to review code or when a shipping skill needs a review receipt. Use when asked to apply this review's findings locally. Use ce-resolve-pr-feedback for feedback already left on a PR.
ce-plan
everyinc/compound-engineering-plugin
Create structured plans for multi-step work, including software and non-software tasks. Use when asked to plan, break down implementation, plan from requirements, or deepen an existing plan; prefer ce-brainstorm for exploratory framing.
ce-doc-review
everyinc/compound-engineering-plugin
Review requirements, plans, or specs with role-specific lenses. Use when the user wants to improve an existing planning document.
ce-work
everyinc/compound-engineering-plugin
Execute a plan or concrete work prompt end-to-end. Use when implementing from a plan document, a spec path, or a clear build request; use ce-debug for open-ended bugs. Use when an outer orchestrator needs implementation and local verification only, without the shipping tail.
lfg
everyinc/compound-engineering-plugin
Take a request all the way to done, hands-off, through the right Compound Engineering skills. A code change ends as an open pull request, pushed without stopping. Use only when the user explicitly asks for autonomous end-to-end work or invokes lfg directly. Use ce-plan, ce-work, ce-debug, or ce-commit-push-pr for work the user reviews step by step.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work