Agent Skills: Compound Engineering Setup

Check Compound Engineering health and repo-local config.

UncategorizedID: EveryInc/compound-engineering-plugin/ce-setup

Install this agent skill to your local

pnpm dlx add-skill https://github.com/EveryInc/compound-engineering-plugin/tree/HEAD/skills/ce-setup

Skill Files

Browse the full folder contents for ce-setup.

Download Skill

Loading file tree…

skills/ce-setup/SKILL.md

Skill Metadata

Name
ce-setup
Description
"Check Compound Engineering health and repo-local config."

Compound Engineering Setup

Interaction Method

Ask each question below using the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (requires the pi-ask-user extension). Fall back to a numbered list in chat only when no blocking tool exists in the harness or the call errors. Never silently skip or auto-configure.

ce-setup is a lightweight health check and repo-local config helper. It does not bulk-install every optional dependency. Missing tools are reported as optional capabilities so the user can install only the workflows they use.

Artifact Root Resolution

Every Compound Engineering skill that writes or reads an artifact directory (solutions, plans, ideation, and the other CE-owned trees) resolves its root through the rule below. ce-setup carries the canonical statement and reports the resolved root so an operator can confirm where artifacts land before running other skills.

<!-- ce-docs-root:start -->

Resolve the CE artifact root <root> before composing any artifact path.

  • Read docs_root from <repo-root>/.compound-engineering/config.yaml only (<repo-root> = git rev-parse --show-toplevel). Do not read it from config.local.yaml. Unset -> <root> is docs, 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 naming docs_root and the value -- never fall back to docs.
  • 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 read docs.
<!-- ce-docs-root:end -->

Phase 1: Diagnose

Step 1: Determine Plugin Version

Detect the installed compound-engineering plugin version by reading the plugin metadata or manifest when the platform exposes it. If the version cannot be determined, skip this step.

If a version is found, pass it to the check script via --version. Otherwise omit the flag.

Step 2: Run the Health Check

Before running the script, display:

Compound Engineering -- checking your environment...

Run the bundled check script. Set SKILL_DIR to the absolute directory you loaded this ce-setup SKILL.md from — the Bash tool's CWD is the user's project, not the skill dir, so a bare scripts/ path will not resolve:

SKILL_DIR="<absolute path of the directory containing this SKILL.md>";
if [ -f "$SKILL_DIR/scripts/check-health" ]; then bash "$SKILL_DIR/scripts/check-health" --version VERSION; else echo "Bundled health script not found at $SKILL_DIR/scripts/check-health; run the inline checks from ce-setup instead."; fi

Use the same command without --version VERSION if Step 1 could not determine a version.

If the script is unavailable, perform the inline equivalent:

  1. Check optional tools with command -v: agent-browser, gh, jq, ast-grep, ffmpeg.
  2. If inside a git repo, resolve the repo root with git rev-parse --show-toplevel.
  3. Check for obsolete compound-engineering.local.md at the repo root.
  4. Check whether .compound-engineering/config.yaml exists.
  5. Check whether .compound-engineering/config.local.yaml exists and, if it does, whether git check-ignore -q .compound-engineering/config.local.yaml succeeds.
  6. Compare .compound-engineering/config.example.yaml with references/config-template.yaml when the template is readable; otherwise report that the example refresh must be done manually.

Display the diagnostic output to the user. Missing optional tools are not setup failures. The health report includes the resolved artifact root and which config layer supplied it (per Artifact Root Resolution above); surface that line so the operator can confirm where CE artifacts will be written. Missing config.yaml is a reported absence, not a project issue.

Step 3: Decide Whether Fixes Are Needed

User-runnable invocation rendering. In setup summaries, default to /ce-setup; use $ce-setup only when the active host is Codex or explicitly documents dollar-prefixed skill invocation. On oh-my-pi (omp), use /skill:ce-setup. Render only the invocation as inline code and output one form only.

Always continue to Phase 2 after the health report when this checkout is a git repository, including when project_issues is 0. Phase 2 always refreshes the example and always offers to create config.yaml when that file is missing.

If the health report says Not inside a git repository, skip Phase 2 and go to Phase 3. Repo-local files cannot be created or refreshed without a repo root.

Also remediate these project issues when the report names them:

  • obsolete compound-engineering.local.md
  • .compound-engineering/config.local.yaml exists but is not safely gitignored
  • .compound-engineering/config.example.yaml is missing or outdated
  • the health report marks the ce-work skill implementation engine unavailable or invalid, detects retired scalar routing keys, or reports malformed dormant work_engine_preferences
  • the health report marks docs_root invalid (Invalid docs_root ...) — CE artifacts will not be written until it is fixed

