ce-babysit-pr
Babysits an open GitHub PR until merge-ready, first judging whether an old PR still belongs. Use when asked to watch a PR over…
Diagnosis loop for bugs and failing behavior. Use when asked to debug or fix failing or slow behavior.
Claude Code
$ npx -y skills add everyinc/compound-engineering-plugin --skill ce-debug --agent claude-code
Codex
$ npx skills add everyinc/compound-engineering-plugin --skill ce-debug -a codex -y
Cursor
$ npx skills add everyinc/compound-engineering-plugin --skill ce-debug -a cursor -y
Gemini CLI
$ npx skills add everyinc/compound-engineering-plugin --skill ce-debug -a gemini-cli -y
GitHub Copilot
$ npx skills add everyinc/compound-engineering-plugin --skill ce-debug -a github-copilot -y
OpenCode
$ npx skills add everyinc/compound-engineering-plugin --skill ce-debug -a opencode -y
Windsurf
$ npx skills add everyinc/compound-engineering-plugin --skill ce-debug -a windsurf -y
name: ce-debug description: "Diagnosis loop for bugs and failing behavior. Use when asked to debug or fix failing or slow behavior." argument-hint: "[issue reference, error message, test path, or description of broken behavior]"
Find the root cause of a failure, then — when the user chooses to — fix it with test-first discipline.
**Done when:** the causal chain from trigger to symptom is stated with no gaps and file:line evidence, and either a verified fix has been handed off (PR, commit, or the user's chosen stop) or a diagnosis-only summary has been delivered. **Escalate rather than persist:** 2-3 hypotheses exhausted without confirmation, or 3 failed fix attempts, means diagnose *why* instead of trying again — that is the smart escalation `references/investigate.md` describes. One hypothesis, one change at a time; changing several to see what helps is shotgun debugging.
`<bug_description>` is whatever this skill was invoked with — a failure description, a `mode:` token, or an issue reference (`#123`, `org/repo#123`, an issue URL) — from the user or from a calling skill (`ce-babysit-pr` / `lfg` in `mode:pipeline` pass the failing jobs and log tails; `lfg`'s defect route passes `mode:return-to-caller` and the user's own reference). Blank if nothing was provided.
Default is **interactive**: investigate, run the Phase 2 fix-choice gate, then the Phase 4 handoff.
**`mode:pipeline`** (set by an orchestrator such as `ce-babysit-pr` or `lfg`): run fully non-interactively and never call the blocking-question tool. Strip the token from `<bug_description>`, then **read `references/pipeline-mode.md` and follow it** — it overrides every "ask the user" point with a conservative default, replaces the Phase 2 fix-gate with "fix convergent bugs, defer divergent ones", and replaces the Phase 4 handoff with a structured return whose `status` is exactly one of `fixed-and-pushed | fixed-not-pushed | diagnosed-no-fix | flaky-infra | needs-human`. The caller branches on those exact spellings, so never rename, abbreviate, or add to them.
**`mode:return-to-caller`** (set by `lfg` on its defect route): run non-interactively, but the caller owns everything after the fix. Strip the token, then **read `references/return-to-caller.md` and follow it** — it keeps Phases 0-3 and the convergent-or-defer fix boundary, applies the Phase 3 branch rule so the fix lands on a feature branch, commits the fix-owned files without pushing, skips the post-fix polish and review steps, and returns a structured result whose `status` is exactly one of `fixed | diagnosed-no-fix | needs-human | blocked`. The same spelling rule applies.
Wherever this skill asks the user something, use the host's blocking question tool already in the current tool list (match by capability, not by a host-specific name). Presence in the current tool list is proof the tool exists; never call a user-facing question tool to discover whether it exists. If a matching tool is listed but unloaded, use the host's tool-discovery primitive to load that capability — do not search for another host's tool name. Fall back to numbered options on the host's chat surface only when no such tool is in the list or a real question call errors. Never silently skip the question, and never end a phase without a response.
Debugging surfaces raw output constantly — command results, captured payloads, log excerpts — and the harness may render a command's output the moment it runs, so check secrets when you construct the command, not afterward. Keep credentials in env vars rather than on the command line; when a command's output may carry a secret (verbose HTTP traces, dumped headers, config or environment prints), capture it to a file and surface only sanitized excerpts, writing `<REDACTED>` in place of each secret. No secret (credential, token, auth header, connection string) appears in anything shown, written, or committed. If sanitizing removes what the diagnosis needs, say so and ask the user rather than un-redacting.
Resolve `<root>` only when you first compose a `<root>/` path — a run that composes none skips this entirely.
<!-- ce-docs-root:start --> **Resolve the CE artifact root `<root>` before composing any artifact path.**
<!-- ce-docs-root:end -->
Five phases in order: **0 Triage -> 1 Investigate -> 2 Root Cause -> 3 Fix -> 4 Handoff.** Beyond Phase 0's trivial-bug fast-path there is no skipping and no complexity tiers. A hard bug spends longer in each phase; it does not enter fewer.
Give each file you read its own tool call, so its output comes back on its own, never several files in one command or one script. A read counts only when the whole file came back. Some hosts cut the middle out of a long tool output and leave a truncation marker in its place, so when a read comes back shortened, read the missing lines in smaller ranges before you act on that file.
**Read `references/investigate.md` now and follow it for Phases 0-2** — issue fetching, reproduction, environment sanity and the dirty-tree stash experiment, backward tracing, the tracker/PR-history search, hypothesis grounding, and the escalation table. Only the gates below are stated here.
**The issue of record.** If the user handed you a ticket or
AI skills that make each unit of engineering work easier than the last. Compound Engineering is a plugin of 37 skills for AI coding agents.
Babysits an open GitHub PR until merge-ready, first judging whether an old PR still belongs. Use when asked to watch a PR over…
Develop independent competing solutions to a defined brief, compare them, and synthesize a winning approach. Use when choosing…
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or…
Review a named diff or PR for bugs, regressions, tests, and standards. Use when asked to review code or when a shipping skill…
Commit, push, and open a PR. Use when asked to ship/open a PR, or for PR-description-only flows like writing, rewriting, or…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.