Hidden Gems: Five Compound Engineering skills

The compound-engineering plugin ships 29 skills. Everyone knows the loop and /lfg. These five do their best work where nobody looks.

Every toolkit develops a fame gradient. The brainstorm-plan-work-review-compound loop gets the demos; /lfg gets the applause. Meanwhile five skills quietly close loops most teams don't even track as open: documents that lie, feedback that rots in Slack, review comments that linger, metrics that drift, and plans that ship broken. Here is where each one hides, and the mechanic inside it that earns a second look.

1. ce-doc-review: the review you already ran without noticing

Everyone reviews code. This skill reviews the documents that cause the code: requirements and plans, before a line exists, when a scope error costs a sentence to fix instead of a sprint.

You have probably used it without knowing. Every ce-plan run ends with a headless doc-review pass: safe fixes applied silently, judgment calls surfaced above the menu. The machinery underneath is a persona panel, the same architecture as code review but aimed at prose: coherence (does the document contradict itself), feasibility (can this be built as written), scope-guardian (does every abstraction earn its keep), and conditional lenses like security and adversarial that activate only when the document's content warrants them.

The part worth stealing is the confidence discipline. Findings carry one of five anchors (0, 25, 50, 75, 100), each tied to a behavioral criterion the reviewer must honestly self-apply, not a vibe. Anchors 0 and 25 never surface. Anchor 50 becomes an FYI. Only 75 and up may interrupt you, and 75 requires naming a concrete downstream consequence someone will actually hit. A finding that merely dislikes your prose has no path to your attention.

Reach for it directly when: a plan or spec feels off but you can't say where. /ce-doc-review docs/plans/whatever.md and let the panel say where.

2. ce-compound-refresh: the gardener of the memory

The compounding loop has a failure mode nobody budgets for: memory that only grows eventually lies. docs/solutions/ fills with learnings whose file paths went stale, whose advice got superseded, whose lessons merged into doctrine long ago. This skill audits the corpus against the current codebase and hands every doc one of five verdicts.

The five-outcome model (Keep, Update, Consolidate, Replace, Delete) is the whole philosophy: staleness is not a boolean. And the judgment boundary between the middle outcomes gets the sharpest line in the skill: "if you find yourself rewriting the solution section or changing what the learning recommends, stop; that is Replace, not Update."

Two mechanics protect it from overzealous cleanup. First, "delete, don't archive" is an explicit rule with an explicit justification: no _archived/ directory, because git history preserves every deleted file; that is the archive. Second, before any Delete, inbound citations get classified as decorative (safe to remove) or substantive (a load-bearing doc someone depends on, which forces Replace instead). A doc other documents lean on cannot silently vanish.

Reach for it when: a fresh learning contradicts an old one, or an area's docs predate a big refactor. Scope it: /ce-compound-refresh payments.

3. ce-sweep: the inbox that becomes a plan

Three days old, and already the most infrastructure-heavy skill in the plugin. The job: on a schedule, poll every configured feedback source (Slack channels, GitHub Issues, experimental email) for items since the last run, acknowledge them at the source, analyze attached recordings, verify that claimed fixes actually merged, and reconcile everything into one standing plan that ends every run with the same handoff line: /lfg docs/plans/feedback-sweep-plan.md.

What makes it a gem is how seriously it takes state. A deterministic script is the sole writer of the state file; the skill never hand-edits it. Every feedback item moves through a typed lifecycle (ingested, acknowledged, analyzed, in_plan, fix_pending, closed, and friends), and the strictest transition is the last one: a closed item is a claim that work shipped and was verified, so the engine holds it to proof. Closing requires three evidence fields (the fix ref, the verified merge SHA, a timestamp), and validation downgrades any closed item missing one back to fix_pending. The same auditability grammar as everywhere else in CE, applied to a Slack message.

Concurrency gets the same respect: a single-writer lease with TTL reclaim decides who owns the sweep, while a separate OS-level file lock decides who is writing at this instant, so a crashed run can be reclaimed without a live run's writes being clobbered. And a circuit breaker (default cap: 25 new items per source) stops a headless run from mass-acknowledging a flood it should have escalated.

Reach for it when: feedback triage is a recurring human chore. Set it up once interactively; cron the rest.

4. ce-optimize: the experiment loop with a lab notebook

Most optimization attempts are one agent making three guesses and keeping whichever felt fastest. This skill turns "make the metric better" into batched, parallel, disk-durable science: generate 10 to 30 hypotheses, run experiments in isolated worktrees, measure each against a baseline, keep what wins, revert what doesn't, repeat until the curve flattens.

Three mechanics elevate it. The metric itself is three-tiered: cheap degenerate gates reject broken solutions before scoring, an LLM-as-judge produces the actual optimized score (with stratified sampling so the judge sees representative work, not cherry-picked samples), and diagnostics get logged but never gated, a deliberate guard against optimizing a misleading proxy. Results obey a persistence discipline with mandatory numbered checkpoints, each one write-then-read-back verified, under the bluntest rule in the plugin: if you produce a results table in the conversation without writing those results to disk first, you have a bug. And batch evaluation goes beyond keep-the-winner: runner-up experiments that also improved get cherry-picked onto the new baseline, but only if they touched completely disjoint files, and the combination gets re-measured and kept only if it beats the winner alone. Promising-alone-but-harmful-together is a logged outcome, not a surprise.

Reach for it when: you can score the thing. Search relevance, build time, clustering quality, prompt output judged by a rubric. If a number exists, the loop can climb it.

5. ce-resolve-pr-feedback: one judge, many hands

PR review threads accumulate faster than anyone resolves them, and the failure modes of automating this are famous: an agent that meekly implements every bot nitpick, or one that argues with your tech lead. This skill splits the problem: judgment is centralized, labor is distributed.

The orchestrator alone fetches every unresolved thread and judges them together, which is what lets it catch things no per-thread agent could: a bot reviewer that is systematically wrong across five threads, or a finding that contradicts the PR's stated design intent. Fixer subagents receive only approved work; they implement, never judge. Every thread lands in a named verdict (fixed, fixed-differently, replied, not-addressing, declined, needs-human), each with its own reply shape posted back to GitHub.

Two calibration rules give it its character. The bias runs toward fixing: diverting from a fix requires a concrete tripwire ("I read the callers and this breaks X" qualifies; "I'm uneasy" does not). And escalation is expensive by design: a needs-human handoff must include analysis the user can read and decide on in under 30 seconds. The run ends self-verifying: re-fetch the PR's unresolved threads, and the result must be empty except for the intentionally open human ones.

Reach for it when: a PR has more than two review comments. Point it at the PR, or at one stubborn thread by URL.

The shape they share

Look at the five together and one design instinct repeats: each finds a loop that was silently open (a stale doc, an unacknowledged Slack thread, an unmeasured optimization, an unresolved comment, an unreviewed plan) and refuses to let it close without evidence. Verdicts over vibes, disk over memory, proof over claims. The famous skills build things; these five keep the building honest.

Grounded in the live repo, July 2026: the five skills' own SKILL.md files and reference schemas, read fresh this run.