/skill

ECC Guide

Credit

This skill comes from the Everything Claude Code community. Full credit goes to the original community author.

Keep this credit when you copy or change the skill.

Purpose

Use this skill to help people understand and use Everything Claude Code, or ECC.

ECC can change fast. Check the current repo files before you give exact steps. Do not trust old counts, lists, or install steps.

When to Use

Use this skill when the user:

• asks what ECC has
• wants to find a skill, command, agent, hook, rule, or install plan
• is new to ECC
• asks how to do a task with ECC
• needs help picking ECC parts for a project
• asks how skills, commands, agents, hooks, and rules work
• has two copies of the same ECC parts
• needs help with install, reset, or removal
• wants to install only some parts

Main Rule

Answer from the current files, not from memory.

Check only the files needed for the question. Do not read the whole repo when one or two files will do.

If the ECC repo is open, these commands can show what is there:

node scripts/ci/catalog.js --json
find skills -maxdepth 2 -name SKILL.md | sort
find commands -maxdepth 1 -name '*.md' | sort
find agents -maxdepth 1 -name '*.md' | sort
node scripts/install-plan.js --list-profiles
node scripts/install-plan.js --list-components --json

If a command fails, do not guess. Check that:

• you are in the ECC repo root
• Node.js is installed
• the file still exists
• the file name has not changed
• the current branch is up to date

Say what you could and could not check.

Repo Map

• README.md: install, reset, removal, and common questions
• AGENTS.md: rules for work in the repo
• agent.yaml: agent setup and command list
• commands/: slash command helper files
• skills/*/SKILL.md: task guides
• agents/*.md: roles for helper agents
• rules/: code and tool rules
• hooks/README.md: hook notes
• hooks/hooks.json: hook setup
• scripts/hooks/: hook scripts
• manifests/install-*.json: install parts and plans
• docs/: guides, design notes, and release notes

A path may not exist in every branch or old release. Check before you name it as fact.

How to Answer

Start with the best answer. Then give one clear next step.

A good short answer has:

1. what to use
2. why it fits
3. the file or command that proves it
4. one next step

Do not:

• list every part unless the user asks
• copy large parts of the README
• suggest an old command when a current skill does the job
• say a part exists before checking
• give hand-copy steps when the installer supports the target
• run an install, reset, or remove step without clear user approval
• change project files while only giving advice

Common Tasks

Help a New User

Offer a short list:

• install or reset ECC
• pick skills for a project
• learn commands and skills
• check hooks and safety rules
• check tool support
• find one task guide

Use README.md for install, reset, and removal.

Use /project-init when the user wants help setting up one project. First check that this command exists in the current repo.

Find a Feature

For a question like “What should I use for tests?”:

1. Search skills/, commands/, and agents/.
2. Pick a skill first when one fits.
3. Use a command when the user wants a slash command or it is the current supported path.
4. Mention an agent only when a helper role would add value.
5. Open the best match and read its rules before you suggest it.

Use:

rg -n "<query>" skills commands agents docs
find skills -maxdepth 2 -name SKILL.md | sort

Search with more than one simple word if needed. For tests, try words such as test, verify, and check.

If there is no good match, say so. Point to the closest guide, but label it as a close match.

Give Install Help

First ask or find:

• the tool target, such as Claude Code
• global install or project install
• full install or selected parts
• whether ECC is already installed

List the current plans:

node scripts/install-plan.js --list-profiles

Show a plan before making changes:

node scripts/install-plan.js --profile minimal --target claude --json
node scripts/install-apply.js --profile minimal --target claude --dry-run

For one skill:

node scripts/install-plan.js --skills <skill-id> --target claude --json
node scripts/install-apply.js --skills <skill-id> --target claude --dry-run

Replace <skill-id> with an ID found in the current repo.

Always use a dry run first. Read the output for files that may be replaced.

Do not mix a plugin install with a full or hand-made install unless the user wants two copies. Two copies can cause old files, repeated commands, or unclear load order.

If ECC is already installed, check its install record before you suggest a new install.

Set Up a Project

Use /project-init if it exists and the user wants ECC set up for a repo.

The safe order is:

1. read project files to find the code stack
2. make a dry-run install plan
3. check current CLAUDE.md and settings files
4. show what would change
5. ask before writing files
6. keep new help short and tied to that repo

Do not replace hand-written project rules without approval. If files have local edits, keep them.

Fix a Problem

First find:

• the target tool
• the install path
• how ECC was installed
• the exact error text
• the command that failed

Then check the matching paths:

• .claude/
• .cursor/
• .codex/
• .gemini/
• .opencode/
• .codebuddy/
• .joycode/
• .qwen/
• plugin install records
• install state files
• hooks/hooks.json
• the skill or command named in the error

Only check folders that matter to the user’s tool.

For repo checks, suggest:

npm run harness:audit -- --format text
npm run observability:ready
npm test

Before using them, check that each script exists in package.json. Run one at a time when you need to find which step fails.

Do not tell the user to delete install folders as a first step. Find the install source and use the current reset or remove path from README.md.

Edge Cases

• If the ECC repo is not present, ask for its path or ask the user to run a check command.
• If the user uses an old release, read files from that release. Do not give steps from the newest branch.
• If docs and code disagree, trust the current install scripts for what they do. Tell the user about the mismatch.
• If two skills have the same goal, compare their current files and pick the smaller fit.
• If a command points to a missing skill, call it a broken link and do not suggest it as ready.
• If the target tool is not listed by the install plan, do not make up a target name.
• If a dry run would replace files, list those files and ask before the real install.
• If the user only wants an answer, do not install or edit anything.

Concrete Example

User asks:

Which ECC part should I use to set up a new Python project?

Check the live repo:

rg -n "project-init|Python|pyproject|requirements" skills commands agents docs
find skills -maxdepth 2 -name SKILL.md | sort

Open the best matching file. Check that /project-init still exists.

Then answer like this:

Use /project-init. It checks the project files and builds a setup plan for this repo.

Proof: commands/project-init.md
Check it with: rg -n "project-init" commands skills

Next: Run /project-init from the Python project root. Review its dry-run plan before you let it change files.

If /project-init is missing, say:

This ECC version does not have /project-init at the expected path.

Closest match: <path>
Next: Check README.md for the setup path used by this version.

Answer Forms

Short Pick

Use <skill-or-command>. It fits because <short reason>.

Main file: <path>
Check with: <command>
Next: <one clear action>

Search Results

Best matches:

- <path>: <why it helps>
- <path>: <why it helps>

Start with <path> because <short reason>.

Install Plan

Found: <project facts>
Target: <tool>
Plan: <plan or selected skills>
Dry run: <command>
Files that may change: <paths>
Approval needed before install: yes

Check Failed

I could not confirm <item> because <clear reason>.

I checked: <paths or commands>
Next: <one check the user can run>

Related Parts

Check that each part exists before you suggest it:

• /project-init: set up ECC for one project
• /harness-audit: check tool support
• /skill-health: review a skill
• /skill-create: make a skill from local Git work
• /security-scan: check Claude or OpenCode setup safety