{ "markdown": "

\n \"ECC\n

\n\n

\n \n \n \n \"GitHub\n \n \n \n \n \n \"Star\n \n \n

\n\n

\n Language:\n English |\n Português (Brasil) |\n 简体中文 |\n 繁體中文 |\n 日本語 |\n 한국어 |\n Türkçe |\n Русский |\n Tiếng Việt |\n ไทย |\n Deutsch |\n Español |\n Українська\n

\n\n

\n \"Discord\"\n \"Website\"\n \"GitHub\n \"MIT\n

\n\n

\n \"Stars\"\n \"Forks\"\n \"Contributors\"\n \"GitHub\n

\n\n

\n \"ecc-universal\n \"ecc-agentshield\n

\n\n

\n \"Shell\"\n \"TypeScript\"\n \"Python\"\n \"Go\"\n \"Java\"\n \"Perl\"\n \"Markdown\"\n

\n\n> [!WARNING]\n> **Official sources only.** Install ECC only from verified channels: the GitHub repository [github.com/affaan-m/ECC](https://github.com/affaan-m/ECC), the npm packages [`ecc-universal`](https://www.npmjs.com/package/ecc-universal) and [`ecc-agentshield`](https://www.npmjs.com/package/ecc-agentshield), the [GitHub App](https://github.com/apps/ecc-tools), the plugin slug `ecc@ecc`, and the project website [ecc.tools](https://ecc.tools). Third-party re-uploads and unofficial mirrors are not maintained or reviewed by the project and may contain malware.\n\n## Install with Claude Code\n\nUse the [guided setup](#install-ecc) or [native plugin commands](#claude-code-details). Both install the same `ecc@ecc` plugin. Choose one and do not stack a full manual Claude install on top.\n\n
\n\n\n\n\n\n\n\n
\n \n \"ECC
\n ECC Pro + GitHub App\n
\n Install free · Private repos from $19/seat/mo\n		\n \n \"\"
\n Sponsor ECC\n
\n Fund the open-source project\n		\n \n \"Discord\"
\n Community\n
\n Discord · Q&A · Show and Tell\n
\n\n
\n\n**OSS stays free.** This repo is MIT-licensed forever. ECC Pro is the hosted GitHub App for private repos. Sponsors and Pro subscribers fund the work. That's why a single maintainer ships weekly across 7 harnesses.\n\n
\n\nPartners & sponsors\n\n

\n \"CodeRabbit\"   \n \"Greptile\"   \n \"Atlas   \n \"Moonshot   \n \"Itô\n

\n\nCommunity sponsors: Mike Morgan · @jasonwu513 · @1anter · @massimotodaro · @meadmccabe\n\nBecome a Sponsor · Sponsor Tiers · Sponsorship Program\n\n
\n\n

Jump to install ↓

\n\n# ECC\n\nYour agent can write code, but ECC gives it a coordinated engineering system and toolbox: it plans before it builds, verifies changes with tests, reviews its own work from a fresh context, remembers what matters, and turns repeated wins into reusable skills and workflows.\n\n```text\nplan -> test -> implement -> review -> verify -> remember -> improve\n```\n\nInstead of rebuilding that process in every prompt, you install it once and make it part of how your agent works.\n\n> Optimize the context window. Persist everything else.\n\nECC is MIT-licensed open source. It works best with Claude Code today, has a supported Codex sync path, and provides capability-limited adapters for Cursor, OpenCode, Gemini, Zed, GitHub Copilot, Antigravity, Qwen, and other harnesses. See the [support status matrix](#platform-support) before assuming feature parity.\n\nAccess to 68 agents, 292 skills, and 94 legacy command shims, plus hooks, rules, memory, continuous learning, and AgentShield security scanning. The agents are specialized for planning, review, build repair, security, architecture, and domain work.\n\n| Included | Count | What it gives you |\n| ---------------- | ----------: | ------------------------------------------------------------------------------------ |\n| Agents | 68 agents | Planning, review, build repair, security, architecture, and domain work |\n| Skills | 292 skills | TDD, research, security, docs, frontend, data, ML, operations, and more |\n| Commands | 94 commands | Convenient entry points while ECC moves to a skills-first surface |\n| Hooks and memory | Runtime | Enforcement, session summaries, continuous learning, instincts, and context controls |\n| Rules | Selective | Always-loaded standards you choose by language or project |\n| AgentShield | Included | Scanning for prompts, hooks, MCP config, permissions, secrets, and agent files |\n\n

\n \n \n \n \"ECC\n \n \n

\n\n## Install ECC\n\n> [!IMPORTANT]\n> ECC 2.2 includes guided package setup for Claude Code, Codex, and Kimi Code.\n> The universal package requires Node.js 18 or newer. Claude plugin setup also\n> requires Git and Claude Code 2.1 or newer on `PATH`.\n\n### Recommended: universal guided setup\n\nFor Claude Code plugin setup, updates, scope changes, and hook-profile changes:\n\n```bash\nnpx ecc-universal@2.2.1 setup\n```\n\nIf npm reports a version or cache error, confirm the registry version before retrying:\n\n```bash\nnpm view ecc-universal version\n```\n\nECC 2.2 supports the same guided setup through modern package runners:\n\n| Package runner | Guided setup command |\n|---|---|\n| npm / npx | `npx ecc-universal@2.2.1 setup` |\n| pnpm | `pnpm dlx ecc-universal@2.2.1 setup` |\n| Yarn 2+ | `yarn dlx ecc-universal@2.2.1 setup` |\n| Bun | `bunx ecc-universal@2.2.1 setup` |\n\nThe examples select [the published ECC 2.2.1 release](https://www.npmjs.com/package/ecc-universal/v/2.2.1), matching this repository's release version. A version pin is not a security audit or an integrity check. Review the release source and registry integrity before running package code; use a reviewed checkout for unreleased changes.\n\nYarn Classic 1 does not provide `yarn dlx`; use `npx`, install the package globally, or upgrade Yarn for a temporary one-shot run.\n\nThe wizard inventories the official marketplace and every native Claude install scope before making changes, then installs, updates, or safely moves `ecc@ecc` to the scope you choose. Rerun the same command whenever you want to update ECC, change scope, or change its hook profile. This setup wizard currently configures the Claude Code plugin; use the multi-harness wizard below for Codex or Kimi Code.\n\nTo configure more than one coding agent in one reviewed flow, use the multi-harness wizard:\n\n```bash\nnpx ecc-universal@2.2.1 install --guided\n```\n\nIt lets you select any combination of Claude Code, Codex, and Kimi Code, shows each install channel and destination, preflights every selection before the first write, and asks for one final confirmation.\n\n| Harness | Guided install behavior |\n|---|---|\n| Claude Code | Native `ecc@ecc` plugin with one `user`, `project`, or `local` scope and an ECC hook profile |\n| Codex | Native Codex marketplace/plugin lifecycle; hook review and trust remain Codex-owned |\n| Kimi Code | Managed project files under `./.kimi-code`; ECC hooks, model/provider settings, and authentication are not configured |\n\nFor automation, make every provider-specific choice explicit:\n\n```bash\nnpx ecc-universal@2.2.1 install --guided \\\n --harness claude --harness codex --harness kimi \\\n --claude-scope local --claude-hooks standard \\\n --profile core --yes\n```\n\nVerify the native guided Codex path and managed Kimi path without writing first:\n\n```bash\nnpx ecc-universal@2.2.1 install --guided --harness codex --dry-run\nnpx ecc-universal@2.2.1 install --profile core --target kimi --dry-run\n```\n\nAdditional package-name commands are also available through the 2.2 alias:\n\n```bash\nnpx ecc-universal@2.2.1 consult \"security reviews\" --target claude\nnpx ecc-universal@2.2.1 install --profile minimal --target claude --with capability:machine-learning\nnpx ecc-universal@2.2.1 doctor --target kimi\n```\n\nDo not use `npx ecc-install --profile minimal --target claude`: `ecc-install` is a binary name inside `ecc-universal`, not a separately published npm package.\n\nECC also ships advanced managed adapters for `cursor`, `antigravity`, `gemini`, `opencode`, `codebuddy`, `joycode`, `qwen`, `zed`, `hermes`, and `openclaw`. Those targets still use their documented `ecc install --target ...` paths until each adapter has passed the guided collision, update, repair, and uninstall lifecycle matrix. Neither wizard silently installs into every detected harness.\n\n### Pick one path only (per harness)\n\nYou can use ECC with Claude Code, Codex, and other harnesses at the same time. Choose one install method for each harness:\n\n- **Recommended default:** run the guided Claude plugin setup above\n- **Also supported for Claude Code:** use the [native plugin commands](#claude-code-details)\n- **Available in release 2.2:** guided package setup for Claude Code, Codex, and Kimi Code\n- **Works:** Claude Code plugin + Codex native plugin\n- **Works:** Claude Code plugin + the legacy Codex sync flow\n- **Avoid:** Claude Code plugin + full Claude manual install\n- **Avoid:** Codex sync + Codex marketplace plugin\n\n**Do not stack install methods.** Installing ECC twice into the same harness can duplicate skills, commands, hooks, or configuration; installing it once into multiple harnesses does not.\n\nIf you already layered multiple installs and things look duplicated, skip straight to [Reset / Uninstall ECC](#reset--uninstall-ecc).\n\n**Install trouble?** Open the short [install or runtime problem form](https://github.com/affaan-m/ECC/issues/new?template=install-problem.yml), or run `ecc feedback`. ECC never uploads diagnostics automatically.\n\n### Claude Code details\n\nAlternatively, run Claude Code's native plugin commands inside Claude Code:\n\n```text\n/plugin marketplace add https://github.com/affaan-m/ECC\n/plugin install ecc@ecc\n```\n\nThe native path installs ECC's skills, agents, commands, and plugin-managed hooks. If you choose it, stop there. Do not also run a full manual install into Claude Code.\n\nClaude Code owns these built-in commands, including their errors when a marketplace, plugin, or conflicting scope already exists. ECC cannot intercept that parser. If either native command reports an existing install or scope conflict, use the 2.2 guided setup or resolve the conflicting Claude plugin scope before retrying; do not layer a manual install on top.\n\nAfter ECC is installed, `/ecc:configure-ecc` is the namespaced in-Claude reconfiguration skill. It delegates to the same safe setup flow, but it is available only after the plugin is installed and cannot replace Claude Code's built-in `/plugin` command during a first install.\n\nClaude Code plugins cannot distribute `rules`, so add only the rule packs you actually want:\n\n```bash\ngit clone https://github.com/affaan-m/ECC.git\ncd ECC\nmkdir -p ~/.claude/rules/ecc\ncp -R rules/common ~/.claude/rules/ecc/\ncp -R rules/typescript ~/.claude/rules/ecc/ # replace with your stack\n```\n\nStart with `rules/common` plus one language or framework pack you actually use. If you install the plugin, do not run `./install.sh --profile full` afterward.\n\n
\nPrefer settings.json? Add the marketplace declaratively\n\nAdd directly to your `~/.claude/settings.json`:\n\n```json\n{\n \"extraKnownMarketplaces\": {\n \"ecc\": {\n \"source\": {\n \"source\": \"github\",\n \"repo\": \"affaan-m/ECC\"\n }\n }\n },\n \"enabledPlugins\": {\n \"ecc@ecc\": true\n }\n}\n```\n\nThis gives you the same result as the two `/plugin` commands above.\n
\n\n
\nNaming + migration note (ecc@ecc, affaan-m/ECC, ecc-universal)\n\nECC has three public identifiers, and they are not interchangeable:\n\n- GitHub source repo: `affaan-m/ECC`\n- Claude marketplace/plugin identifier: `ecc@ecc`\n- npm package: `ecc-universal`\n\nThis is intentional. Anthropic marketplace/plugin installs are keyed by a canonical plugin identifier, so ECC uses `ecc@ecc` to keep tool names and slash-command namespaces short enough for strict Desktop/API validators. Older posts may still show the former long marketplace identifier; treat that as a legacy alias only. Separately, the npm package stayed on `ecc-universal`, so npm installs and marketplace installs intentionally use different names.\n\nnpm releases are cut per version tag, not per commit, so `ecc-universal` tracks releases (2.1, 2.2, ...) rather than every push to `main`. Install from git if you want the bleeding edge.\n\nIf your local Claude setup was wiped or reset, that does not mean you need to repurchase anything. Start with `node scripts/ecc.js list-installed`, then run `node scripts/ecc.js doctor` and `node scripts/ecc.js repair` before reinstalling. That usually restores ECC-managed files without rebuilding your setup.\n
\n\n### Codex App and CLI\n\nCurrent Codex releases can install ECC as a native repo-marketplace plugin. The marketplace entry uses the repository root so Codex's cache receives the manifest together with all referenced skills, MCP configuration, hook runtime, scripts, and assets:\n\n```bash\ncodex plugin marketplace add affaan-m/ECC\ncodex plugin add ecc@ecc\ncodex plugin list --json\nnode scripts/codex/check-plugin-cache.js\n```\n\nBoth add commands are idempotent. To refresh later, run `codex plugin marketplace upgrade ecc` followed by `codex plugin add ecc@ecc`. Codex stores one enabled plugin state in the active `CODEX_HOME`; it does not offer Claude's `user`, `project`, and `local` scopes. Its native hooks require an explicit trust decision and do not use Claude's four ECC hook profiles. Inside Codex, invoke `$configure-ecc` for the guided provider-aware flow.\n\nThe older `scripts/sync-ecc-to-codex.sh` path is a deprecated compatibility option for users who intentionally need copied and merged configuration in `~/.codex`; it is not required for the native plugin. New sync runs write an ownership manifest so cleanup can preserve modified user files. Run Codex once first so `~/.codex/config.toml` exists, then:\n\n```bash\ngit clone https://github.com/affaan-m/ECC.git\ncd ECC\nnpm install\nbash scripts/sync-ecc-to-codex.sh\n```\n\nTo inspect or remove that legacy layer without touching Codex conversations or native plugin caches:\n\n```bash\nnode scripts/ecc.js uninstall --legacy-codex-sync --dry-run\nnode scripts/ecc.js uninstall --legacy-codex-sync\n```\n\nPre-manifest installations are handled conservatively: ECC removes its marked `AGENTS.md` block but preserves copied files it cannot prove it owns and reports them for review.\n\nYou can also open the ECC repository directly in Codex for a project-local setup. Codex reads the root `AGENTS.md` and the trusted project configuration in `.codex/` without a global sync. Do not add the native marketplace plugin on top of the sync flow.\n\nFor repo navigation, surface ownership, and PR diff packet guidance, read the [Codex ECC Navigation Map](docs/CODEX-NAVIGATION-GUIDE.md). See the [.codex plugin notes](.codex-plugin/README.md) for native lifecycle details.\n\n### Other agents and editors\n\n
\nCursor, OpenCode, Gemini, Zed, Antigravity, Qwen, Hermes, OpenClaw, Kimi, CodeBuddy, JoyCode, Copilot\n\nClone ECC once, then choose the target that matches your harness:\n\n```bash\ngit clone https://github.com/affaan-m/ECC.git\ncd ECC\n```\n\n| Harness | Install or setup | Notes |\n|---|---|---|\n| Cursor | `./install.sh --profile minimal --target cursor` | Project-local `.cursor/` adapter |\n| OpenCode | `npm install && npm run build:opencode && ./install.sh --profile full --target opencode --enable-hooks` | Builds the plugin payload before the full install |\n| Gemini CLI | `./install.sh --profile minimal --target gemini` | Project-local `.gemini/` config |\n| Zed | `./install.sh --profile minimal --target zed` | Project-local `.zed/` adapter |\n| Antigravity | `./install.sh --profile minimal --target antigravity` | See the [Antigravity guide](docs/ANTIGRAVITY-GUIDE.md) |\n| Qwen CLI | `./install.sh --profile minimal --target qwen` | See the [Qwen guide](docs/QWEN-GUIDE.md) |\n| Hermes | `./install.sh --profile minimal --target hermes` | See the [Hermes setup guide](docs/HERMES-SETUP.md) |\n| OpenClaw | `./install.sh --profile minimal --target openclaw` | Managed home-directory install |\n| Kimi Code CLI | `./install.sh --profile minimal --target kimi` | Project-local `.kimi-code/` install · [Get Kimi Code](https://www.kimi.com/code?aff=ecc) |\n| CodeBuddy | `./install.sh --profile minimal --target codebuddy` | Project-local `.codebuddy/` install |\n| JoyCode | `./install.sh --profile minimal --target joycode` | Project-local `.joycode/` install |\n\nGitHub Copilot support is already included in this repository. `.github/copilot-instructions.md` provides the instruction layer, `.github/prompts/` contains the reusable `/plan`, `/tdd`, `/security-review`, `/build-fix`, and `/refactor` prompts, and `.vscode/settings.json` enables `chat.promptFiles`.\n\nFor a harness without a native ECC target, use the [manual adaptation guide](docs/MANUAL-ADAPTATION-GUIDE.md). It explains how to carry a small set of ECC skills and workflow instructions into chat-style tools without pretending hooks or native skill discovery are available.\n\nCursor installs agent definitions under `.cursor/agents/ecc-*.md`. Cursor-native loading behavior can vary by Cursor build. ECC does not install root `AGENTS.md` into `.cursor/`. The adapter keeps Cursor's context scoped to its native rules and agent surfaces.\n\nDeep per-harness notes (feature parity, hook adapters, limitations) live in [Platform Support](#platform-support) below.\n
\n\n## Advanced Install Options\n\n
\nLow-context install with no hook runtime\n\n### Low-context / no-hooks path\n\nUse this when you want ECC's rules, agents, commands, platform config, and core workflows without runtime hooks:\n\n```bash\nnpx ecc-universal@2.2.1 install --profile minimal --target claude\n```\n\nFrom a source checkout, the equivalent command is:\n\n```bash\n./install.sh --profile minimal --target claude\n```\n\nWindows:\n\n```powershell\n.\\install.ps1 --profile minimal --target claude\n```\n\nThis profile intentionally excludes `hooks-runtime`.\n\nClaude manual installs place each skill directly under `~/.claude/skills//` (or `.claude/skills//` for `claude-project`) so Claude Code can discover it. When upgrading an older ECC manual install, the installer migrates only nested `skills/ecc/` files recorded in ECC install-state. If a flat skill directory is user-owned, ECC preserves it, prints a conflict warning, and keeps any older managed copy tracked for a safe uninstall instead of overwriting user files.\n\nFor the normal core profile with hooks disabled:\n\n```bash\n./install.sh --profile core --without baseline:hooks --target claude\n./install.sh --profile core --no-hooks --target claude\n```\n\nAdd the hook runtime later only if you want it:\n\n```bash\n./install.sh --target claude --modules hooks-runtime --enable-hooks\n```\n\nAny install whose profile or modules would materialize the hook runtime requires\nan explicit decision. Without `--enable-hooks` or `--no-hooks`, the installer\nprints what the hooks can do and stops before writing anything. The guided\ninstaller (`ecc install --guided`) asks for this choice interactively.\n
\n\n
\nChoose only the components you need\n\n### Find the right components first\n\nAsk the packaged advisor which components match your work:\n\n```bash\nnode scripts/ecc.js consult \"security reviews\" --target claude\n```\n\nIt returns matching components, related profiles, and preview/install commands. Use the preview command before installing if you want to inspect the exact file plan.\n\nYou can also install explicit skills or capabilities:\n\n```bash\n./install.sh --target claude --skills tdd-workflow,security-review\nnode scripts/ecc.js install --profile minimal --target claude --with capability:machine-learning\n```\n\nManual component-by-component copying also works. Each component is fully independent:\n\n```bash\n# Just agents\ncp agents/*.md ~/.claude/agents/\n\n# Rules directories (common + language-specific)\nmkdir -p ~/.claude/rules/ecc\ncp -r rules/common ~/.claude/rules/ecc/\ncp -r rules/typescript ~/.claude/rules/ecc/ # pick your stack\n\n# Core/general skills only (Claude Code loads skills from direct children\n# of ~/.claude/skills; do not nest manual installs under ~/.claude/skills/ecc/)\nmkdir -p ~/.claude/skills\ncp -r .agents/skills/* ~/.claude/skills/\ncp -r skills/search-first ~/.claude/skills/\n\n# Optional: maintained slash-command compatibility during migration\nmkdir -p ~/.claude/commands\ncp commands/*.md ~/.claude/commands/\n```\n\nRetired shims live in `legacy-command-shims/`. Copy individual files from there only if you still need old names such as `/tdd`.\n
\n\n
\nProject-local rules instead of global rules\n\nUse project-local rules when ECC's standards should apply to one repository rather than every Claude Code session:\n\n```bash\ncd your-project\nmkdir -p .claude/rules/ecc\ncp -R /path/to/ECC/rules/common .claude/rules/ecc/\ncp -R /path/to/ECC/rules/typescript .claude/rules/ecc/\n```\n\nRules are always-loaded context, so begin with `common` and one pack for the stack you actually use. When copying rules manually, copy the whole language directory (for example `rules/common` or `rules/golang`), not the files inside it, so relative references keep working and filenames do not collide.\n
\n\n
\nFully manual Claude install\n\nUse this only when you are intentionally skipping the plugin path:\n\n```bash\ngit clone https://github.com/affaan-m/ECC.git\ncd ECC\n./install.sh --profile full\n```\n\nWindows:\n\n```powershell\ngit clone https://github.com/affaan-m/ECC.git\ncd ECC\n.\\install.ps1 --profile full\n```\n\nIf you choose this path, stop there. Do not also run `/plugin install`.\n\nFor hand-picked manual installs, Claude discovers skills as direct children of `~/.claude/skills/`; do not nest them under `~/.claude/skills/ecc/`.\n\n#### Install hooks\n\nDo not copy the raw repo `hooks/hooks.json` into `~/.claude/settings.json` or `~/.claude/hooks/hooks.json`. That file is plugin/repo-oriented; use the installer so hook command paths are rewritten correctly:\n\n```bash\nbash ./install.sh --target claude --modules hooks-runtime --enable-hooks\n```\n\nThat installs the hook scripts under `~/.claude/` and registers the resolved\nhook entries in `~/.claude/settings.json`. Existing user settings and hooks are\npreserved; ECC-owned entries are tracked by stable ID for idempotent updates\nand safe uninstall.\n\nIf you installed ECC via `/plugin install`, do not copy those hooks into `settings.json`. Claude Code v2.1+ already auto-loads plugin `hooks/hooks.json`, and duplicating them in `settings.json` causes duplicate execution and cross-platform hook conflicts.\n\nOn Windows, Claude's config root is `%USERPROFILE%\\.claude`; install the hook runtime with:\n\n```powershell\npwsh -File .\\install.ps1 --target claude --modules hooks-runtime --enable-hooks\n```\n\n#### Configure MCPs\n\nClaude plugin installs intentionally do not auto-enable ECC's bundled MCP server definitions. This avoids overlong plugin MCP tool names on strict third-party gateways while keeping manual MCP setup available.\n\nUse Claude Code's `/mcp` command or CLI-managed MCP setup for live Claude Code server changes; Claude Code persists those choices in `~/.claude.json`. For repo-local MCP access, copy desired MCP server definitions from `mcp-configs/mcp-servers.json` into a project-scoped `.mcp.json`.\n\nECC ships exactly one default connector (`chrome-devtools`); everything else is a skill wrapping a CLI/REST API or an opt-in catalog entry. The rule and the June 2026 audit that retired the previous six defaults live in [docs/MCP-CONNECTOR-POLICY.md](docs/MCP-CONNECTOR-POLICY.md).\n\nIf you already run your own copies of ECC-bundled MCPs, set:\n\n```bash\nexport ECC_DISABLED_MCPS=\"chrome-devtools\"\n```\n\nECC-managed install and Codex sync flows will skip or remove those bundled servers instead of re-adding duplicates. `ECC_DISABLED_MCPS` is an ECC install/sync filter, not a live Claude Code toggle.\n\n**Important:** Replace `YOUR_*_HERE` placeholders with your actual API keys.\n
\n\n
\nMulti-model commands require additional setup\n\n`multi-*` commands are **not** covered by the base plugin/rules install.\n\nTo use `/multi-plan`, `/multi-execute`, `/multi-backend`, `/multi-frontend`, and `/multi-workflow`, you must also install the `ccg-workflow` runtime. Choose and review an exact release using the [upstream CCG installation guide](https://github.com/fengshao1227/ccg-workflow#readme), then initialize that installed runtime. ECC does not bundle CCG or attest to a compatible, audited CCG release; this guide does not bootstrap an unspecified registry version.\n\nThat runtime provides the external dependencies these commands expect, including:\n\n- `~/.claude/bin/codeagent-wrapper`\n- `~/.claude/.ccg/prompts/*`\n\nWithout `ccg-workflow`, these `multi-*` commands will not run correctly.\n
\n\n
\nReset, repair, or uninstall\n\n### Reset / Uninstall ECC\n\nIf you installed from the universal package, run these commands from the same\nproject directory used for installation:\n\n```bash\nnpx ecc-universal@2.2.1 list-installed\nnpx ecc-universal@2.2.1 doctor\nnpx ecc-universal@2.2.1 repair\nnpx ecc-universal@2.2.1 uninstall --dry-run\nnpx ecc-universal@2.2.1 uninstall\n```\n\nFrom a source checkout, inspect the managed state before reinstalling:\n\n```bash\nnode scripts/ecc.js list-installed\nnode scripts/ecc.js doctor\nnode scripts/ecc.js repair\nnode scripts/ecc.js uninstall --dry-run\n```\n\nFor a direct source-checkout uninstall:\n\n```bash\nnode scripts/uninstall.js --dry-run\nnode scripts/uninstall.js\n```\n\nIf you are leaving, the uninstall command prints an optional [20-second feedback form](https://github.com/affaan-m/ECC/issues/new?template=quick-feedback.yml). It is a public GitHub issue, never blocks uninstall, and ECC does not upload diagnostics. You can also run `ecc feedback` at any time to see the problem, feedback, and feature routes.\n\nPlugin users should remove the plugin from Claude Code, then delete only the rule folders they manually copied and no longer want. ECC only removes files recorded in its install-state. It does not claim unrelated files in your harness directories.\n\nIf you stacked methods, clean up in this order:\n\n1. Remove the Claude Code plugin install.\n2. Run the ECC uninstall command from the project directory that contains the managed install-state.\n3. Delete any extra rule folders you copied manually and no longer want.\n4. Reinstall once, using a single path.\n
\n\n## Start Using ECC\n\nStart with the workflow you need, not the full catalog.\n\n| What you are doing | Start here |\n|---|---|\n| Building a feature | `/ecc:plan \"describe the feature\"`, then `tdd-workflow` |\n| Fixing a bug | Reproduce it with a failing test, then use `tdd-workflow` |\n| Reviewing new code | `/code-review` for a fresh-context review |\n| Repairing a build | `/build-fix` |\n| Cleaning a codebase | `/refactor-clean` |\n| Checking context pressure | `/context-budget` |\n| Ending a long session | `/save-session` or `/learn-eval` |\n| Resuming later | `/resume-session` |\n| Auditing agent config | `/security-scan` with a reviewed scanner, or installed `agentshield scan --path .` |\n\n
\nPlugin commands and manual commands\n\nClaude Code plugin commands use the namespaced form:\n\n```text\n/ecc:plan \"Add authentication\"\n```\n\nManual installs may expose the shorter compatibility form:\n\n```text\n/plan \"Add authentication\"\n```\n\nSkills are the primary workflow surface. Commands remain convenient entry points and compatibility shims. Check what is installed with:\n\n```bash\n/plugin list ecc@ecc\n```\n
\n\n
\nWhich agent should I use?\n\nSkills are the canonical workflow surface; maintained slash entries stay available for command-first workflows.\n\n| I want to... | Use this surface | Agent used |\n|--------------|-----------------|------------|\n| Plan a new feature | `/ecc:plan \"Add auth\"` | planner |\n| Design system architecture | `/ecc:plan` + architect agent | architect |\n| Write code with tests first | `tdd-workflow` skill | tdd-guide |\n| Review code I just wrote | `/code-review` | code-reviewer |\n| Fix a failing build | `/build-fix` | build-error-resolver |\n| Run end-to-end tests | `e2e-testing` skill | e2e-runner |\n| Find security vulnerabilities | `/security-scan` | security-reviewer |\n| Remove dead code | `/refactor-clean` | refactor-cleaner |\n| Update documentation | `/update-docs` | doc-updater |\n| Review Go code | `/go-review` | go-reviewer |\n| Review Python code | `/python-review` | python-reviewer |\n| Review F# code | *(invoke `fsharp-reviewer` directly)* | fsharp-reviewer |\n| Review TypeScript/JavaScript code | *(invoke `typescript-reviewer` directly)* | typescript-reviewer |\n| Develop HarmonyOS apps | *(invoke `harmonyos-app-resolver` directly)* | harmonyos-app-resolver |\n| Audit database queries | *(auto-delegated)* | database-reviewer |\n| Review production ML changes | `mle-workflow` skill + `mle-reviewer` agent | mle-reviewer |\n\n
\n\n
\nCommon workflows\n\nSlash forms below are shown where they remain part of the maintained command surface. Retired short-name shims such as `/tdd` and `/eval` live in `legacy-command-shims/` for explicit opt-in only.\n\n**Starting a new feature:**\n```\n/ecc:plan \"Add user authentication with OAuth\"\n -> planner creates implementation blueprint\ntdd-workflow skill -> tdd-guide enforces write-tests-first\n/code-review -> code-reviewer checks your work\n```\n\n**Fixing a bug:**\n```\ntdd-workflow skill -> tdd-guide: write a failing test that reproduces it\n -> implement the fix, verify test passes\n/code-review -> code-reviewer: catch regressions\n```\n\n**Preparing for production:**\n```\n/security-scan -> security-reviewer: OWASP Top 10 audit\ne2e-testing skill -> e2e-runner: critical user flow tests\n/test-coverage -> verify 80%+ coverage\n```\n
\n\n## Self-Hosted Models and Custom Endpoints\n\nECC works through each harness's normal configuration, so you can use an official provider, a compatible custom API endpoint or model gateway, or a self-hosted model without changing ECC's workflows.\n\nFor Claude Code, ECC does not hardcode Anthropic-hosted transport settings. Minimal gateway example:\n\n```bash\nexport ANTHROPIC_BASE_URL=https://your-gateway.example.com\nexport ANTHROPIC_AUTH_TOKEN=your-token\nclaude\n```\n\nIf your gateway remaps model names, configure that in Claude Code rather than in ECC. ECC's hooks, skills, commands, and rules are model-provider agnostic once the `claude` CLI is already working. See Anthropic's [LLM gateway documentation](https://docs.anthropic.com/en/docs/claude-code/llm-gateway) and [model configuration documentation](https://docs.anthropic.com/en/docs/claude-code/model-config).\n\nRun or self-host any open-source model behind that gateway using separate compute and serving setup. If you need GPU capacity, [Itô](https://compute.itomarkets.com) is ECC's preferred compute sponsor; any GPU provider works. The sponsorship link is passive: it does not invoke an RFQ, reserve capacity, provision compute, or configure serving. Separately, `ecc ito find` invokes the explicitly configured canonical Itô CLI and submits a live authenticated RFQ; it does not reserve capacity. Managed inference through Itô is not live yet.\n\n### Self-host Kimi with ECC + Itô compute\n\nThe Kimi Code harness and the model-serving layer are separate. ECC configures the agent harness; you bring an API endpoint ([get a Kimi API key](https://platform.kimi.ai?aff=ecc)) or self-host an open-weight Kimi model on your own GPU capacity. This adapter is verified against Kimi Code 0.31.x (`@moonshot-ai/kimi-code`):\n\n\n\n\n\n\n\n
\n \n \"Itô
\n 1. Get GPU capacity\n
\n Use Itô or any GPU provider.\n		\n \n \"Moonshot
\n 2. Serve Kimi\n
\n Expose the chosen checkpoint through a compatible endpoint.\n		\n \n \"ECC
\n 3. Run Kimi Code with ECC\n
\n Install project instructions and skills, then start Kimi Code.\n
\n\nConfigure the endpoint with Kimi Code's official provider guide, then install ECC:\n\n```bash\nbash ./install.sh --target kimi --profile minimal\nnode scripts/ecc.js doctor --target kimi\nkimi\n```\n\nKimi Code discovers the installed `.kimi-code/AGENTS.md` instructions and `.kimi-code/skills/` workflows natively; project-level `.agents/skills/` is also an official discovery location. ECC safely merges project MCP entries into `.kimi-code/mcp.json` and does not change the user-level `~/.kimi-code/config.toml`. Kimi Code supports native hooks, but ECC's current managed-project adapter does not configure them, so this installer does not offer Kimi hook profiles. The installer dry-run and regression suite verify that every managed Kimi write stays inside the project-local `.kimi-code/` root.\n\n### Itô compute CLI bridge\n\n`ecc ito` delegates to the separately installed canonical Itô client; ECC does not maintain a second API client. `ecc ito login [--no-browser]` performs device authorization, opens the Itô verification page by default, and persists a device token in macOS Keychain; `--no-browser` suppresses the page handoff. ECC itself does no browser automation. `ecc ito auth` is validation-only and rejects `--no-browser`. The available operations are `ecc ito login`, `ecc ito auth`, `ecc ito find`, `ecc ito status`, and the separately gated `ecc ito evals`. The matching MCP tools remain `ito_auth`, `ito_find`, and `ito_status`; `ito_auth` validates existing credentials and node qualification is CLI-only.\n\nThe `ito-compute-cli` package is currently unpublished. Build it locally from the Itô runtime repo (private while the desk hardens; design partners get access) under `cli/ito-compute-cli`, run `npm ci` and `npm run check`, then set `ECC_ITO_CLI_EXECUTABLE` to that build's absolute `dist/bin/ito.js` path. Login never inherits `ITO_API_KEY`; auth, find, and status forward `ITO_API_KEY` directly when configured, and `ITO_AUTH_MODE=legacy` is not required. `ecc ito logout` revokes the current device credential and retains its local copy if remote revocation cannot be confirmed. Device tokens use macOS Keychain by default; explicit file fallback must retain owner-only directory/file permissions. ECC does not discover this credential-bearing client through `PATH`. See the [`ito-compute` skill](skills/ito-compute/SKILL.md) for the full RFQ authority and MCP setup contract.\n\n`find` submits a live authenticated RFQ. It does not reserve capacity. `evals` requires both `ITO_ENABLE_SIXTYTWO_LIVE=1` and `--live-sixtytwo`, a separately installed `sixtytwo-cli==0.3.33`, an explicit node list, and an existing absolute configuration directory. It cannot rent, launch, recover, repair, or purchase. ECC exposes no quote lock, purchase, workload, or inference path, and it never replaces a missing client or failed live call with a local result.\n\n## What's New\n\nCurrent release: **2.2.1** (2026-08-31). Highlights of the 2.2 line:\n\n- Guided, manifest-driven setup across Claude Code, Codex, and Kimi Code, with install-state ownership, doctor, repair, and uninstall.\n- Native Antigravity install, a thin Pi adapter, and the packed-artifact release gate tested on Linux, macOS, and Windows.\n- Plan Canvas browser review, the unified memory vault (`ecc memory`), and the Itô compute skill family.\n\nFull history: [CHANGELOG.md](CHANGELOG.md). Per-release notes and evidence live under [docs/releases/](docs/releases/).\n\n### v2.0.0: The Agent Harness Operating System (Jun 2026)\n\nStable graduation of the 2.0 line: control-pane substrate, worktree lifecycle service, the `orch-*` orchestrator family, and the Discord community. Notes: [docs/releases/2.0.0/release-notes.md](docs/releases/2.0.0/release-notes.md).\n\n## What's Inside\n\n```text\nECC/\n|-- agents/ # 68 specialized subagents for delegation\n|-- skills/ # 292 reusable workflows loaded on demand\n|-- commands/ # 94 maintained slash-command shims\n|-- rules/ # opt-in common and language standards\n|-- hooks/ # runtime automation and enforcement\n|-- scripts/ # install, repair, sync, orchestration, and checks\n|-- .claude-plugin/ # Claude Code marketplace manifest\n|-- .codex/ # Codex reference configuration and agent roles\n|-- .opencode/ # OpenCode plugin, commands, and instructions\n|-- .cursor/ # Cursor rules and hook adapter\n|-- docs/ # public setup, architecture, and operating guides\n```\n\nThe root is the source of truth. Platform adapters package or map these same workflows instead of maintaining separate copies.\n\n
\nAnnotated component catalog\n\n```\nECC/\n|-- .claude-plugin/ # Plugin and marketplace manifests\n| |-- plugin.json # Plugin metadata and component paths\n| |-- marketplace.json # Marketplace catalog for /plugin marketplace add\n|\n|-- agents/ # 67 specialized subagents for delegation\n| |-- planner.md # Feature implementation planning\n| |-- architect.md # System design decisions\n| |-- tdd-guide.md # Test-driven development\n| |-- code-reviewer.md # Quality and security review\n| |-- security-reviewer.md # Vulnerability analysis\n| |-- build-error-resolver.md\n| |-- e2e-runner.md # Playwright E2E testing\n| |-- refactor-cleaner.md # Dead code cleanup\n| |-- doc-updater.md # Documentation sync\n| |-- docs-lookup.md # Documentation/API lookup\n| |-- chief-of-staff.md # Communication triage and drafts\n| |-- loop-operator.md # Autonomous loop execution\n| |-- harness-optimizer.md # Harness config tuning\n| |-- cpp-reviewer.md # C++ code review\n| |-- cpp-build-resolver.md # C++ build error resolution\n| |-- fsharp-reviewer.md # F# functional code review\n| |-- go-reviewer.md # Go code review\n| |-- go-build-resolver.md # Go build error resolution\n| |-- python-reviewer.md # Python code review\n| |-- database-reviewer.md # Database/Supabase review\n| |-- typescript-reviewer.md # TypeScript/JavaScript code review\n| |-- java-reviewer.md # Java/Spring Boot code review\n| |-- java-build-resolver.md # Java/Maven/Gradle build errors\n| |-- kotlin-reviewer.md # Kotlin/Android/KMP code review\n| |-- kotlin-build-resolver.md # Kotlin/Gradle build errors\n| |-- harmonyos-app-resolver.md # HarmonyOS/ArkTS app development\n| |-- rust-reviewer.md # Rust code review\n| |-- rust-build-resolver.md # Rust build error resolution\n| |-- pytorch-build-resolver.md # PyTorch/CUDA training errors\n| |-- mle-reviewer.md # Production ML pipeline, eval, serving, and monitoring review\n|\n|-- skills/ # Workflow definitions and domain knowledge\n| |-- coding-standards/ # Language best practices\n| |-- clickhouse-io/ # ClickHouse analytics, queries, data engineering\n| |-- backend-patterns/ # API, database, caching patterns\n| |-- frontend-patterns/ # React, Next.js patterns\n| |-- frontend-slides/ # HTML slide decks and PPTX-to-web presentation workflows\n| |-- article-writing/ # Long-form writing in a supplied voice without generic AI tone\n| |-- content-engine/ # Multi-platform social content and repurposing workflows\n| |-- market-research/ # Source-attributed market, competitor, and investor research\n| |-- investor-materials/ # Pitch decks, one-pagers, memos, and financial models\n| |-- investor-outreach/ # Personalized fundraising outreach and follow-up\n| |-- continuous-learning/ # Legacy v1 Stop-hook pattern extraction\n| |-- continuous-learning-v2/ # Instinct-based learning with confidence scoring\n| |-- iterative-retrieval/ # Progressive context refinement for subagents\n| |-- strategic-compact/ # Manual compaction suggestions (Longform Guide)\n| |-- tdd-workflow/ # TDD methodology\n| |-- security-review/ # Security checklist\n| |-- eval-harness/ # Verification loop evaluation (Longform Guide)\n| |-- verification-loop/ # Continuous verification (Longform Guide)\n| |-- videodb/ # Video and audio: ingest, search, edit, generate, stream\n| |-- golang-patterns/ # Go idioms and best practices\n| |-- golang-testing/ # Go testing patterns, TDD, benchmarks\n| |-- cpp-coding-standards/ # C++ coding standards from C++ Core Guidelines\n| |-- cpp-testing/ # C++ testing with GoogleTest, CMake/CTest\n| |-- django-patterns/ # Django patterns, models, views\n| |-- django-security/ # Django security best practices\n| |-- django-tdd/ # Django TDD workflow\n| |-- django-verification/ # Django verification loops\n| |-- laravel-patterns/ # Laravel architecture patterns\n| |-- laravel-security/ # Laravel security best practices\n| |-- laravel-tdd/ # Laravel TDD workflow\n| |-- laravel-verification/ # Laravel verification loops\n| |-- python-patterns/ # Python idioms and best practices\n| |-- python-testing/ # Python testing with pytest\n| |-- quarkus-patterns/ # Java Quarkus patterns\n| |-- quarkus-security/ # Quarkus security\n| |-- quarkus-tdd/ # Quarkus TDD\n| |-- quarkus-verification/ # Quarkus verification\n| |-- rails-patterns/ # Rails architecture patterns\n| |-- springboot-patterns/ # Java Spring Boot patterns\n| |-- springboot-security/ # Spring Boot security\n| |-- springboot-tdd/ # Spring Boot TDD\n| |-- springboot-verification/ # Spring Boot verification\n| |-- configure-ecc/ # Interactive installation wizard\n| |-- security-scan/ # AgentShield security auditor integration\n| |-- java-coding-standards/ # Java coding standards\n| |-- jpa-patterns/ # JPA/Hibernate patterns\n| |-- postgres-patterns/ # PostgreSQL optimization patterns\n| |-- nutrient-document-processing/ # Document processing with Nutrient API\n| |-- database-migrations/ # Migration patterns (Prisma, Drizzle, Django, Go)\n| |-- api-design/ # REST API design, pagination, error responses\n| |-- deployment-patterns/ # CI/CD, Docker, health checks, rollbacks\n| |-- docker-patterns/ # Docker Compose, networking, volumes, container security\n| |-- e2e-testing/ # Playwright E2E patterns and Page Object Model\n| |-- content-hash-cache-pattern/ # SHA-256 content hash caching for file processing\n| |-- cost-aware-llm-pipeline/ # LLM cost optimization, model routing, budget tracking\n| |-- regex-vs-llm-structured-text/ # Decision framework: regex vs LLM for text parsing\n| |-- swift-actor-persistence/ # Thread-safe Swift data persistence with actors\n| |-- swift-protocol-di-testing/ # Protocol-based DI for testable Swift code\n| |-- search-first/ # Research-before-coding workflow\n| |-- skill-stocktake/ # Audit skills and commands for quality\n| |-- liquid-glass-design/ # iOS 26 Liquid Glass design system\n| |-- foundation-models-on-device/ # Apple on-device LLM with FoundationModels\n| |-- swift-concurrency-6-2/ # Swift 6.2 Approachable Concurrency\n| |-- mle-workflow/ # Production ML data contracts, evals, deployment, monitoring\n| |-- perl-patterns/ # Modern Perl 5.36+ idioms and best practices\n| |-- perl-security/ # Perl security patterns, taint mode, safe I/O\n| |-- perl-testing/ # Perl TDD with Test2::V0, prove, Devel::Cover\n| |-- autonomous-loops/ # Autonomous loop patterns: sequential pipelines, PR loops, DAG orchestration\n| |-- plankton-code-quality/ # Write-time code quality enforcement with Plankton hooks\n| |-- codehealth-mcp/ # Optional CodeScene Code Health MCP skill (opt-in)\n| |-- docs/examples/project-guidelines-template.md # Template for project-specific skills\n|\n|-- commands/ # Maintained slash-entry compatibility; prefer skills/\n| |-- plan.md # /plan - Implementation planning\n| |-- code-review.md # /code-review - Quality review\n| |-- build-fix.md # /build-fix - Fix build errors\n| |-- refactor-clean.md # /refactor-clean - Dead code removal\n| |-- quality-gate.md # /quality-gate - Verification gate\n| |-- learn.md # /learn - Extract patterns mid-session (Longform Guide)\n| |-- learn-eval.md # /learn-eval - Extract, evaluate, and save patterns\n| |-- checkpoint.md # /checkpoint - Save verification state (Longform Guide)\n| |-- setup-pm.md # /setup-pm - Configure package manager\n| |-- go-review.md # /go-review - Go code review\n| |-- go-test.md # /go-test - Go TDD workflow\n| |-- go-build.md # /go-build - Fix Go build errors\n| |-- skill-create.md # /skill-create - Generate skills from git history\n| |-- instinct-status.md # /instinct-status - View learned instincts\n| |-- instinct-import.md # /instinct-import - Import instincts\n| |-- instinct-export.md # /instinct-export - Export instincts\n| |-- evolve.md # /evolve - Cluster instincts into skills\n| |-- prune.md # /prune - Delete expired pending instincts\n| |-- pm2.md # /pm2 - PM2 service lifecycle management\n| |-- multi-plan.md # /multi-plan - Multi-agent task decomposition\n| |-- multi-execute.md # /multi-execute - Orchestrated multi-agent workflows\n| |-- multi-backend.md # /multi-backend - Backend multi-service orchestration\n| |-- multi-frontend.md # /multi-frontend - Frontend multi-service orchestration\n| |-- multi-workflow.md # /multi-workflow - General multi-service workflows\n| |-- sessions.md # /sessions - Session history management\n| |-- test-coverage.md # /test-coverage - Test coverage analysis\n| |-- update-docs.md # /update-docs - Update documentation\n| |-- update-codemaps.md # /update-codemaps - Update codemaps\n| |-- python-review.md # /python-review - Python code review\n|-- legacy-command-shims/ # Opt-in archive for retired shims such as /tdd and /eval\n| |-- tdd.md # /tdd - Prefer the tdd-workflow skill\n| |-- e2e.md # /e2e - Prefer the e2e-testing skill\n| |-- eval.md # /eval - Prefer the eval-harness skill\n| |-- verify.md # /verify - Prefer the verification-loop skill\n| |-- orchestrate.md # /orchestrate - Prefer dmux-workflows or multi-workflow\n|\n|-- rules/ # Always-follow guidelines (copy to ~/.claude/rules/ecc/)\n| |-- README.md # Structure overview and installation guide\n| |-- common/ # Language-agnostic principles\n| | |-- coding-style.md # Immutability, file organization\n| | |-- git-workflow.md # Commit format, PR process\n| | |-- testing.md # TDD, 80% coverage requirement\n| | |-- performance.md # Model selection, context management\n| | |-- patterns.md # Design patterns, skeleton projects\n| | |-- hooks.md # Hook architecture, TodoWrite\n| | |-- agents.md # When to delegate to subagents\n| | |-- security.md # Mandatory security checks\n| |-- typescript/ # TypeScript/JavaScript specific\n| |-- python/ # Python specific\n| |-- golang/ # Go specific\n| |-- swift/ # Swift specific\n| |-- php/ # PHP specific\n| |-- arkts/ # HarmonyOS / ArkTS specific\n|\n|-- hooks/ # Trigger-based automations\n| |-- README.md # Hook documentation, recipes, and customization guide\n| |-- hooks.json # All hooks config (PreToolUse, PostToolUse, Stop, etc.)\n| |-- memory-persistence/ # Session lifecycle hooks (Longform Guide)\n| |-- strategic-compact/ # Compaction suggestions (Longform Guide)\n|\n|-- scripts/ # Cross-platform Node.js scripts\n| |-- lib/ # Shared utilities\n| | |-- utils.js # Cross-platform file/path/system utilities\n| | |-- package-manager.js # Package manager detection and selection\n| |-- hooks/ # Hook implementations\n| | |-- session-start.js # Load context on session start\n| | |-- session-end.js # Save state on session end\n| | |-- pre-compact.js # Pre-compaction state saving\n| | |-- suggest-compact.js # Strategic compaction suggestions\n| | |-- evaluate-session.js # Extract patterns from sessions\n| |-- setup-package-manager.js # Interactive PM setup\n|\n|-- tests/ # Test suite\n| |-- lib/ # Library tests\n| |-- hooks/ # Hook tests\n| |-- run-all.js # Run all tests\n|\n|-- contexts/ # Dynamic system prompt injection contexts (Longform Guide)\n| |-- dev.md # Development mode context\n| |-- review.md # Code review mode context\n| |-- research.md # Research/exploration mode context\n|\n|-- examples/ # Example configurations and sessions\n| |-- CLAUDE.md # Example project-level config\n| |-- user-CLAUDE.md # Example user-level config\n| |-- saas-nextjs-CLAUDE.md # Real-world SaaS (Next.js + Supabase + Stripe)\n| |-- go-microservice-CLAUDE.md # Real-world Go microservice (gRPC + PostgreSQL)\n| |-- django-api-CLAUDE.md # Real-world Django REST API (DRF + Celery)\n| |-- laravel-api-CLAUDE.md # Real-world Laravel API (PostgreSQL + Redis)\n| |-- rust-api-CLAUDE.md # Real-world Rust API (Axum + SQLx + PostgreSQL)\n|\n|-- mcp-configs/ # MCP server configurations\n| |-- mcp-servers.json # GitHub, Supabase, Vercel, Railway, etc.\n|\n|-- ecc_dashboard.py # Desktop GUI dashboard (Tkinter)\n|\n|-- marketplace.json # Self-hosted marketplace config (for /plugin marketplace add)\n```\n
\n\n
\nDashboard GUI\n\nLaunch the desktop dashboard to visually explore ECC components:\n\n```bash\nnpm run dashboard\n# or\npython3 ./ecc_dashboard.py\n```\n\n**Features:**\n- Tabbed interface: Agents, Skills, Commands, Rules, Settings\n- Dark/Light theme toggle\n- Font customization (family and size)\n- Project logo in header and taskbar\n- Search and filter across all components\n
\n\n## Key Concepts\n\n
\nAgents, skills, hooks, and rules explained\n\n### Agents\n\nSubagents handle delegated tasks with limited scope. Example:\n\n```markdown\n---\nname: code-reviewer\ndescription: Reviews code for quality, security, and maintainability\ntools: Read, Grep, Glob, Bash\nmodel: opus\n---\n\nYou are a senior code reviewer...\n```\n\n### Skills\n\nSkills are the primary workflow surface. They can be invoked directly, suggested automatically, and reused by agents. ECC still ships maintained `commands/` during migration, while retired short-name shims live under `legacy-command-shims/` for explicit opt-in only. New workflow development should land in `skills/` first.\n\n```markdown\n# TDD Workflow\n\n1. Define interfaces first\n2. Write failing tests (RED)\n3. Implement minimal code (GREEN)\n4. Refactor (IMPROVE)\n5. Verify 80%+ coverage\n```\n\n### Hooks\n\nHooks fire on tool events. Example: warn about console.log:\n\n```json\n{\n \"matcher\": \"tool == \\\"Edit\\\" && tool_input.file_path matches \\\"\\\\\\\\.(ts|tsx|js|jsx)$\\\"\",\n \"hooks\": [{\n \"type\": \"command\",\n \"command\": \"#!/bin/bash\\ngrep -n 'console\\\\.log' \\\"$file_path\\\" && echo '[Hook] Remove console.log' >&2\"\n }]\n}\n```\n\n### Rules\n\nRules are always-follow guidelines, organized into `common/` (language-agnostic) + language-specific directories:\n\n```\nrules/\n common/ # Universal principles (always install)\n typescript/ # TS/JS specific patterns and tools\n python/ # Python specific patterns and tools\n golang/ # Go specific patterns and tools\n swift/ # Swift specific patterns and tools\n php/ # PHP specific patterns and tools\n arkts/ # HarmonyOS / ArkTS patterns and constraints\n```\n\nSee [`rules/README.md`](rules/README.md) for installation and structure details.\n
\n\n## Guides\n\nThis repo is the raw code. The guides explain everything.\n\n