SKILL.md
skills/configure-ecc/SKILL.md
name: configure-ecc
description: Guide ECC installation, update, or reconfiguration from inside Claude Code, Codex, or Kimi while respecting each harness's real plugin, scope, and hook capabilities.
metadata:
origin: ECCConfigure Everything Claude Code
Run a conversational wizard inside the current harness. Inventory first, collect only supported choices, preview, confirm once, apply non-interactively, verify, and show the welcome only after success. Never clone ECC into a temporary directory or copy plugin components by hand.
For a human-operated terminal, the canonical entry points are ecc setup and npx ecc-universal setup. Inside a harness, use the explicit non-interactive commands below instead.
Route by the current harness
- In Claude Code, use the full scope-and-hook wizard below.
- In Codex, use Codex's native plugin lifecycle. Do not offer Claude scopes or
map ECC's four Claude hook profiles onto Codex.
- In Kimi, install the project surface under
./.kimi-code. Kimi does not
provide ECC's Claude lifecycle-hook profiles.
- If the harness is uncertain, state the detected evidence and ask which
harness to configure before running a mutating command.
This skill is a post-install reconfiguration path. It cannot intercept or replace a provider's built-in first-install UI.
Claude Code: run the full conversational wizard
1. Inventory without changing anything
Run both commands and summarize the installed ECC scope, enabled state, and marketplace source:
claude plugin list --json
claude plugin marketplace list --json
Treat a single existing ecc@ecc installation as a reconfiguration. Do not interpret Claude's provider-owned "Open home page" control as installation evidence. Stop and report the recovery returned by setup for multiple ECC scopes, a legacy/manual install, malformed settings, or a marketplace collision; never guess which state to delete.
2. Collect exactly two choices
Ask exactly one scope question and require one value:
user | project | localuseris global for this user.projectis shared through repository settings.localis private to the current project.
Visually mark only the selected scope as selected or installing. If the user chooses a different scope from a single existing install, describe it as a scope migration and include --move-scope in the commands below.
Ask exactly one hook-mode question and require one value:
off | minimal | standard | strictoffkeeps skills and commands but disables ECC hook automation.minimalenables the lightest lifecycle and safety automation.standardbalances quality and safety automation.strictenables the strongest checks and reminders.
Hook preference is personal Claude plugin configuration; it does not follow the selected install scope.
3. Preview and confirm once
Prefer the plugin-bundled setup script. Substitute the two selected values and include --move-scope only for a scope migration:
node "$CLAUDE_PLUGIN_ROOT/scripts/setup.js" --mode claude-plugin \
--scope <scope> --hooks <hooks> [--move-scope] --dry-run --json
If $CLAUDE_PLUGIN_ROOT is unavailable, use the published npm package:
npx --yes --package ecc-universal ecc setup --mode claude-plugin \
--scope <scope> --hooks <hooks> [--move-scope] --dry-run --json
Show exactly one confirmation summary containing the planned action, one scope, one hook mode, marketplace action, and any source-to-destination migration. Ask one yes/no question. Do not run a bare interactive ecc setup through a harness shell tool because that shell is commonly non-TTY.
4. Apply the explicit choices
After confirmation, rerun the same route without --dry-run. Keep every choice explicit and request JSON so success can be checked deterministically:
node "$CLAUDE_PLUGIN_ROOT/scripts/setup.js" --mode claude-plugin \
--scope <scope> --hooks <hooks> [--move-scope] --yes --json
Fallback:
npx --yes --package ecc-universal ecc setup --mode claude-plugin \
--scope <scope> --hooks <hooks> [--move-scope] --yes --json
5. Verify, then render the welcome
Require a zero exit status and a setup result whose scope and hooks equal the selected values. Then independently run:
claude plugin list --json
Continue only when exactly one enabled ecc@ecc entry exists at the selected scope. When $CLAUDE_PLUGIN_ROOT is available, pass the successful setup action (installed, updated, migrated, resumed, or already-migrated) to the bundled renderer:
Before invoking it, require the provider-reported version to match ECC_VERSION_PATTERN from scripts/lib/terminal-welcome.js. Reject unexpected version text instead of interpolating it into a shell command.
node -e 'const { renderTerminalWelcome } = require(process.env.CLAUDE_PLUGIN_ROOT + "/scripts/lib/terminal-welcome"); process.stdout.write(renderTerminalWelcome({ action: process.argv[1], version: process.argv[2], color: process.stdout.isTTY }));' "<action>" "<installed-version>"
Render the welcome exactly once. On failure, dry-run, cancellation, a scope or hook mismatch, or unverifiable state, do not render it; report the error and recovery instead. After verified changes, tell the user to run /reload-plugins or restart Claude Code.
Codex: use the native plugin lifecycle
Inventory with codex plugin marketplace list --json and codex plugin list --available --json. Codex's native plugin command has no Claude-style user | project | local selector. Codex native plugins do support provider-specific hooks, but Codex requires explicit trust for them. Let Codex show that trust decision; do not ask the Claude four-profile hook question or claim those profiles map to Codex.
If the ECC marketplace is missing, add it. Otherwise refresh its snapshot:
codex plugin marketplace add affaan-m/ECC
codex plugin marketplace upgrade ecc --json
Ask for one confirmation, then install or idempotently refresh the installed cache and verify it:
codex plugin add ecc@ecc --json
codex plugin list --json
Continue only when the JSON reports ECC installed and provides its installedPath. Then render the verified bundle's welcome:
Use only the exact absolute installedPath returned by Codex JSON. Reject control characters and require the installed version to match ECC_VERSION_PATTERN. Invoke node directly with this argument array; this is a tool API invocation, not a shell command:
["<installedPath>/scripts/welcome.js", "--action", "configured", "--version", "<installed-version>"]
If the current harness cannot invoke an executable with a separate argument array, skip the welcome. Never construct a shell command from Codex JSON values.
Never claim that Claude's off | minimal | standard | strict profiles were applied to Codex.
Kimi: install the project surface
State the capability summary before confirmation: destination ./.kimi-code; hooks=unsupported for ECC lifecycle hooks. Do not ask the Claude scope or hook-mode questions. Preview first:
npx --yes --package ecc-universal ecc install --profile core --target kimi --dry-run
Show one confirmation for that project destination, then apply the identical command without --dry-run. Verify with:
npx --yes --package ecc-universal ecc doctor --target kimi
Only after doctor succeeds and the installed instructions and skills remain inside ./.kimi-code, render:
npx --yes --package ecc-universal ecc welcome --action configured
Do not claim that Kimi installed or configured ECC lifecycle hooks.