configure-ecc

Configure 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 | local
• user is global for this user.
• project is shared through repository settings.
• local is 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 | strict
• off keeps skills and commands but disables ECC hook automation.
• minimal enables the lightest lifecycle and safety automation.
• standard balances quality and safety automation.
• strict enables 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.