dotfiles/dot_config/opencode/skills/ce-setup/SKILL.md
Diagnose and configure compound-engineering environment. Checks CLI dependencies, plugin version, and repo-local config. Offers guided installation for missing tools. Use when troubleshooting missing tools, verifying setup, or before onboarding.
npx skillsauth add pkking/dotfiles ce-setupInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Ask the user 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_user in Gemini, ask_user in Pi (requires the pi-ask-user extension). Fall back to presenting each question as a numbered list in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip or auto-configure. For multiSelect questions, accept comma-separated numbers (e.g. 1, 3).
Interactive setup for compound-engineering — diagnoses environment health, cleans obsolete repo-local CE config, and helps configure required tools. Review agent selection is handled automatically by ce-code-review; project-specific review guidance belongs in CLAUDE.md or AGENTS.md.
Detect the installed compound-engineering plugin version by reading the plugin metadata or manifest. This is platform-specific -- use whatever mechanism is available (e.g., reading plugin.json from the plugin root or cache directory). 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.
Before running the script, display: "Compound Engineering -- checking your environment..."
Run the bundled check script. Do not perform manual dependency checks -- the script handles all CLI tools, agent skills, repo-local CE file checks, and .gitignore guidance in one pass.
bash scripts/check-health --version VERSION
Or without version if Step 1 could not determine it:
bash scripts/check-health
Script reference: scripts/check-health
Display the script's output to the user.
Plugin root (pre-resolved): !echo "${CLAUDE_PLUGIN_ROOT}"
If the line above resolved to an absolute path (starts with / and contains no ${), this is a Claude Code session and /ce-update is available. Anything else — empty, the literal ${CLAUDE_PLUGIN_ROOT} token, or an unresolved command string like echo "${CLAUDE_PLUGIN_ROOT}" left in place by a non-Claude harness that doesn't process ! pre-resolution — means this is not Claude Code; omit any /ce-update references from output.
After the diagnostic report, check whether:
compound-engineering.local.md is present and needs cleanup.compound-engineering/config.local.yaml does not exist or is not safely gitignored.compound-engineering/config.local.example.yaml is missing or outdatedIf everything is installed, no repo-local cleanup is needed, and .compound-engineering/config.local.yaml already exists and is gitignored, display the tool and skill list and completion message. Parse the tool and skill names from the script output and list each with a green circle. Omit the Skills line if the Skills section is absent from the script output:
✅ Compound Engineering setup complete
Tools: 🟢 agent-browser 🟢 gh 🟢 jq 🟢 vhs 🟢 silicon 🟢 ffmpeg 🟢 ast-grep
Skills: 🟢 ast-grep
Config: ✅
Run /ce-setup anytime to re-check.
If this is a Claude Code session (the Plugin root above resolved to a non-empty path), append to the message: "Run /ce-update to grab the latest plugin version."
Stop here.
Otherwise proceed to Phase 2 to resolve any issues. Handle repo-local cleanup (Step 4) first, then config bootstrapping (Step 5), then missing dependencies (Step 6).
Resolve the repository root (git rev-parse --show-toplevel). If compound-engineering.local.md exists at the repo root, explain that it is obsolete because review-agent selection is automatic and CE now uses .compound-engineering/config.local.yaml for any surviving machine-local state. Ask whether to delete it now. Use the repo-root path when deleting.
Resolve the repository root (git rev-parse --show-toplevel). All paths below are relative to the repo root, not the current working directory.
Example file (always refresh): Copy references/config-template.yaml to <repo-root>/.compound-engineering/config.local.example.yaml, creating the directory if needed. This file is committed to the repo and always overwritten with the latest template so teammates can see available settings.
Local config (create once): If .compound-engineering/config.local.yaml does not exist, ask whether to create it:
Set up a local config file for this project?
This saves your Compound Engineering preferences (like which tools to use and how workflows behave).
Everything starts commented out -- you only enable what you need.
1. Yes, create it (Recommended)
2. No thanks
If the user approves, copy references/config-template.yaml to <repo-root>/.compound-engineering/config.local.yaml. If .compound-engineering/config.local.yaml is not already covered by .gitignore, offer to add the entry:
.compound-engineering/*.local.yaml
If the local config already exists, check whether it is safely gitignored. If not, offer to add the .gitignore entry as above.
Present the missing tools and skills using a multiSelect question with all items pre-selected. Use the install commands and URLs from the script's diagnostic output. Group items under Tools: and Skills: so the user can see which runtime each item targets; omit a group whose items are all installed.
The following items are missing. Select which to install:
(All items are pre-selected)
Tools:
[x] agent-browser - Browser automation for testing and screenshots
[x] gh - GitHub CLI for issues and PRs
[x] jq - JSON processor
[x] vhs (charmbracelet/vhs) - Create GIFs from CLI output
[x] silicon (Aloxaf/silicon) - Generate code screenshots
[x] ffmpeg - Video processing for feature demos
[x] ast-grep - Structural code search using AST patterns
Skills:
[x] ast-grep - Agent skill for structural code search with ast-grep
Only show items that are actually missing. Omit installed ones.
For each selected dependency, in order:
Show the install command (from the diagnostic output) and ask for approval:
Install agent-browser?
Command: CI=true npm install -g agent-browser --no-audit --no-fund --loglevel=error && agent-browser install && npx skills add https://github.com/vercel-labs/agent-browser --skill agent-browser -g -y
1. Run this command
2. Skip - I'll install it manually
If approved: Run the install command using a shell execution tool. After the command completes, verify installation:
command -v agent-browser).npx --yes skills list --global --json | jq -r '.[].name' | grep -qx <skill-name> when npx is available; otherwise fall back to checking that ~/.config/opencode/skills/<skill-name>, ~/.agents/skills/<skill-name>, or ~/.codex/skills/<skill-name> exists (file, directory, or symlink).If verification succeeds: Report success.
If verification fails or install errors: Display the project URL as fallback and continue to the next dependency.
Display a brief summary:
✅ Compound Engineering setup complete
Installed: agent-browser, gh, jq
Skipped: rtk
Run /ce-setup anytime to re-check.
If this is a Claude Code session (per platform detection in Step 3), append: "Run /ce-update to grab the latest plugin version."
testing
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
data-ai
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
development
Run the full autonomous engineering pipeline end-to-end (plan, work, code review, test, commit, push, open PR, watch CI, fix CI failures until green). Use only when the user explicitly requests hands-off execution of a software task and provides a feature description; do not auto-route casual conversation here.
development
Create an isolated git worktree for parallel feature work or PR review. Use when starting work that should not disturb the current checkout, or when `ce-work` or `ce-code-review` offers a worktree option.