CtrlK
BlogDocsLog inGet started
Tessl Logo

configure-ecc

Guide ECC installation, update, or reconfiguration from inside Claude Code, Codex, or Kimi while respecting each harness's real plugin, scope, and hook capabilities.

65

Quality

79%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/configure-ecc/SKILL.md
SKILL.md
Quality
Evals
Security

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.

Repository
affaan-m/ECC
Last updated
First committed

Also appears in

tdg-personal/configure-ecc
Modified

on Apr 24, 2026

jbvc/configure-ecc
Modified

on Mar 31, 2026

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.