If optional tools are missing, do not offer a bulk install. The diagnostic already printed the relevant install command or project URL. Say: "Install optional tools only for the workflows you use."

Phase 2: Fix Repo-Local Issues

Resolve the repository root (git rev-parse --show-toplevel). All paths below are relative to the repo root, not the current working directory.

Step 4: Remove Obsolete Local Config

If compound-engineering.local.md exists at the repo root, explain that it is obsolete because review-agent selection is automatic and surviving machine-local settings now live in .compound-engineering/config.local.yaml (the optional override). Team defaults live in config.yaml.

Ask whether to delete it now. Delete only if the user approves.

Step 5: Refresh Example Config

Copy references/config-template.yaml to <repo-root>/.compound-engineering/config.example.yaml, creating the directory if needed. This file is committed to the repo and should always reflect the latest available settings.

If leftover <repo-root>/.compound-engineering/config.local.example.yaml remains after the new example exists, treat it as stale generated example (not user config) and remove it with trash (never rm).

If the bundled template cannot be located by the current platform, print the source template path that failed and tell the user the example config could not be refreshed automatically.

Step 6: Create Repo Config If Missing

If .compound-engineering/config.yaml does not exist, ask — even when health is otherwise green:

Set up a repo config file for this project?
This creates .compound-engineering/config.yaml with optional Compound Engineering team defaults.
Everything starts commented out -- you only enable what you need.
It does not create config.local.yaml.

1. Yes, create it
2. No thanks

If the user approves, copy references/config-template.yaml to <repo-root>/.compound-engineering/config.yaml. Never overwrite an existing config.yaml or config.local.yaml.

If config.local.yaml already exists, leave it. After creating (or if both files already exist), name ordinary local keys that would shadow the new team file. If local still has docs_root, say it is ignored and offer to move it into config.yaml.

Do not create config.local.yaml.

Step 6a: Repair Invalid CE Work Preferences

When the health report marks the CE Work implementation engine unavailable or invalid, detects retired scalar routing keys, or reports malformed dormant work_engine_preferences, do not guess the intended recipients. Explain the exact reported problem, derive a valid ordered work_engine_preferences block from the user's stated harness/model order (or remove malformed dormant preferences and use work_engine_mode: off when they want native-by-default), remove any retired scalar routing keys, and show the complete replacement block. Edit the layer that supplied the failing value. If the bad ordinary key is only in config.yaml, edit that file after preview. Do not hide a broken team value behind a new local override. Preserve every unrelated setting. Re-run the health check and require it to report either native or the intended normalized ordered list before setup is complete.

Step 6b: Repair Invalid docs_root

When the health report marks docs_root invalid, explain the exact reason it gave (absolute, escapes the repo, .. traversal, repo root, .git/, or a non-directory component) and the consequence: CE artifacts will not be written until it is fixed, because docs_root fails closed rather than silently falling back to docs. docs_root is read only from .compound-engineering/config.yaml. A docs_root in config.local.yaml is ignored — if local still has one, say so and offer to move it into config.yaml. Offer to either correct the tracked value to a valid repo-relative directory the user names, or remove the bad docs_root key from config.yaml. Removing it reaches the default docs. Edit only those keys after the user approves; preserve every unrelated setting. Re-run the health check and require it to report a resolved artifact root before setup is complete.

Step 7: Ensure Local Config Is Gitignored

If .compound-engineering/config.local.yaml exists and is not covered by .gitignore, offer to add:

.compound-engineering/*.local.yaml

Append the entry to the repo-root .gitignore only if the user approves. Do not overwrite unrelated .gitignore content.

Step 8: Offer To Gitignore CE Scratch Space

Skills that keep local scratch write it under .context/compound-engineering/. Probe coverage with git -C <repo root> check-ignore -q .context/compound-engineering/ — with the trailing slash, so an existing directory-only rule counts before the directory exists, and anchored to the repo root, since that is where the entry is appended — and when it is not covered, offer to add:

.context/compound-engineering/

Append the entry to the repo-root .gitignore only if the user approves. Do not overwrite unrelated .gitignore content.

Unlike Step 7 this does not wait for the path to exist. The skill about to write there offers the same entry at its first write, so a repository that never uses one of those skills never needs the line — adding it here only means that prompt never has to fire.

Phase 3: Summary

Display a brief summary:

✅ Compound Engineering setup complete

Fixed:     <repo-local fixes applied, or none>
Skipped:   <repo-local fixes declined, or none>
Optional:  <missing optional tools, or all available>

Run `<rendered invocation>` anytime to re-check.