docs: salvage ECC onboarding guide commands

This commit is contained in:
Affaan Mustafa
2026-05-11 21:00:45 -04:00
committed by Affaan Mustafa
parent e5229cec92
commit 10d160b95e
12 changed files with 929 additions and 20 deletions

93
commands/ecc-guide.md Normal file
View File

@@ -0,0 +1,93 @@
---
description: Navigate ECC's current agents, skills, commands, hooks, install profiles, and docs from the live repository surface.
---
# /ecc-guide
Use this command as a conversational map of Everything Claude Code. It should help the user discover the right ECC surface for their task without dumping the entire README or stale catalog counts.
## Usage
```text
/ecc-guide
/ecc-guide setup
/ecc-guide skills
/ecc-guide commands
/ecc-guide hooks
/ecc-guide install
/ecc-guide find: <query>
/ecc-guide <feature-or-file-name>
```
## Operating Rules
1. Read current repository files before answering when the checkout is available.
2. Prefer current filesystem/catalog data over hard-coded counts.
3. Keep the first answer short, then offer specific drill-down paths.
4. Link users to canonical files instead of copying long sections.
5. Do not invent commands, skills, agents, or install profiles that are not present.
## What To Inspect
Use these files as the canonical map:
- `README.md` for install paths, reset/uninstall guidance, and high-level positioning
- `AGENTS.md` for contributor and project-structure guidance
- `agent.yaml` for exported agent and command surface
- `commands/` for maintained slash-command shims
- `skills/*/SKILL.md` for reusable skill workflows
- `agents/*.md` for delegated agent roles
- `hooks/README.md` and `hooks/hooks.json` for hook behavior
- `manifests/install-*.json` for selective install modules, components, and profiles
- `scripts/ci/catalog.js --json` for live catalog counts when running inside ECC
## Response Patterns
### No Arguments
Give a compact menu:
- setup and install
- choosing skills
- command compatibility shims
- agents and delegation
- hooks and safety
- troubleshooting an install
- finding a specific feature
Then ask what they want to do next.
### Topic Lookup
For topics like `skills`, `commands`, `hooks`, `install`, or `agents`:
1. Summarize the current surface in 3-6 bullets.
2. Point to the canonical directories/files.
3. Suggest one or two commands that can verify the state.
4. Avoid exhaustive lists unless the user asks for one.
### Search Mode
For `find: <query>`:
1. Search the relevant files with `rg`.
2. Group results by surface: skills, commands, agents, rules, docs, hooks.
3. Return the strongest matches first with file paths.
4. Recommend the next action for each match.
### Feature Lookup
For a specific feature name:
1. Check exact paths first, such as `skills/<name>/SKILL.md`, `commands/<name>.md`, and `agents/<name>.md`.
2. If exact lookup fails, search with `rg`.
3. Explain what the feature does, when to use it, and what file is canonical.
4. Mention adjacent features only when they reduce confusion.
## Related Commands
- `/project-init` for stack-aware ECC onboarding of a target project
- `/harness-audit` for deterministic repo readiness scoring
- `/skill-health` for skill quality checks
- `/skill-create` for extracting a new skill from local git history
- `/security-scan` for Claude/OpenCode configuration security review

86
commands/project-init.md Normal file
View File

@@ -0,0 +1,86 @@
---
description: Detect a project's stack and produce a dry-run ECC onboarding plan using the repository's install manifests and stack mappings.
---
# /project-init
Create a safe, reviewable ECC onboarding plan for the current project. This command should start in dry-run mode and only write files after explicit user approval.
## Usage
```text
/project-init
/project-init --dry-run
/project-init --target claude
/project-init --target cursor
/project-init --skills continuous-learning-v2,security-review
/project-init --config ecc-install.json
```
## Safety Rules
1. Default to dry-run. Do not modify `CLAUDE.md`, settings files, rules, skills, or install state until the user approves the concrete plan.
2. Preserve existing project guidance. If `CLAUDE.md`, `.claude/settings.local.json`, `.cursor/`, `.codex/`, `.gemini/`, `.opencode/`, `.codebuddy/`, `.joycode/`, or `.qwen/` already exists, inspect it and propose a merge/append plan instead of overwriting.
3. Use ECC's installer and manifest tooling. Do not hand-copy files or clone arbitrary remotes as an install shortcut.
4. Keep permissions narrow. Any generated settings should match detected build/test/lint tools and avoid broad shell access.
5. Report exactly what would change before applying anything.
## Detection Inputs
Read the current project root and detect stack signals from:
- package manager files: `package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `bun.lockb`
- language manifests: `pyproject.toml`, `requirements.txt`, `go.mod`, `Cargo.toml`, `pom.xml`, `build.gradle`, `build.gradle.kts`
- framework files: `next.config.*`, `vite.config.*`, `tailwind.config.*`, `Dockerfile`, `docker-compose.yml`
- ECC config: `ecc-install.json`
- optional stack map: `config/project-stack-mappings.json` in the ECC repo
When the ECC checkout is available, use `config/project-stack-mappings.json` as the stack-to-rules/skills reference. If the file is unavailable, fall back to the installed ECC manifests and explicit user choices.
## Planning Flow
1. Identify the target harness. Default to `claude` unless the user asks for `cursor`, `codex`, `gemini`, `opencode`, `codebuddy`, `joycode`, or `qwen`.
2. Detect stacks from project files and show the evidence for each match.
3. Resolve the smallest useful ECC plan:
- project has an `ecc-install.json`: `node scripts/install-plan.js --config ecc-install.json --json`
- user named a profile: `node scripts/install-plan.js --profile <profile> --target <target> --json`
- user named skills: `node scripts/install-plan.js --skills <skill-ids> --target <target> --json`
- only language stacks are detected: use the legacy language install dry-run with those language names
4. Run a dry-run apply command before writing:
```bash
node scripts/install-apply.js --target <target> --dry-run --json <language-or-profile-args>
```
5. Summarize detected stacks, selected modules/components/skills, target paths, skipped unsupported modules, and files that would be changed.
6. Ask for approval before applying the non-dry-run command.
## Output Contract
Return:
1. detected stack evidence
2. proposed target harness
3. exact dry-run command used
4. exact apply command to run after approval
5. files/directories that would be created or changed
6. warnings about existing files, broad permissions, missing scripts, or unsupported targets
## CLAUDE.md Guidance
If the user wants a `CLAUDE.md` starter, generate it separately from the installer plan and keep it minimal:
- build command, if detected
- test command, if detected
- lint/typecheck command, if detected
- dev server command, if detected
- repo-specific notes from existing package scripts or manifests
Never replace an existing `CLAUDE.md` without showing a diff and receiving approval.
## Related
- `config/project-stack-mappings.json` for stack-to-surface hints
- `scripts/install-plan.js` for deterministic plan resolution
- `scripts/install-apply.js` for dry-run and apply operations
- `/ecc-guide` for interactive feature discovery before installing