mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-13 20:28:36 +08:00
Compare commits
No commits in common. "main" and "v1.10.0" have entirely different histories.
@ -1,12 +1,11 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"name": "everything-claude-code",
|
||||
"interface": {
|
||||
"displayName": "Everything Claude Code"
|
||||
},
|
||||
"plugins": [
|
||||
{
|
||||
"name": "ecc",
|
||||
"version": "1.10.0",
|
||||
"name": "everything-claude-code",
|
||||
"source": {
|
||||
"source": "local",
|
||||
"path": "../.."
|
||||
|
||||
@ -1,153 +0,0 @@
|
||||
---
|
||||
name: agent-introspection-debugging
|
||||
description: Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Agent Introspection Debugging
|
||||
|
||||
Use this skill when an agent run is failing repeatedly, consuming tokens without progress, looping on the same tools, or drifting away from the intended task.
|
||||
|
||||
This is a workflow skill, not a hidden runtime. It teaches the agent to debug itself systematically before escalating to a human.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- Maximum tool call / loop-limit failures
|
||||
- Repeated retries with no forward progress
|
||||
- Context growth or prompt drift that starts degrading output quality
|
||||
- File-system or environment state mismatch between expectation and reality
|
||||
- Tool failures that are likely recoverable with diagnosis and a smaller corrective action
|
||||
|
||||
## Scope Boundaries
|
||||
|
||||
Activate this skill for:
|
||||
- capturing failure state before retrying blindly
|
||||
- diagnosing common agent-specific failure patterns
|
||||
- applying contained recovery actions
|
||||
- producing a structured human-readable debug report
|
||||
|
||||
Do not use this skill as the primary source for:
|
||||
- feature verification after code changes; use `verification-loop`
|
||||
- framework-specific debugging when a narrower ECC skill already exists
|
||||
- runtime promises the current harness cannot enforce automatically
|
||||
|
||||
## Four-Phase Loop
|
||||
|
||||
### Phase 1: Failure Capture
|
||||
|
||||
Before trying to recover, record the failure precisely.
|
||||
|
||||
Capture:
|
||||
- error type, message, and stack trace when available
|
||||
- last meaningful tool call sequence
|
||||
- what the agent was trying to do
|
||||
- current context pressure: repeated prompts, oversized pasted logs, duplicated plans, or runaway notes
|
||||
- current environment assumptions: cwd, branch, relevant service state, expected files
|
||||
|
||||
Minimum capture template:
|
||||
|
||||
```markdown
|
||||
## Failure Capture
|
||||
- Session / task:
|
||||
- Goal in progress:
|
||||
- Error:
|
||||
- Last successful step:
|
||||
- Last failed tool / command:
|
||||
- Repeated pattern seen:
|
||||
- Environment assumptions to verify:
|
||||
```
|
||||
|
||||
### Phase 2: Root-Cause Diagnosis
|
||||
|
||||
Match the failure to a known pattern before changing anything.
|
||||
|
||||
| Pattern | Likely Cause | Check |
|
||||
| --- | --- | --- |
|
||||
| Maximum tool calls / repeated same command | loop or no-exit observer path | inspect the last N tool calls for repetition |
|
||||
| Context overflow / degraded reasoning | unbounded notes, repeated plans, oversized logs | inspect recent context for duplication and low-signal bulk |
|
||||
| `ECONNREFUSED` / timeout | service unavailable or wrong port | verify service health, URL, and port assumptions |
|
||||
| `429` / quota exhaustion | retry storm or missing backoff | count repeated calls and inspect retry spacing |
|
||||
| file missing after write / stale diff | race, wrong cwd, or branch drift | re-check path, cwd, git status, and actual file existence |
|
||||
| tests still failing after “fix” | wrong hypothesis | isolate the exact failing test and re-derive the bug |
|
||||
|
||||
Diagnosis questions:
|
||||
- is this a logic failure, state failure, environment failure, or policy failure?
|
||||
- did the agent lose the real objective and start optimizing the wrong subtask?
|
||||
- is the failure deterministic or transient?
|
||||
- what is the smallest reversible action that would validate the diagnosis?
|
||||
|
||||
### Phase 3: Contained Recovery
|
||||
|
||||
Recover with the smallest action that changes the diagnosis surface.
|
||||
|
||||
Safe recovery actions:
|
||||
- stop repeated retries and restate the hypothesis
|
||||
- trim low-signal context and keep only the active goal, blockers, and evidence
|
||||
- re-check the actual filesystem / branch / process state
|
||||
- narrow the task to one failing command, one file, or one test
|
||||
- switch from speculative reasoning to direct observation
|
||||
- escalate to a human when the failure is high-risk or externally blocked
|
||||
|
||||
Do not claim unsupported auto-healing actions like “reset agent state” or “update harness config” unless you are actually doing them through real tools in the current environment.
|
||||
|
||||
Contained recovery checklist:
|
||||
|
||||
```markdown
|
||||
## Recovery Action
|
||||
- Diagnosis chosen:
|
||||
- Smallest action taken:
|
||||
- Why this is safe:
|
||||
- What evidence would prove the fix worked:
|
||||
```
|
||||
|
||||
### Phase 4: Introspection Report
|
||||
|
||||
End with a report that makes the recovery legible to the next agent or human.
|
||||
|
||||
```markdown
|
||||
## Agent Self-Debug Report
|
||||
- Session / task:
|
||||
- Failure:
|
||||
- Root cause:
|
||||
- Recovery action:
|
||||
- Result: success | partial | blocked
|
||||
- Token / time burn risk:
|
||||
- Follow-up needed:
|
||||
- Preventive change to encode later:
|
||||
```
|
||||
|
||||
## Recovery Heuristics
|
||||
|
||||
Prefer these interventions in order:
|
||||
|
||||
1. Restate the real objective in one sentence.
|
||||
2. Verify the world state instead of trusting memory.
|
||||
3. Shrink the failing scope.
|
||||
4. Run one discriminating check.
|
||||
5. Only then retry.
|
||||
|
||||
Bad pattern:
|
||||
- retrying the same action three times with slightly different wording
|
||||
|
||||
Good pattern:
|
||||
- capture failure
|
||||
- classify the pattern
|
||||
- run one direct check
|
||||
- change the plan only if the check supports it
|
||||
|
||||
## Integration with ECC
|
||||
|
||||
- Use `verification-loop` after recovery if code was changed.
|
||||
- Use `continuous-learning-v2` when the failure pattern is worth turning into an instinct or later skill.
|
||||
- Use `council` when the issue is not technical failure but decision ambiguity.
|
||||
- Use `workspace-surface-audit` if the failure came from conflicting local state or repo drift.
|
||||
|
||||
## Output Standard
|
||||
|
||||
When this skill is active, do not end with “I fixed it” alone.
|
||||
|
||||
Always provide:
|
||||
- the failure pattern
|
||||
- the root-cause hypothesis
|
||||
- the recovery action
|
||||
- the evidence that the situation is now better or still blocked
|
||||
@ -1,215 +0,0 @@
|
||||
---
|
||||
name: agent-sort
|
||||
description: Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Agent Sort
|
||||
|
||||
Use this skill when a repo needs a project-specific ECC surface instead of the default full install.
|
||||
|
||||
The goal is not to guess what "feels useful." The goal is to classify ECC components with evidence from the actual codebase.
|
||||
|
||||
## When to Use
|
||||
|
||||
- A project only needs a subset of ECC and full installs are too noisy
|
||||
- The repo stack is clear, but nobody wants to hand-curate skills one by one
|
||||
- A team wants a repeatable install decision backed by grep evidence instead of opinion
|
||||
- You need to separate always-loaded daily workflow surfaces from searchable library/reference surfaces
|
||||
- A repo has drifted into the wrong language, rule, or hook set and needs cleanup
|
||||
|
||||
## Non-Negotiable Rules
|
||||
|
||||
- Use the current repository as the source of truth, not generic preferences
|
||||
- Every DAILY decision must cite concrete repo evidence
|
||||
- LIBRARY does not mean "delete"; it means "keep accessible without loading by default"
|
||||
- Do not install hooks, rules, or scripts that the current repo cannot use
|
||||
- Prefer ECC-native surfaces; do not introduce a second install system
|
||||
|
||||
## Outputs
|
||||
|
||||
Produce these artifacts in order:
|
||||
|
||||
1. DAILY inventory
|
||||
2. LIBRARY inventory
|
||||
3. install plan
|
||||
4. verification report
|
||||
5. optional `skill-library` router if the project wants one
|
||||
|
||||
## Classification Model
|
||||
|
||||
Use two buckets only:
|
||||
|
||||
- `DAILY`
|
||||
- should load every session for this repo
|
||||
- strongly matched to the repo's language, framework, workflow, or operator surface
|
||||
- `LIBRARY`
|
||||
- useful to retain, but not worth loading by default
|
||||
- should remain reachable through search, router skill, or selective manual use
|
||||
|
||||
## Evidence Sources
|
||||
|
||||
Use repo-local evidence before making any classification:
|
||||
|
||||
- file extensions
|
||||
- package managers and lockfiles
|
||||
- framework configs
|
||||
- CI and hook configs
|
||||
- build/test scripts
|
||||
- imports and dependency manifests
|
||||
- repo docs that explicitly describe the stack
|
||||
|
||||
Useful commands include:
|
||||
|
||||
```bash
|
||||
rg --files
|
||||
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
|
||||
cat package.json
|
||||
cat pyproject.toml
|
||||
cat Cargo.toml
|
||||
cat pubspec.yaml
|
||||
cat go.mod
|
||||
```
|
||||
|
||||
## Parallel Review Passes
|
||||
|
||||
If parallel subagents are available, split the review into these passes:
|
||||
|
||||
1. Agents
|
||||
- classify `agents/*`
|
||||
2. Skills
|
||||
- classify `skills/*`
|
||||
3. Commands
|
||||
- classify `commands/*`
|
||||
4. Rules
|
||||
- classify `rules/*`
|
||||
5. Hooks and scripts
|
||||
- classify hook surfaces, MCP health checks, helper scripts, and OS compatibility
|
||||
6. Extras
|
||||
- classify contexts, examples, MCP configs, templates, and guidance docs
|
||||
|
||||
If subagents are not available, run the same passes sequentially.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
### 1. Read the repo
|
||||
|
||||
Establish the real stack before classifying anything:
|
||||
|
||||
- languages in use
|
||||
- frameworks in use
|
||||
- primary package manager
|
||||
- test stack
|
||||
- lint/format stack
|
||||
- deployment/runtime surface
|
||||
- operator integrations already present
|
||||
|
||||
### 2. Build the evidence table
|
||||
|
||||
For every candidate surface, record:
|
||||
|
||||
- component path
|
||||
- component type
|
||||
- proposed bucket
|
||||
- repo evidence
|
||||
- short justification
|
||||
|
||||
Use this format:
|
||||
|
||||
```text
|
||||
skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack
|
||||
skills/django-patterns | skill | LIBRARY | no .py files, no pyproject.toml | not active in this repo
|
||||
rules/typescript/* | rules | DAILY | package.json + tsconfig.json | active TS repo
|
||||
rules/python/* | rules | LIBRARY | zero Python source files | keep accessible only
|
||||
```
|
||||
|
||||
### 3. Decide DAILY vs LIBRARY
|
||||
|
||||
Promote to `DAILY` when:
|
||||
|
||||
- the repo clearly uses the matching stack
|
||||
- the component is general enough to help every session
|
||||
- the repo already depends on the corresponding runtime or workflow
|
||||
|
||||
Demote to `LIBRARY` when:
|
||||
|
||||
- the component is off-stack
|
||||
- the repo might need it later, but not every day
|
||||
- it adds context overhead without immediate relevance
|
||||
|
||||
### 4. Build the install plan
|
||||
|
||||
Translate the classification into action:
|
||||
|
||||
- DAILY skills -> install or keep in `.claude/skills/`
|
||||
- DAILY commands -> keep as explicit shims only if still useful
|
||||
- DAILY rules -> install only matching language sets
|
||||
- DAILY hooks/scripts -> keep only compatible ones
|
||||
- LIBRARY surfaces -> keep accessible through search or `skill-library`
|
||||
|
||||
If the repo already uses selective installs, update that plan instead of creating another system.
|
||||
|
||||
### 5. Create the optional library router
|
||||
|
||||
If the project wants a searchable library surface, create:
|
||||
|
||||
- `.claude/skills/skill-library/SKILL.md`
|
||||
|
||||
That router should contain:
|
||||
|
||||
- a short explanation of DAILY vs LIBRARY
|
||||
- grouped trigger keywords
|
||||
- where the library references live
|
||||
|
||||
Do not duplicate every skill body inside the router.
|
||||
|
||||
### 6. Verify the result
|
||||
|
||||
After the plan is applied, verify:
|
||||
|
||||
- every DAILY file exists where expected
|
||||
- stale language rules were not left active
|
||||
- incompatible hooks were not installed
|
||||
- the resulting install actually matches the repo stack
|
||||
|
||||
Return a compact report with:
|
||||
|
||||
- DAILY count
|
||||
- LIBRARY count
|
||||
- removed stale surfaces
|
||||
- open questions
|
||||
|
||||
## Handoffs
|
||||
|
||||
If the next step is interactive installation or repair, hand off to:
|
||||
|
||||
- `configure-ecc`
|
||||
|
||||
If the next step is overlap cleanup or catalog review, hand off to:
|
||||
|
||||
- `skill-stocktake`
|
||||
|
||||
If the next step is broader context trimming, hand off to:
|
||||
|
||||
- `strategic-compact`
|
||||
|
||||
## Output Format
|
||||
|
||||
Return the result in this order:
|
||||
|
||||
```text
|
||||
STACK
|
||||
- language/framework/runtime summary
|
||||
|
||||
DAILY
|
||||
- always-loaded items with evidence
|
||||
|
||||
LIBRARY
|
||||
- searchable/reference items with evidence
|
||||
|
||||
INSTALL PLAN
|
||||
- what should be installed, removed, or routed
|
||||
|
||||
VERIFICATION
|
||||
- checks run and remaining gaps
|
||||
```
|
||||
@ -1,18 +1,12 @@
|
||||
---
|
||||
name: coding-standards
|
||||
description: Baseline cross-project coding conventions for naming, readability, immutability, and code-quality review. Use detailed frontend or backend skills for framework-specific patterns.
|
||||
description: Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Coding Standards & Best Practices
|
||||
|
||||
Baseline coding conventions applicable across projects.
|
||||
|
||||
This skill is the shared floor, not the detailed framework playbook.
|
||||
|
||||
- Use `frontend-patterns` for React, state, forms, rendering, and UI architecture.
|
||||
- Use `backend-patterns` or `api-design` for repository/service layers, endpoint design, validation, and server-specific concerns.
|
||||
- Use `rules/common/coding-style.md` when you need the shortest reusable rule layer instead of a full skill walkthrough.
|
||||
Universal coding standards applicable across all projects.
|
||||
|
||||
## When to Activate
|
||||
|
||||
@ -23,19 +17,6 @@ This skill is the shared floor, not the detailed framework playbook.
|
||||
- Setting up linting, formatting, or type-checking rules
|
||||
- Onboarding new contributors to coding conventions
|
||||
|
||||
## Scope Boundaries
|
||||
|
||||
Activate this skill for:
|
||||
- descriptive naming
|
||||
- immutability defaults
|
||||
- readability, KISS, DRY, and YAGNI enforcement
|
||||
- error-handling expectations and code-smell review
|
||||
|
||||
Do not use this skill as the primary source for:
|
||||
- React composition, hooks, or rendering patterns
|
||||
- backend architecture, API design, or database layering
|
||||
- domain-specific framework guidance when a narrower ECC skill already exists
|
||||
|
||||
## Code Quality Principles
|
||||
|
||||
### 1. Readability First
|
||||
|
||||
@ -1,145 +0,0 @@
|
||||
---
|
||||
name: frontend-design
|
||||
description: Create distinctive, production-grade frontend interfaces with high design quality. Use when the user asks to build web components, pages, or applications and the visual direction matters as much as the code quality.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Frontend Design
|
||||
|
||||
Use this when the task is not just "make it work" but "make it look designed."
|
||||
|
||||
This skill is for product pages, dashboards, app shells, components, or visual systems that need a clear point of view instead of generic AI-looking UI.
|
||||
|
||||
## When To Use
|
||||
|
||||
- building a landing page, dashboard, or app surface from scratch
|
||||
- upgrading a bland interface into something intentional and memorable
|
||||
- translating a product concept into a concrete visual direction
|
||||
- implementing a frontend where typography, composition, and motion matter
|
||||
|
||||
## Core Principle
|
||||
|
||||
Pick a direction and commit to it.
|
||||
|
||||
Safe-average UI is usually worse than a strong, coherent aesthetic with a few bold choices.
|
||||
|
||||
## Design Workflow
|
||||
|
||||
### 1. Frame the interface first
|
||||
|
||||
Before coding, settle:
|
||||
|
||||
- purpose
|
||||
- audience
|
||||
- emotional tone
|
||||
- visual direction
|
||||
- one thing the user should remember
|
||||
|
||||
Possible directions:
|
||||
|
||||
- brutally minimal
|
||||
- editorial
|
||||
- industrial
|
||||
- luxury
|
||||
- playful
|
||||
- geometric
|
||||
- retro-futurist
|
||||
- soft and organic
|
||||
- maximalist
|
||||
|
||||
Do not mix directions casually. Choose one and execute it cleanly.
|
||||
|
||||
### 2. Build the visual system
|
||||
|
||||
Define:
|
||||
|
||||
- type hierarchy
|
||||
- color variables
|
||||
- spacing rhythm
|
||||
- layout logic
|
||||
- motion rules
|
||||
- surface / border / shadow treatment
|
||||
|
||||
Use CSS variables or the project's token system so the interface stays coherent as it grows.
|
||||
|
||||
### 3. Compose with intention
|
||||
|
||||
Prefer:
|
||||
|
||||
- asymmetry when it sharpens hierarchy
|
||||
- overlap when it creates depth
|
||||
- strong whitespace when it clarifies focus
|
||||
- dense layouts only when the product benefits from density
|
||||
|
||||
Avoid defaulting to a symmetrical card grid unless it is clearly the right fit.
|
||||
|
||||
### 4. Make motion meaningful
|
||||
|
||||
Use animation to:
|
||||
|
||||
- reveal hierarchy
|
||||
- stage information
|
||||
- reinforce user action
|
||||
- create one or two memorable moments
|
||||
|
||||
Do not scatter generic micro-interactions everywhere. One well-directed load sequence is usually stronger than twenty random hover effects.
|
||||
|
||||
## Strong Defaults
|
||||
|
||||
### Typography
|
||||
|
||||
- pick fonts with character
|
||||
- pair a distinctive display face with a readable body face when appropriate
|
||||
- avoid generic defaults when the page is design-led
|
||||
|
||||
### Color
|
||||
|
||||
- commit to a clear palette
|
||||
- one dominant field with selective accents usually works better than evenly weighted rainbow palettes
|
||||
- avoid cliché purple-gradient-on-white unless the product genuinely calls for it
|
||||
|
||||
### Background
|
||||
|
||||
Use atmosphere:
|
||||
|
||||
- gradients
|
||||
- meshes
|
||||
- textures
|
||||
- subtle noise
|
||||
- patterns
|
||||
- layered transparency
|
||||
|
||||
Flat empty backgrounds are rarely the best answer for a product-facing page.
|
||||
|
||||
### Layout
|
||||
|
||||
- break the grid when the composition benefits from it
|
||||
- use diagonals, offsets, and grouping intentionally
|
||||
- keep reading flow obvious even when the layout is unconventional
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
Never default to:
|
||||
|
||||
- interchangeable SaaS hero sections
|
||||
- generic card piles with no hierarchy
|
||||
- random accent colors without a system
|
||||
- placeholder-feeling typography
|
||||
- motion that exists only because animation was easy to add
|
||||
|
||||
## Execution Rules
|
||||
|
||||
- preserve the established design system when working inside an existing product
|
||||
- match technical complexity to the visual idea
|
||||
- keep accessibility and responsiveness intact
|
||||
- frontends should feel deliberate on desktop and mobile
|
||||
|
||||
## Quality Gate
|
||||
|
||||
Before delivering:
|
||||
|
||||
- the interface has a clear visual point of view
|
||||
- typography and spacing feel intentional
|
||||
- color and motion support the product instead of decorating it randomly
|
||||
- the result does not read like generic AI UI
|
||||
- the implementation is production-grade, not just visually interesting
|
||||
@ -1,141 +0,0 @@
|
||||
---
|
||||
name: product-capability
|
||||
description: Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Product Capability
|
||||
|
||||
This skill turns product intent into explicit engineering constraints.
|
||||
|
||||
Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"
|
||||
|
||||
## When to Use
|
||||
|
||||
- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
|
||||
- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
|
||||
- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
|
||||
- Senior engineers keep restating the same hidden assumptions during review
|
||||
- You need a reusable artifact that can survive across harnesses and sessions
|
||||
|
||||
## Canonical Artifact
|
||||
|
||||
If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.
|
||||
|
||||
If no capability manifest exists yet, create one using the template at:
|
||||
|
||||
- `docs/examples/product-capability-template.md`
|
||||
|
||||
The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.
|
||||
|
||||
## Non-Negotiable Rules
|
||||
|
||||
- Do not invent product truth. Mark unresolved questions explicitly.
|
||||
- Separate user-visible promises from implementation details.
|
||||
- Call out what is fixed policy, what is architecture preference, and what is still open.
|
||||
- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
|
||||
- Prefer one reusable capability artifact over scattered ad hoc notes.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read only what is needed:
|
||||
|
||||
1. Product intent
|
||||
- issue, discussion, PRD, roadmap note, founder message
|
||||
2. Current architecture
|
||||
- relevant repo docs, contracts, schemas, routes, existing workflows
|
||||
3. Existing capability context
|
||||
- `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
|
||||
4. Delivery constraints
|
||||
- auth, billing, compliance, rollout, backwards compatibility, performance, review policy
|
||||
|
||||
## Core Workflow
|
||||
|
||||
### 1. Restate the capability
|
||||
|
||||
Compress the ask into one precise statement:
|
||||
|
||||
- who the user or operator is
|
||||
- what new capability exists after this ships
|
||||
- what outcome changes because of it
|
||||
|
||||
If this statement is weak, the implementation will drift.
|
||||
|
||||
### 2. Resolve capability constraints
|
||||
|
||||
Extract the constraints that must hold before implementation:
|
||||
|
||||
- business rules
|
||||
- scope boundaries
|
||||
- invariants
|
||||
- trust boundaries
|
||||
- data ownership
|
||||
- lifecycle transitions
|
||||
- rollout / migration requirements
|
||||
- failure and recovery expectations
|
||||
|
||||
These are the things that often live only in senior-engineer memory.
|
||||
|
||||
### 3. Define the implementation-facing contract
|
||||
|
||||
Produce an SRS-style capability plan with:
|
||||
|
||||
- capability summary
|
||||
- explicit non-goals
|
||||
- actors and surfaces
|
||||
- required states and transitions
|
||||
- interfaces / inputs / outputs
|
||||
- data model implications
|
||||
- security / billing / policy constraints
|
||||
- observability and operator requirements
|
||||
- open questions blocking implementation
|
||||
|
||||
### 4. Translate into execution
|
||||
|
||||
End with the exact handoff:
|
||||
|
||||
- ready for direct implementation
|
||||
- needs architecture review first
|
||||
- needs product clarification first
|
||||
|
||||
If useful, point to the next ECC-native lane:
|
||||
|
||||
- `project-flow-ops`
|
||||
- `workspace-surface-audit`
|
||||
- `api-connector-builder`
|
||||
- `dashboard-builder`
|
||||
- `tdd-workflow`
|
||||
- `verification-loop`
|
||||
|
||||
## Output Format
|
||||
|
||||
Return the result in this order:
|
||||
|
||||
```text
|
||||
CAPABILITY
|
||||
- one-paragraph restatement
|
||||
|
||||
CONSTRAINTS
|
||||
- fixed rules, invariants, and boundaries
|
||||
|
||||
IMPLEMENTATION CONTRACT
|
||||
- actors
|
||||
- surfaces
|
||||
- states and transitions
|
||||
- interface/data implications
|
||||
|
||||
NON-GOALS
|
||||
- what this lane explicitly does not own
|
||||
|
||||
OPEN QUESTIONS
|
||||
- blockers or product decisions still required
|
||||
|
||||
HANDOFF
|
||||
- what should happen next and which ECC lane should take it
|
||||
```
|
||||
|
||||
## Good Outcomes
|
||||
|
||||
- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
|
||||
- Engineering review has a durable artifact instead of relying on memory or Slack context.
|
||||
- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.
|
||||
@ -1,5 +1,7 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
|
||||
"name": "everything-claude-code",
|
||||
"description": "Battle-tested Claude Code configurations from an Anthropic hackathon winner — agents, skills, hooks, rules, and legacy command shims evolved over 10+ months of intensive daily use",
|
||||
"owner": {
|
||||
"name": "Affaan Mustafa",
|
||||
"email": "me@affaanmustafa.com"
|
||||
|
||||
@ -30,9 +30,6 @@ codex plugin install ./
|
||||
Run this from the repository root so `./` points to the repo root and `.mcp.json` resolves correctly.
|
||||
```
|
||||
|
||||
The installed plugin registers under the short slug `ecc` so tool and command names
|
||||
stay below provider length limits.
|
||||
|
||||
## MCP Servers Included
|
||||
|
||||
| Server | Purpose |
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"name": "everything-claude-code",
|
||||
"version": "1.10.0",
|
||||
"description": "Battle-tested Codex workflows — 156 shared ECC skills, production-ready MCP configs, and selective-install-aligned conventions for TDD, security scanning, code review, and autonomous development.",
|
||||
"author": {
|
||||
|
||||
22
.github/workflows/ci.yml
vendored
22
.github/workflows/ci.yml
vendored
@ -43,18 +43,10 @@ jobs:
|
||||
|
||||
# Package manager setup
|
||||
- name: Setup pnpm
|
||||
if: matrix.pm == 'pnpm' && matrix.node != '18.x'
|
||||
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
|
||||
if: matrix.pm == 'pnpm'
|
||||
uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4
|
||||
with:
|
||||
# Keep an explicit pnpm major because this repo's packageManager is Yarn.
|
||||
version: 10
|
||||
|
||||
- name: Setup pnpm (via Corepack)
|
||||
if: matrix.pm == 'pnpm' && matrix.node == '18.x'
|
||||
shell: bash
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare pnpm@9 --activate
|
||||
version: latest
|
||||
|
||||
- name: Setup Yarn (via Corepack)
|
||||
if: matrix.pm == 'yarn'
|
||||
@ -87,8 +79,6 @@ jobs:
|
||||
if: matrix.pm == 'pnpm'
|
||||
id: pnpm-cache-dir
|
||||
shell: bash
|
||||
env:
|
||||
COREPACK_ENABLE_STRICT: '0'
|
||||
run: echo "dir=$(pnpm store path)" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Cache pnpm
|
||||
@ -156,7 +146,7 @@ jobs:
|
||||
# Upload test artifacts on failure
|
||||
- name: Upload test artifacts
|
||||
if: failure()
|
||||
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
|
||||
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
|
||||
with:
|
||||
name: test-results-${{ matrix.os }}-node${{ matrix.node }}-${{ matrix.pm }}
|
||||
path: |
|
||||
@ -200,10 +190,6 @@ jobs:
|
||||
run: node scripts/ci/validate-install-manifests.js
|
||||
continue-on-error: false
|
||||
|
||||
- name: Validate workflow security
|
||||
run: node scripts/ci/validate-workflow-security.js
|
||||
continue-on-error: false
|
||||
|
||||
- name: Validate rules
|
||||
run: node scripts/ci/validate-rules.js
|
||||
continue-on-error: false
|
||||
|
||||
2
.github/workflows/maintenance.yml
vendored
2
.github/workflows/maintenance.yml
vendored
@ -43,7 +43,7 @@ jobs:
|
||||
name: Stale Issues/PRs
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/stale@b5d41d4e1d5dceea10e7104786b73624c18a190f # v10.2.0
|
||||
- uses: actions/stale@5bef64f19d7facfb25b37b414482c7164d639639 # v9
|
||||
with:
|
||||
stale-issue-message: 'This issue is stale due to inactivity.'
|
||||
stale-pr-message: 'This PR is stale due to inactivity.'
|
||||
|
||||
23
.github/workflows/monthly-metrics.yml
vendored
23
.github/workflows/monthly-metrics.yml
vendored
@ -15,7 +15,7 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Update monthly metrics issue
|
||||
uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
|
||||
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
|
||||
with:
|
||||
script: |
|
||||
const owner = context.repo.owner;
|
||||
@ -30,10 +30,6 @@ jobs:
|
||||
return match ? Number(match[1]) : null;
|
||||
}
|
||||
|
||||
function escapeRegex(value) {
|
||||
return value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
|
||||
}
|
||||
|
||||
function fmt(value) {
|
||||
if (value === null || value === undefined) return "n/a";
|
||||
return Number(value).toLocaleString("en-US");
|
||||
@ -171,18 +167,15 @@ jobs:
|
||||
}
|
||||
|
||||
const currentBody = issue.body || "";
|
||||
const rowPattern = new RegExp(`^\\| ${escapeRegex(monthKey)} \\|.*$`, "m");
|
||||
|
||||
let body;
|
||||
if (rowPattern.test(currentBody)) {
|
||||
body = currentBody.replace(rowPattern, row);
|
||||
console.log(`Refreshed issue #${issue.number} snapshot row for ${monthKey}`);
|
||||
} else {
|
||||
body = currentBody.includes("| Month (UTC) |")
|
||||
? `${currentBody.trimEnd()}\n${row}\n`
|
||||
: `${intro}\n${row}\n`;
|
||||
if (currentBody.includes(`| ${monthKey} |`)) {
|
||||
console.log(`Issue #${issue.number} already has snapshot row for ${monthKey}`);
|
||||
return;
|
||||
}
|
||||
|
||||
const body = currentBody.includes("| Month (UTC) |")
|
||||
? `${currentBody.trimEnd()}\n${row}\n`
|
||||
: `${intro}\n${row}\n`;
|
||||
|
||||
await github.rest.issues.update({
|
||||
owner,
|
||||
repo,
|
||||
|
||||
24
.github/workflows/release.yml
vendored
24
.github/workflows/release.yml
vendored
@ -18,17 +18,6 @@ jobs:
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f # v6.3.0
|
||||
with:
|
||||
node-version: '20.x'
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Verify OpenCode package payload
|
||||
run: node tests/scripts/build-opencode.test.js
|
||||
|
||||
- name: Validate version tag
|
||||
run: |
|
||||
if ! [[ "${REF_NAME}" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
|
||||
@ -38,21 +27,18 @@ jobs:
|
||||
|
||||
env:
|
||||
REF_NAME: ${{ github.ref_name }}
|
||||
- name: Verify package version matches tag
|
||||
- name: Verify plugin.json version matches tag
|
||||
env:
|
||||
TAG_NAME: ${{ github.ref_name }}
|
||||
run: |
|
||||
TAG_VERSION="${TAG_NAME#v}"
|
||||
PACKAGE_VERSION=$(node -p "require('./package.json').version")
|
||||
if [ "$TAG_VERSION" != "$PACKAGE_VERSION" ]; then
|
||||
echo "::error::Tag version ($TAG_VERSION) does not match package.json version ($PACKAGE_VERSION)"
|
||||
PLUGIN_VERSION=$(grep -oE '"version": *"[^"]*"' .claude-plugin/plugin.json | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
|
||||
if [ "$TAG_VERSION" != "$PLUGIN_VERSION" ]; then
|
||||
echo "::error::Tag version ($TAG_VERSION) does not match plugin.json version ($PLUGIN_VERSION)"
|
||||
echo "Run: ./scripts/release.sh $TAG_VERSION"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Verify release metadata stays in sync
|
||||
run: node tests/plugin-manifest.test.js
|
||||
|
||||
- name: Generate release highlights
|
||||
id: highlights
|
||||
env:
|
||||
@ -77,7 +63,7 @@ jobs:
|
||||
EOF
|
||||
|
||||
- name: Create GitHub Release
|
||||
uses: softprops/action-gh-release@b4309332981a82ec1c5618f44dd2e27cc8bfbfda # v3.0.0
|
||||
uses: softprops/action-gh-release@153bb8e04406b158c6c84fc1615b65b24149a1fe # v2
|
||||
with:
|
||||
body_path: release_body.md
|
||||
generate_release_notes: true
|
||||
|
||||
28
.github/workflows/reusable-release.yml
vendored
28
.github/workflows/reusable-release.yml
vendored
@ -27,17 +27,6 @@ jobs:
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f # v6.3.0
|
||||
with:
|
||||
node-version: '20.x'
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Verify OpenCode package payload
|
||||
run: node tests/scripts/build-opencode.test.js
|
||||
|
||||
- name: Validate version tag
|
||||
env:
|
||||
INPUT_TAG: ${{ inputs.tag }}
|
||||
@ -47,21 +36,6 @@ jobs:
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Verify package version matches tag
|
||||
env:
|
||||
INPUT_TAG: ${{ inputs.tag }}
|
||||
run: |
|
||||
TAG_VERSION="${INPUT_TAG#v}"
|
||||
PACKAGE_VERSION=$(node -p "require('./package.json').version")
|
||||
if [ "$TAG_VERSION" != "$PACKAGE_VERSION" ]; then
|
||||
echo "::error::Tag version ($TAG_VERSION) does not match package.json version ($PACKAGE_VERSION)"
|
||||
echo "Run: ./scripts/release.sh $TAG_VERSION"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Verify release metadata stays in sync
|
||||
run: node tests/plugin-manifest.test.js
|
||||
|
||||
- name: Generate release highlights
|
||||
env:
|
||||
TAG_NAME: ${{ inputs.tag }}
|
||||
@ -77,7 +51,7 @@ jobs:
|
||||
EOF
|
||||
|
||||
- name: Create GitHub Release
|
||||
uses: softprops/action-gh-release@b4309332981a82ec1c5618f44dd2e27cc8bfbfda # v3.0.0
|
||||
uses: softprops/action-gh-release@153bb8e04406b158c6c84fc1615b65b24149a1fe # v2
|
||||
with:
|
||||
tag_name: ${{ inputs.tag }}
|
||||
body_path: release_body.md
|
||||
|
||||
18
.github/workflows/reusable-test.yml
vendored
18
.github/workflows/reusable-test.yml
vendored
@ -35,18 +35,10 @@ jobs:
|
||||
node-version: ${{ inputs.node-version }}
|
||||
|
||||
- name: Setup pnpm
|
||||
if: inputs.package-manager == 'pnpm' && inputs.node-version != '18.x'
|
||||
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
|
||||
if: inputs.package-manager == 'pnpm'
|
||||
uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4
|
||||
with:
|
||||
# Keep an explicit pnpm major because this repo's packageManager is Yarn.
|
||||
version: 10
|
||||
|
||||
- name: Setup pnpm (via Corepack)
|
||||
if: inputs.package-manager == 'pnpm' && inputs.node-version == '18.x'
|
||||
shell: bash
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare pnpm@9 --activate
|
||||
version: latest
|
||||
|
||||
- name: Setup Yarn (via Corepack)
|
||||
if: inputs.package-manager == 'yarn'
|
||||
@ -78,8 +70,6 @@ jobs:
|
||||
if: inputs.package-manager == 'pnpm'
|
||||
id: pnpm-cache-dir
|
||||
shell: bash
|
||||
env:
|
||||
COREPACK_ENABLE_STRICT: '0'
|
||||
run: echo "dir=$(pnpm store path)" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Cache pnpm
|
||||
@ -144,7 +134,7 @@ jobs:
|
||||
|
||||
- name: Upload test artifacts
|
||||
if: failure()
|
||||
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
|
||||
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
|
||||
with:
|
||||
name: test-results-${{ inputs.os }}-node${{ inputs.node-version }}-${{ inputs.package-manager }}
|
||||
path: |
|
||||
|
||||
3
.github/workflows/reusable-validate.yml
vendored
3
.github/workflows/reusable-validate.yml
vendored
@ -42,9 +42,6 @@ jobs:
|
||||
- name: Validate install manifests
|
||||
run: node scripts/ci/validate-install-manifests.js
|
||||
|
||||
- name: Validate workflow security
|
||||
run: node scripts/ci/validate-workflow-security.js
|
||||
|
||||
- name: Validate rules
|
||||
run: node scripts/ci/validate-rules.js
|
||||
|
||||
|
||||
@ -184,7 +184,7 @@ Create a detailed implementation plan for: {input}
|
||||
```markdown
|
||||
---
|
||||
description: Create implementation plan
|
||||
agent: everything-claude-code:planner
|
||||
agent: planner
|
||||
---
|
||||
|
||||
Create a detailed implementation plan for: $ARGUMENTS
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Fix build and TypeScript errors with minimal changes
|
||||
agent: everything-claude-code:build-error-resolver
|
||||
agent: build-error-resolver
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Save verification state and progress checkpoint
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Checkpoint Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Review code for quality, security, and maintainability
|
||||
agent: everything-claude-code:code-reviewer
|
||||
agent: code-reviewer
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Generate and run E2E tests with Playwright
|
||||
agent: everything-claude-code:e2e-runner
|
||||
agent: e2e-runner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Run evaluation against acceptance criteria
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Eval Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Analyze instincts and suggest or generate evolved structures
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Evolve Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Fix Go build and vet errors
|
||||
agent: everything-claude-code:go-build-resolver
|
||||
agent: go-build-resolver
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Go code review for idiomatic patterns
|
||||
agent: everything-claude-code:go-reviewer
|
||||
agent: go-reviewer
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Go TDD workflow with table-driven tests
|
||||
agent: everything-claude-code:tdd-guide
|
||||
agent: tdd-guide
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Export instincts for sharing
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Instinct Export Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Import instincts from external sources
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Instinct Import Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Show learned instincts (project + global) with confidence
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Instinct Status Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Extract patterns and learnings from current session
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Learn Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Orchestrate multiple agents for complex tasks
|
||||
agent: everything-claude-code:planner
|
||||
agent: planner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Create implementation plan with risk assessment
|
||||
agent: everything-claude-code:planner
|
||||
agent: planner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: List registered projects and instinct counts
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Projects Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Promote project instincts to global scope
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Promote Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Remove dead code and consolidate duplicates
|
||||
agent: everything-claude-code:refactor-cleaner
|
||||
agent: refactor-cleaner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Fix Rust build errors and borrow checker issues
|
||||
agent: everything-claude-code:rust-build-resolver
|
||||
agent: rust-build-resolver
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Rust code review for ownership, safety, and idiomatic patterns
|
||||
agent: everything-claude-code:rust-reviewer
|
||||
agent: rust-reviewer
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Rust TDD workflow with unit and property tests
|
||||
agent: everything-claude-code:tdd-guide
|
||||
agent: tdd-guide
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Run comprehensive security review
|
||||
agent: everything-claude-code:security-reviewer
|
||||
agent: security-reviewer
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Configure package manager preference
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Setup Package Manager Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Generate skills from git history analysis
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Skill Create Command
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Enforce TDD workflow with 80%+ coverage
|
||||
agent: everything-claude-code:tdd-guide
|
||||
agent: tdd-guide
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Analyze and improve test coverage
|
||||
agent: everything-claude-code:tdd-guide
|
||||
agent: tdd-guide
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Update codemaps for codebase navigation
|
||||
agent: everything-claude-code:doc-updater
|
||||
agent: doc-updater
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Update documentation for recent changes
|
||||
agent: everything-claude-code:doc-updater
|
||||
agent: doc-updater
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Run verification loop to validate implementation
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Verify Command
|
||||
|
||||
104
.opencode/package-lock.json
generated
104
.opencode/package-lock.json
generated
@ -9,7 +9,7 @@
|
||||
"version": "1.10.0",
|
||||
"license": "MIT",
|
||||
"devDependencies": {
|
||||
"@opencode-ai/plugin": "^1.4.3",
|
||||
"@opencode-ai/plugin": "^1.0.0",
|
||||
"@types/node": "^20.0.0",
|
||||
"typescript": "^5.3.0"
|
||||
},
|
||||
@ -21,37 +21,22 @@
|
||||
}
|
||||
},
|
||||
"node_modules/@opencode-ai/plugin": {
|
||||
"version": "1.4.3",
|
||||
"resolved": "https://registry.npmjs.org/@opencode-ai/plugin/-/plugin-1.4.3.tgz",
|
||||
"integrity": "sha512-Ob/3tVSIeuMRJBr2O23RtrnC5djRe01Lglx+TwGEmjrH9yDBJ2tftegYLnNEjRoMuzITgq9LD8168p4pzv+U/A==",
|
||||
"version": "1.1.53",
|
||||
"resolved": "https://registry.npmjs.org/@opencode-ai/plugin/-/plugin-1.1.53.tgz",
|
||||
"integrity": "sha512-9ye7Wz2kESgt02AUDaMea4hXxj6XhWwKAG8NwFhrw09Ux54bGaMJFt1eIS8QQGIMaD+Lp11X4QdyEg96etEBJw==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@opencode-ai/sdk": "1.4.3",
|
||||
"@opencode-ai/sdk": "1.1.53",
|
||||
"zod": "4.1.8"
|
||||
},
|
||||
"peerDependencies": {
|
||||
"@opentui/core": ">=0.1.97",
|
||||
"@opentui/solid": ">=0.1.97"
|
||||
},
|
||||
"peerDependenciesMeta": {
|
||||
"@opentui/core": {
|
||||
"optional": true
|
||||
},
|
||||
"@opentui/solid": {
|
||||
"optional": true
|
||||
}
|
||||
}
|
||||
},
|
||||
"node_modules/@opencode-ai/sdk": {
|
||||
"version": "1.4.3",
|
||||
"resolved": "https://registry.npmjs.org/@opencode-ai/sdk/-/sdk-1.4.3.tgz",
|
||||
"integrity": "sha512-X0CAVbwoGAjTY2iecpWkx2B+GAa2jSaQKYpJ+xILopeF/OGKZUN15mjqci+L7cEuwLHV5wk3x2TStUOVCa5p0A==",
|
||||
"version": "1.1.53",
|
||||
"resolved": "https://registry.npmjs.org/@opencode-ai/sdk/-/sdk-1.1.53.tgz",
|
||||
"integrity": "sha512-RUIVnPOP1CyyU32FrOOYuE7Ge51lOBuhaFp2NSX98ncApT7ffoNetmwzqrhOiJQgZB1KrbCHLYOCK6AZfacxag==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"cross-spawn": "7.0.6"
|
||||
}
|
||||
"license": "MIT"
|
||||
},
|
||||
"node_modules/@types/node": {
|
||||
"version": "20.19.33",
|
||||
@ -63,61 +48,6 @@
|
||||
"undici-types": "~6.21.0"
|
||||
}
|
||||
},
|
||||
"node_modules/cross-spawn": {
|
||||
"version": "7.0.6",
|
||||
"resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.6.tgz",
|
||||
"integrity": "sha512-uV2QOWP2nWzsy2aMp8aRibhi9dlzF5Hgh5SHaB9OiTGEyDTiJJyx0uy51QXdyWbtAHNua4XJzUKca3OzKUd3vA==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"path-key": "^3.1.0",
|
||||
"shebang-command": "^2.0.0",
|
||||
"which": "^2.0.1"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">= 8"
|
||||
}
|
||||
},
|
||||
"node_modules/isexe": {
|
||||
"version": "2.0.0",
|
||||
"resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz",
|
||||
"integrity": "sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==",
|
||||
"dev": true,
|
||||
"license": "ISC"
|
||||
},
|
||||
"node_modules/path-key": {
|
||||
"version": "3.1.1",
|
||||
"resolved": "https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz",
|
||||
"integrity": "sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"engines": {
|
||||
"node": ">=8"
|
||||
}
|
||||
},
|
||||
"node_modules/shebang-command": {
|
||||
"version": "2.0.0",
|
||||
"resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz",
|
||||
"integrity": "sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"shebang-regex": "^3.0.0"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=8"
|
||||
}
|
||||
},
|
||||
"node_modules/shebang-regex": {
|
||||
"version": "3.0.0",
|
||||
"resolved": "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz",
|
||||
"integrity": "sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==",
|
||||
"dev": true,
|
||||
"license": "MIT",
|
||||
"engines": {
|
||||
"node": ">=8"
|
||||
}
|
||||
},
|
||||
"node_modules/typescript": {
|
||||
"version": "5.9.3",
|
||||
"resolved": "https://registry.npmjs.org/typescript/-/typescript-5.9.3.tgz",
|
||||
@ -139,22 +69,6 @@
|
||||
"dev": true,
|
||||
"license": "MIT"
|
||||
},
|
||||
"node_modules/which": {
|
||||
"version": "2.0.2",
|
||||
"resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz",
|
||||
"integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==",
|
||||
"dev": true,
|
||||
"license": "ISC",
|
||||
"dependencies": {
|
||||
"isexe": "^2.0.0"
|
||||
},
|
||||
"bin": {
|
||||
"node-which": "bin/node-which"
|
||||
},
|
||||
"engines": {
|
||||
"node": ">= 8"
|
||||
}
|
||||
},
|
||||
"node_modules/zod": {
|
||||
"version": "4.1.8",
|
||||
"resolved": "https://registry.npmjs.org/zod/-/zod-4.1.8.tgz",
|
||||
|
||||
@ -60,7 +60,7 @@
|
||||
"@opencode-ai/plugin": ">=1.0.0"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@opencode-ai/plugin": "^1.4.3",
|
||||
"@opencode-ai/plugin": "^1.0.0",
|
||||
"@types/node": "^20.0.0",
|
||||
"typescript": "^5.3.0"
|
||||
},
|
||||
|
||||
@ -23,9 +23,7 @@ import {
|
||||
} from "./lib/changed-files-store.js"
|
||||
import changedFilesTool from "../tools/changed-files.js"
|
||||
|
||||
type ECCHooksPluginFn = (input: PluginInput) => Promise<Record<string, unknown>>
|
||||
|
||||
export const ECCHooksPlugin: ECCHooksPluginFn = async ({
|
||||
export const ECCHooksPlugin = async ({
|
||||
client,
|
||||
$,
|
||||
directory,
|
||||
@ -456,7 +454,7 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
|
||||
const contextBlock = [
|
||||
"# ECC Context (preserve across compaction)",
|
||||
"",
|
||||
"## Active Plugin: Everything Claude Code v1.10.0",
|
||||
"## Active Plugin: Everything Claude Code v1.8.0",
|
||||
"- Hooks: file.edited, tool.execute.before/after, session.created/idle/deleted, shell.env, compacting, permission.ask",
|
||||
"- Tools: run-tests, check-coverage, security-audit, format-code, lint-check, git-summary, changed-files",
|
||||
"- Agents: 13 specialized (planner, architect, tdd-guide, code-reviewer, security-reviewer, build-error-resolver, e2e-runner, refactor-cleaner, doc-updater, go-reviewer, go-build-resolver, database-reviewer, python-reviewer)",
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
import { tool, type ToolDefinition } from "@opencode-ai/plugin/tool"
|
||||
import { tool } from "@opencode-ai/plugin/tool"
|
||||
import {
|
||||
buildTree,
|
||||
getChangedPaths,
|
||||
@ -26,7 +26,7 @@ function renderTree(nodes: TreeNode[], indent: string): string {
|
||||
return lines.join("\n")
|
||||
}
|
||||
|
||||
const changedFilesTool: ToolDefinition = tool({
|
||||
export default tool({
|
||||
description:
|
||||
"List files changed by agents in this session as a navigable tree. Shows added (+), modified (~), and deleted (-) indicators. Use filter to show only specific change types. Returns paths for git diff.",
|
||||
args: {
|
||||
@ -79,5 +79,3 @@ const changedFilesTool: ToolDefinition = tool({
|
||||
return output
|
||||
},
|
||||
})
|
||||
|
||||
export default changedFilesTool
|
||||
|
||||
@ -5,11 +5,11 @@
|
||||
* Supports common coverage report formats.
|
||||
*/
|
||||
|
||||
import { tool, type ToolDefinition } from "@opencode-ai/plugin/tool"
|
||||
import { tool } from "@opencode-ai/plugin/tool"
|
||||
import * as path from "path"
|
||||
import * as fs from "fs"
|
||||
|
||||
const checkCoverageTool: ToolDefinition = tool({
|
||||
export default tool({
|
||||
description:
|
||||
"Check test coverage against a threshold and identify files with low coverage. Reads coverage reports from common locations.",
|
||||
args: {
|
||||
@ -100,8 +100,6 @@ const checkCoverageTool: ToolDefinition = tool({
|
||||
},
|
||||
})
|
||||
|
||||
export default checkCoverageTool
|
||||
|
||||
interface CoverageSummary {
|
||||
total: {
|
||||
lines: number
|
||||
|
||||
@ -5,13 +5,13 @@
|
||||
* This avoids shell execution assumptions while still giving precise guidance.
|
||||
*/
|
||||
|
||||
import { tool, type ToolDefinition } from "@opencode-ai/plugin/tool"
|
||||
import { tool } from "@opencode-ai/plugin/tool"
|
||||
import * as path from "path"
|
||||
import * as fs from "fs"
|
||||
|
||||
type Formatter = "biome" | "prettier" | "black" | "gofmt" | "rustfmt"
|
||||
|
||||
const formatCodeTool: ToolDefinition = tool({
|
||||
export default tool({
|
||||
description:
|
||||
"Detect formatter for a file and return the exact command to run (Biome, Prettier, Black, gofmt, rustfmt).",
|
||||
args: {
|
||||
@ -43,8 +43,6 @@ const formatCodeTool: ToolDefinition = tool({
|
||||
},
|
||||
})
|
||||
|
||||
export default formatCodeTool
|
||||
|
||||
function detectFormatter(cwd: string, ext: string): Formatter | null {
|
||||
if (["ts", "tsx", "js", "jsx", "json", "css", "scss", "md", "yaml", "yml"].includes(ext)) {
|
||||
if (fs.existsSync(path.join(cwd, "biome.json")) || fs.existsSync(path.join(cwd, "biome.jsonc"))) {
|
||||
|
||||
@ -4,10 +4,10 @@
|
||||
* Returns branch/status/log/diff details for the active repository.
|
||||
*/
|
||||
|
||||
import { tool, type ToolDefinition } from "@opencode-ai/plugin/tool"
|
||||
import { tool } from "@opencode-ai/plugin/tool"
|
||||
import { execSync } from "child_process"
|
||||
|
||||
const gitSummaryTool: ToolDefinition = tool({
|
||||
export default tool({
|
||||
description:
|
||||
"Generate git summary with branch, status, recent commits, and optional diff stats.",
|
||||
args: {
|
||||
@ -45,8 +45,6 @@ const gitSummaryTool: ToolDefinition = tool({
|
||||
},
|
||||
})
|
||||
|
||||
export default gitSummaryTool
|
||||
|
||||
function run(command: string, cwd: string): string {
|
||||
try {
|
||||
return execSync(command, { cwd, encoding: "utf-8", stdio: ["ignore", "pipe", "pipe"] }).trim()
|
||||
|
||||
@ -4,13 +4,13 @@
|
||||
* Detects the appropriate linter and returns a runnable lint command.
|
||||
*/
|
||||
|
||||
import { tool, type ToolDefinition } from "@opencode-ai/plugin/tool"
|
||||
import { tool } from "@opencode-ai/plugin/tool"
|
||||
import * as path from "path"
|
||||
import * as fs from "fs"
|
||||
|
||||
type Linter = "biome" | "eslint" | "ruff" | "pylint" | "golangci-lint"
|
||||
|
||||
const lintCheckTool: ToolDefinition = tool({
|
||||
export default tool({
|
||||
description:
|
||||
"Detect linter for a target path and return command for check/fix runs.",
|
||||
args: {
|
||||
@ -43,8 +43,6 @@ const lintCheckTool: ToolDefinition = tool({
|
||||
},
|
||||
})
|
||||
|
||||
export default lintCheckTool
|
||||
|
||||
function detectLinter(cwd: string): Linter {
|
||||
if (fs.existsSync(path.join(cwd, "biome.json")) || fs.existsSync(path.join(cwd, "biome.jsonc"))) {
|
||||
return "biome"
|
||||
|
||||
@ -5,11 +5,11 @@
|
||||
* Automatically detects the package manager and test framework.
|
||||
*/
|
||||
|
||||
import { tool, type ToolDefinition } from "@opencode-ai/plugin/tool"
|
||||
import { tool } from "@opencode-ai/plugin/tool"
|
||||
import * as path from "path"
|
||||
import * as fs from "fs"
|
||||
|
||||
const runTestsTool: ToolDefinition = tool({
|
||||
export default tool({
|
||||
description:
|
||||
"Run the test suite with optional coverage, watch mode, or specific test patterns. Automatically detects package manager (npm, pnpm, yarn, bun) and test framework.",
|
||||
args: {
|
||||
@ -97,8 +97,6 @@ const runTestsTool: ToolDefinition = tool({
|
||||
},
|
||||
})
|
||||
|
||||
export default runTestsTool
|
||||
|
||||
async function detectPackageManager(cwd: string): Promise<string> {
|
||||
const lockFiles: Record<string, string> = {
|
||||
"bun.lockb": "bun",
|
||||
|
||||
@ -8,11 +8,11 @@
|
||||
* The regex patterns below are used to DETECT potential issues in user code.
|
||||
*/
|
||||
|
||||
import { tool, type ToolDefinition } from "@opencode-ai/plugin/tool"
|
||||
import { tool } from "@opencode-ai/plugin/tool"
|
||||
import * as path from "path"
|
||||
import * as fs from "fs"
|
||||
|
||||
const securityAuditTool: ToolDefinition = tool({
|
||||
export default tool({
|
||||
description:
|
||||
"Run a comprehensive security audit including dependency vulnerabilities, secret scanning, and common security issues.",
|
||||
args: {
|
||||
@ -106,8 +106,6 @@ const securityAuditTool: ToolDefinition = tool({
|
||||
},
|
||||
})
|
||||
|
||||
export default securityAuditTool
|
||||
|
||||
interface AuditCheck {
|
||||
name: string
|
||||
description: string
|
||||
|
||||
12
AGENTS.md
12
AGENTS.md
@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — Agent Instructions
|
||||
|
||||
This is a **production-ready AI coding plugin** providing 47 specialized agents, 181 skills, 79 commands, and automated hook workflows for software development.
|
||||
This is a **production-ready AI coding plugin** providing 38 specialized agents, 156 skills, 72 commands, and automated hook workflows for software development.
|
||||
|
||||
**Version:** 1.10.0
|
||||
|
||||
@ -25,8 +25,8 @@ This is a **production-ready AI coding plugin** providing 47 specialized agents,
|
||||
| e2e-runner | End-to-end Playwright testing | Critical user flows |
|
||||
| refactor-cleaner | Dead code cleanup | Code maintenance |
|
||||
| doc-updater | Documentation and codemaps | Updating docs |
|
||||
| cpp-reviewer | C/C++ code review | C and C++ projects |
|
||||
| cpp-build-resolver | C/C++ build errors | C and C++ build failures |
|
||||
| cpp-reviewer | C++ code review | C++ projects |
|
||||
| cpp-build-resolver | C++ build errors | C++ build failures |
|
||||
| docs-lookup | Documentation lookup via Context7 | API/docs questions |
|
||||
| go-reviewer | Go code review | Go projects |
|
||||
| go-build-resolver | Go build errors | Go build failures |
|
||||
@ -145,9 +145,9 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
agents/ — 47 specialized subagents
|
||||
skills/ — 181 workflow skills and domain knowledge
|
||||
commands/ — 79 slash commands
|
||||
agents/ — 38 specialized subagents
|
||||
skills/ — 156 workflow skills and domain knowledge
|
||||
commands/ — 72 slash commands
|
||||
hooks/ — Trigger-based automations
|
||||
rules/ — Always-follow guidelines (common + per-language)
|
||||
scripts/ — Cross-platform Node.js utilities
|
||||
|
||||
@ -7,7 +7,6 @@ Thanks for wanting to contribute! This repo is a community resource for Claude C
|
||||
- [What We're Looking For](#what-were-looking-for)
|
||||
- [Quick Start](#quick-start)
|
||||
- [Contributing Skills](#contributing-skills)
|
||||
- [Skill Adaptation Policy](#skill-adaptation-policy)
|
||||
- [Contributing Agents](#contributing-agents)
|
||||
- [Contributing Hooks](#contributing-hooks)
|
||||
- [Contributing Commands](#contributing-commands)
|
||||
@ -74,7 +73,7 @@ git add . && git commit -m "feat: add my-skill" && git push -u origin feat/my-co
|
||||
|
||||
Skills are knowledge modules that Claude Code loads based on context.
|
||||
|
||||
> **Comprehensive Guide:** For detailed guidance on creating effective skills, see [Skill Development Guide](docs/SKILL-DEVELOPMENT-GUIDE.md). It covers:
|
||||
> ** Comprehensive Guide:** For detailed guidance on creating effective skills, see [Skill Development Guide](docs/SKILL-DEVELOPMENT-GUIDE.md). It covers:
|
||||
> - Skill architecture and categories
|
||||
> - Writing effective content with examples
|
||||
> - Best practices and common patterns
|
||||
@ -143,18 +142,7 @@ Link to complementary skills (e.g., `related-skill-1`, `related-skill-2`).
|
||||
| **Workflow** | Step-by-step processes | `tdd-workflow`, `refactoring-workflow` |
|
||||
| **Domain Knowledge** | Specialized domains | `security-review`, `api-design` |
|
||||
| **Tool Integration** | Tool/library usage | `docker-patterns`, `supabase-patterns` |
|
||||
| **Template** | Project-specific skill templates | `docs/examples/project-guidelines-template.md` |
|
||||
|
||||
### Skill Adaptation Policy
|
||||
|
||||
If you are porting an idea from another repo, plugin, harness, or personal prompt pack, read [Skill Adaptation Policy](docs/skill-adaptation-policy.md) before opening the PR.
|
||||
|
||||
Short version:
|
||||
|
||||
- copy the underlying idea, not the external product identity
|
||||
- rename the skill when ECC materially changes or expands the surface
|
||||
- prefer ECC-native rules, skills, scripts, and MCPs over new default third-party dependencies
|
||||
- do not ship a skill whose main value is telling users to install an unvetted package
|
||||
| **Template** | Project-specific skill templates | `project-guidelines-example` |
|
||||
|
||||
### Skill Checklist
|
||||
|
||||
@ -177,7 +165,7 @@ Short version:
|
||||
| `backend-patterns/` | Framework Patterns | API and database patterns |
|
||||
| `security-review/` | Domain Knowledge | Security checklist |
|
||||
| `tdd-workflow/` | Workflow | Test-driven development process |
|
||||
| `docs/examples/project-guidelines-template.md` | Template | Project-specific skill template |
|
||||
| `project-guidelines-example/` | Template | Project-specific skill template |
|
||||
|
||||
---
|
||||
|
||||
|
||||
154
README.md
154
README.md
@ -84,9 +84,8 @@ This repo is the raw code only. The guides explain everything.
|
||||
|
||||
### v1.10.0 — Surface Refresh, Operator Workflows, and ECC 2.0 Alpha (Apr 2026)
|
||||
|
||||
- **Dashboard GUI** — New Tkinter-based desktop application (`ecc_dashboard.py` or `npm run dashboard`) with dark/light theme toggle, font customization, and project logo in header and taskbar.
|
||||
- **Public surface synced to the live repo** — metadata, catalog counts, plugin manifests, and install-facing docs now match the actual OSS surface: 38 agents, 156 skills, and 72 legacy command shims.
|
||||
- **Operator and outbound workflow expansion** — `brand-voice`, `social-graph-ranker`, `connections-optimizer`, `customer-billing-ops`, `ecc-tools-cost-audit`, `google-workspace-ops`, `project-flow-ops`, and `workspace-surface-audit` round out the operator lane.
|
||||
- **Operator and outbound workflow expansion** — `brand-voice`, `social-graph-ranker`, `connections-optimizer`, `customer-billing-ops`, `google-workspace-ops`, `project-flow-ops`, and `workspace-surface-audit` round out the operator lane.
|
||||
- **Media and launch tooling** — `manim-video`, `remotion-video-creation`, and upgraded social publishing surfaces make technical explainers and launch content part of the same system.
|
||||
- **Framework and product surface growth** — `nestjs-patterns`, richer Codex/OpenCode install surfaces, and expanded cross-harness packaging keep the repo usable beyond Claude Code alone.
|
||||
- **ECC 2.0 alpha is in-tree** — the Rust control-plane prototype in `ecc2/` now builds locally and exposes `dashboard`, `start`, `sessions`, `status`, `stop`, `resume`, and `daemon` commands. It is usable as an alpha, not yet a general release.
|
||||
@ -101,7 +100,7 @@ This repo is the raw code only. The guides explain everything.
|
||||
- **Orchestration overhaul** — Harness audit scoring made deterministic, orchestration status and launcher compatibility hardened, observer loop prevention with 5-layer guard.
|
||||
- **Observer reliability** — Memory explosion fix with throttling and tail sampling, sandbox access fix, lazy-start logic, and re-entrancy guard.
|
||||
- **12 language ecosystems** — New rules for Java, PHP, Perl, Kotlin/Android/KMP, C++, and Rust join existing TypeScript, Python, Go, and common rules.
|
||||
- **Community contributions** — Korean and Chinese translations, biome hook optimization, video processing skills, operational skills, PowerShell installer, Antigravity IDE support.
|
||||
- **Community contributions** — Korean and Chinese translations, security hook, biome hook optimization, video processing skills, operational skills, PowerShell installer, Antigravity IDE support.
|
||||
- **CI hardening** — 19 test failure fixes, catalog count enforcement, install manifest validation, and full test suite green.
|
||||
|
||||
### v1.8.0 — Harness Performance System (Mar 2026)
|
||||
@ -174,14 +173,12 @@ Get up and running in under 2 minutes:
|
||||
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
|
||||
|
||||
# Install plugin
|
||||
/plugin install ecc@ecc
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
### Step 2: Install Rules (Required)
|
||||
|
||||
> WARNING: **Important:** Claude Code plugins cannot distribute `rules` automatically. Install them manually:
|
||||
>
|
||||
> If your local Claude setup was wiped or reset, that does not mean you need to repurchase ECC. Start with `ecc list-installed`, then run `ecc doctor` and `ecc repair` before reinstalling anything. That usually restores ECC-managed files without rebuilding your setup. If the problem is account or marketplace access for ECC Tools, handle billing/account recovery separately.
|
||||
|
||||
```bash
|
||||
# Clone the repo first
|
||||
@ -230,33 +227,16 @@ For manual install instructions see the README in the `rules/` folder. When copy
|
||||
# Existing slash-style command names still work while ECC migrates off commands/.
|
||||
|
||||
# Plugin install uses the namespaced form
|
||||
/ecc:plan "Add user authentication"
|
||||
/everything-claude-code:plan "Add user authentication"
|
||||
|
||||
# Manual install keeps the shorter slash form:
|
||||
# /plan "Add user authentication"
|
||||
|
||||
# Check available commands
|
||||
/plugin list ecc@ecc
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
**That's it!** You now have access to 47 agents, 181 skills, and 79 legacy command shims.
|
||||
|
||||
### Dashboard GUI
|
||||
|
||||
Launch the desktop dashboard to visually explore ECC components:
|
||||
|
||||
```bash
|
||||
npm run dashboard
|
||||
# or
|
||||
python3 ./ecc_dashboard.py
|
||||
```
|
||||
|
||||
**Features:**
|
||||
- Tabbed interface: Agents, Skills, Commands, Rules, Settings
|
||||
- Dark/Light theme toggle
|
||||
- Font customization (family & size)
|
||||
- Project logo in header and taskbar
|
||||
- Search and filter across all components
|
||||
**That's it!** You now have access to 38 agents, 156 skills, and 72 legacy command shims.
|
||||
|
||||
### Multi-model commands require additional setup
|
||||
|
||||
@ -371,7 +351,7 @@ everything-claude-code/
|
||||
| |-- market-research/ # Source-attributed market, competitor, and investor research (NEW)
|
||||
| |-- investor-materials/ # Pitch decks, one-pagers, memos, and financial models (NEW)
|
||||
| |-- investor-outreach/ # Personalized fundraising outreach and follow-up (NEW)
|
||||
| |-- continuous-learning/ # Legacy v1 Stop-hook pattern extraction
|
||||
| |-- continuous-learning/ # Auto-extract patterns from sessions (Longform Guide)
|
||||
| |-- continuous-learning-v2/ # Instinct-based learning with confidence scoring
|
||||
| |-- iterative-retrieval/ # Progressive context refinement for subagents
|
||||
| |-- strategic-compact/ # Manual compaction suggestions (Longform Guide)
|
||||
@ -404,7 +384,7 @@ everything-claude-code/
|
||||
| |-- jpa-patterns/ # JPA/Hibernate patterns (NEW)
|
||||
| |-- postgres-patterns/ # PostgreSQL optimization patterns (NEW)
|
||||
| |-- nutrient-document-processing/ # Document processing with Nutrient API (NEW)
|
||||
| |-- docs/examples/project-guidelines-template.md # Template for project-specific skills
|
||||
| |-- project-guidelines-example/ # Template for project-specific skills
|
||||
| |-- database-migrations/ # Migration patterns (Prisma, Drizzle, Django, Go) (NEW)
|
||||
| |-- api-design/ # REST API design, pagination, error responses (NEW)
|
||||
| |-- deployment-patterns/ # CI/CD, Docker, health checks, rollbacks (NEW)
|
||||
@ -518,12 +498,6 @@ everything-claude-code/
|
||||
|-- mcp-configs/ # MCP server configurations
|
||||
| |-- mcp-servers.json # GitHub, Supabase, Vercel, Railway, etc.
|
||||
|
|
||||
|-- ecc_dashboard.py # Desktop GUI dashboard (Tkinter)
|
||||
|
|
||||
|-- assets/ # Assets for dashboard
|
||||
| |-- images/
|
||||
| |-- ecc-logo.png
|
||||
|
|
||||
|-- marketplace.json # Self-hosted marketplace config (for /plugin marketplace add)
|
||||
```
|
||||
|
||||
@ -541,7 +515,7 @@ Use the `/skill-create` command for local analysis without external services:
|
||||
|
||||
```bash
|
||||
/skill-create # Analyze current repo
|
||||
/skill-create --instincts # Also generate instincts for continuous-learning-v2
|
||||
/skill-create --instincts # Also generate instincts for continuous-learning
|
||||
```
|
||||
|
||||
This analyzes your git history locally and generates SKILL.md files.
|
||||
@ -606,7 +580,6 @@ The instinct-based learning system automatically learns your patterns:
|
||||
```
|
||||
|
||||
See `skills/continuous-learning-v2/` for full documentation.
|
||||
Keep `continuous-learning/` only when you explicitly want the legacy v1 Stop-hook learned-skill flow.
|
||||
|
||||
---
|
||||
|
||||
@ -648,7 +621,7 @@ The easiest way to use this repo - install as a Claude Code plugin:
|
||||
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
|
||||
|
||||
# Install the plugin
|
||||
/plugin install ecc@ecc
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
Or add directly to your `~/.claude/settings.json`:
|
||||
@ -656,7 +629,7 @@ Or add directly to your `~/.claude/settings.json`:
|
||||
```json
|
||||
{
|
||||
"extraKnownMarketplaces": {
|
||||
"ecc": {
|
||||
"everything-claude-code": {
|
||||
"source": {
|
||||
"source": "github",
|
||||
"repo": "affaan-m/everything-claude-code"
|
||||
@ -664,7 +637,7 @@ Or add directly to your `~/.claude/settings.json`:
|
||||
}
|
||||
},
|
||||
"enabledPlugins": {
|
||||
"ecc@ecc": true
|
||||
"everything-claude-code@everything-claude-code": true
|
||||
}
|
||||
}
|
||||
```
|
||||
@ -727,40 +700,14 @@ mkdir -p ~/.claude/commands
|
||||
cp everything-claude-code/commands/*.md ~/.claude/commands/
|
||||
```
|
||||
|
||||
#### Install hooks
|
||||
#### Add hooks to settings.json
|
||||
|
||||
Do not copy the raw repo `hooks/hooks.json` into `~/.claude/settings.json` or `~/.claude/hooks/hooks.json`. That file is plugin/repo-oriented and still contains `${CLAUDE_PLUGIN_ROOT}` placeholders, so raw copying is not a supported manual install path.
|
||||
|
||||
Use the installer to install only the Claude hook runtime so command paths are rewritten correctly:
|
||||
|
||||
```bash
|
||||
# macOS / Linux
|
||||
bash ./install.sh --target claude --modules hooks-runtime
|
||||
```
|
||||
|
||||
```powershell
|
||||
# Windows PowerShell
|
||||
pwsh -File .\install.ps1 --target claude --modules hooks-runtime
|
||||
```
|
||||
|
||||
That writes resolved hooks to `~/.claude/hooks/hooks.json` and leaves any existing `~/.claude/settings.json` untouched.
|
||||
|
||||
If 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 `${CLAUDE_PLUGIN_ROOT}` resolution failures.
|
||||
|
||||
Windows note: the Claude config directory is `%USERPROFILE%\\.claude`, not `~/claude`.
|
||||
Copy the hooks from `hooks/hooks.json` to your `~/.claude/settings.json`.
|
||||
|
||||
#### Configure MCPs
|
||||
|
||||
Copy desired MCP server definitions from `mcp-configs/mcp-servers.json` into your official Claude Code config in `~/.claude/settings.json`, or into a project-scoped `.mcp.json` if you want repo-local MCP access.
|
||||
|
||||
If you already run your own copies of ECC-bundled MCPs, set:
|
||||
|
||||
```bash
|
||||
export ECC_DISABLED_MCPS="github,context7,exa,playwright,sequential-thinking,memory"
|
||||
```
|
||||
|
||||
ECC-managed install and Codex sync flows will skip or remove those bundled servers instead of re-adding duplicates.
|
||||
|
||||
**Important:** Replace `YOUR_*_HERE` placeholders with your actual API keys.
|
||||
|
||||
---
|
||||
@ -834,8 +781,8 @@ Not sure where to start? Use this quick reference. Skills are the canonical work
|
||||
|
||||
| I want to... | Use this command | Agent used |
|
||||
|--------------|-----------------|------------|
|
||||
| Plan a new feature | `/ecc:plan "Add auth"` | planner |
|
||||
| Design system architecture | `/ecc:plan` + architect agent | architect |
|
||||
| Plan a new feature | `/everything-claude-code:plan "Add auth"` | planner |
|
||||
| Design system architecture | `/everything-claude-code:plan` + architect agent | architect |
|
||||
| Write code with tests first | `/tdd` | tdd-guide |
|
||||
| Review code I just wrote | `/code-review` | code-reviewer |
|
||||
| Fix a failing build | `/build-fix` | build-error-resolver |
|
||||
@ -854,7 +801,7 @@ Slash forms below are shown because they are still the fastest familiar entrypoi
|
||||
|
||||
**Starting a new feature:**
|
||||
```
|
||||
/ecc:plan "Add user authentication with OAuth"
|
||||
/everything-claude-code:plan "Add user authentication with OAuth"
|
||||
→ planner creates implementation blueprint
|
||||
/tdd → tdd-guide enforces write-tests-first
|
||||
/code-review → code-reviewer checks your work
|
||||
@ -882,7 +829,7 @@ Slash forms below are shown because they are still the fastest familiar entrypoi
|
||||
<summary><b>How do I check which agents/commands are installed?</b></summary>
|
||||
|
||||
```bash
|
||||
/plugin list ecc@ecc
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
This shows all available agents, commands, and skills from the plugin.
|
||||
@ -958,10 +905,9 @@ Each component is fully independent.
|
||||
Yes. ECC is cross-platform:
|
||||
- **Cursor**: Pre-translated configs in `.cursor/`. See [Cursor IDE Support](#cursor-ide-support).
|
||||
- **Gemini CLI**: Experimental project-local support via `.gemini/GEMINI.md` and shared installer plumbing.
|
||||
- **OpenCode**: Full plugin support in `.opencode/`. See [OpenCode Support](#opencode-support).
|
||||
- **OpenCode**: Full plugin support in `.opencode/`. See [OpenCode Support](#-opencode-support).
|
||||
- **Codex**: First-class support for both macOS app and CLI, with adapter drift guards and SessionStart fallback. See PR [#257](https://github.com/affaan-m/everything-claude-code/pull/257).
|
||||
- **Antigravity**: Tightly integrated setup for workflows, skills, and flattened rules in `.agent/`. See [Antigravity Guide](docs/ANTIGRAVITY-GUIDE.md).
|
||||
- **Non-native harnesses**: Manual fallback path for Grok and similar interfaces. See [Manual Adaptation Guide](docs/MANUAL-ADAPTATION-GUIDE.md).
|
||||
- **Claude Code**: Native — this is the primary target.
|
||||
</details>
|
||||
|
||||
@ -1112,8 +1058,8 @@ Codex macOS app:
|
||||
|-----------|-------|---------|
|
||||
| Config | 1 | `.codex/config.toml` — top-level approvals/sandbox/web_search, MCP servers, notifications, profiles |
|
||||
| AGENTS.md | 2 | Root (universal) + `.codex/AGENTS.md` (Codex-specific supplement) |
|
||||
| Skills | 30 | `.agents/skills/` — SKILL.md + agents/openai.yaml per skill |
|
||||
| MCP Servers | 6 | GitHub, Context7, Exa, Memory, Playwright, Sequential Thinking (7 with Supabase via `--update-mcp` sync) |
|
||||
| Skills | 16 | `.agents/skills/` — SKILL.md + agents/openai.yaml per skill |
|
||||
| MCP Servers | 6 | Supabase, Playwright, Context7, GitHub, Memory, Sequential Thinking (auto-merged via add-only sync) |
|
||||
| Profiles | 2 | `strict` (read-only sandbox) and `yolo` (full auto-approve) |
|
||||
| Agent Roles | 3 | `.codex/agents/` — explorer, reviewer, docs-researcher |
|
||||
|
||||
@ -1123,36 +1069,22 @@ Skills at `.agents/skills/` are auto-loaded by Codex:
|
||||
|
||||
| Skill | Description |
|
||||
|-------|-------------|
|
||||
| api-design | REST API design patterns |
|
||||
| article-writing | Long-form writing from notes and voice references |
|
||||
| backend-patterns | API design, database, caching |
|
||||
| brand-voice | Source-derived writing style profiles from real content |
|
||||
| bun-runtime | Bun as runtime, package manager, bundler, and test runner |
|
||||
| claude-api | Anthropic Claude API patterns for Python and TypeScript |
|
||||
| tdd-workflow | Test-driven development with 80%+ coverage |
|
||||
| security-review | Comprehensive security checklist |
|
||||
| coding-standards | Universal coding standards |
|
||||
| content-engine | Platform-native social content and repurposing |
|
||||
| crosspost | Multi-platform content distribution across X, LinkedIn, Threads |
|
||||
| deep-research | Multi-source research with synthesis and source attribution |
|
||||
| dmux-workflows | Multi-agent orchestration using tmux pane manager |
|
||||
| documentation-lookup | Up-to-date library and framework docs via Context7 MCP |
|
||||
| e2e-testing | Playwright E2E tests |
|
||||
| eval-harness | Eval-driven development |
|
||||
| everything-claude-code | Development conventions and patterns for the project |
|
||||
| exa-search | Neural search via Exa MCP for web, code, company research |
|
||||
| fal-ai-media | Unified media generation for images, video, and audio |
|
||||
| frontend-patterns | React/Next.js patterns |
|
||||
| frontend-slides | HTML presentations, PPTX conversion, visual style exploration |
|
||||
| article-writing | Long-form writing from notes and voice references |
|
||||
| content-engine | Platform-native social content and repurposing |
|
||||
| market-research | Source-attributed market and competitor research |
|
||||
| investor-materials | Decks, memos, models, and one-pagers |
|
||||
| investor-outreach | Personalized outreach, follow-ups, and intro blurbs |
|
||||
| market-research | Source-attributed market and competitor research |
|
||||
| mcp-server-patterns | Build MCP servers with Node/TypeScript SDK |
|
||||
| nextjs-turbopack | Next.js 16+ and Turbopack incremental bundling |
|
||||
| security-review | Comprehensive security checklist |
|
||||
| backend-patterns | API design, database, caching |
|
||||
| e2e-testing | Playwright E2E tests |
|
||||
| eval-harness | Eval-driven development |
|
||||
| strategic-compact | Context management |
|
||||
| tdd-workflow | Test-driven development with 80%+ coverage |
|
||||
| api-design | REST API design patterns |
|
||||
| verification-loop | Build, test, lint, typecheck, security |
|
||||
| video-editing | AI-assisted video editing workflows with FFmpeg and Remotion |
|
||||
| x-api | X/Twitter API integration for posting and analytics |
|
||||
|
||||
### Key Limitation
|
||||
|
||||
@ -1160,7 +1092,7 @@ Codex does **not yet provide Claude-style hook execution parity**. ECC enforceme
|
||||
|
||||
### Multi-Agent Support
|
||||
|
||||
Current Codex builds support stable multi-agent workflows.
|
||||
Current Codex builds support experimental multi-agent workflows.
|
||||
|
||||
- Enable `features.multi_agent = true` in `.codex/config.toml`
|
||||
- Define roles under `[agents.<name>]`
|
||||
@ -1197,9 +1129,9 @@ The configuration is automatically detected from `.opencode/opencode.json`.
|
||||
|
||||
| Feature | Claude Code | OpenCode | Status |
|
||||
|---------|-------------|----------|--------|
|
||||
| Agents | PASS: 47 agents | PASS: 12 agents | **Claude Code leads** |
|
||||
| Commands | PASS: 79 commands | PASS: 31 commands | **Claude Code leads** |
|
||||
| Skills | PASS: 181 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Agents | PASS: 38 agents | PASS: 12 agents | **Claude Code leads** |
|
||||
| Commands | PASS: 72 commands | PASS: 31 commands | **Claude Code leads** |
|
||||
| Skills | PASS: 156 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Hooks | PASS: 8 event types | PASS: 11 events | **OpenCode has more!** |
|
||||
| Rules | PASS: 29 rules | PASS: 13 instructions | **Claude Code leads** |
|
||||
| MCP Servers | PASS: 14 servers | PASS: Full | **Full parity** |
|
||||
@ -1306,9 +1238,9 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
|
||||
|
||||
| Feature | Claude Code | Cursor IDE | Codex CLI | OpenCode |
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **Agents** | 47 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
|
||||
| **Commands** | 79 | Shared | Instruction-based | 31 |
|
||||
| **Skills** | 181 | Shared | 10 (native format) | 37 |
|
||||
| **Agents** | 38 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
|
||||
| **Commands** | 72 | Shared | Instruction-based | 31 |
|
||||
| **Skills** | 156 | Shared | 10 (native format) | 37 |
|
||||
| **Hook Events** | 8 types | 15 types | None yet | 11 types |
|
||||
| **Hook Scripts** | 20+ scripts | 16 scripts (DRY adapter) | N/A | Plugin hooks |
|
||||
| **Rules** | 34 (common + lang) | 34 (YAML frontmatter) | Instruction-based | 13 instructions |
|
||||
@ -1434,18 +1366,6 @@ These configs work for my workflow. You should:
|
||||
|
||||
---
|
||||
|
||||
## Community Projects
|
||||
|
||||
Projects built on or inspired by Everything Claude Code:
|
||||
|
||||
| Project | Description |
|
||||
|---------|-------------|
|
||||
| [EVC](https://github.com/SaigonXIII/evc) | Marketing agent workspace — 42 commands for content operators, brand governance, and multi-channel publishing. [Visual overview](https://saigonxiii.github.io/evc). |
|
||||
|
||||
Built something with ECC? Open a PR to add it here.
|
||||
|
||||
---
|
||||
|
||||
## Sponsors
|
||||
|
||||
This project is free and open source. Sponsors help keep it maintained and growing.
|
||||
|
||||
492
README.zh-CN.md
492
README.zh-CN.md
@ -1,29 +1,20 @@
|
||||
# Everything Claude Code
|
||||
|
||||
[](https://github.com/affaan-m/everything-claude-code/stargazers)
|
||||
[](https://github.com/affaan-m/everything-claude-code/network/members)
|
||||
[](https://github.com/affaan-m/everything-claude-code/graphs/contributors)
|
||||
[](https://www.npmjs.com/package/ecc-universal)
|
||||
[](https://www.npmjs.com/package/ecc-agentshield)
|
||||
[](https://github.com/marketplace/ecc-tools)
|
||||
[](LICENSE)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> **140K+ stars** | **21K+ forks** | **170+ 贡献者** | **12+ 语言系统** | **Anthropic黑客松获胜者**
|
||||
|
||||
---
|
||||
|
||||
<div align="center">
|
||||
|
||||
**Language / 语言 / 語言 / Dil**
|
||||
**Language / 语言 / 語言**
|
||||
|
||||
[**English**](README.md) | [Português (Brasil)](docs/pt-BR/README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md) | [Türkçe](docs/tr/README.md)
|
||||
[**English**](README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md) | [한국어](docs/ko-KR/README.md)
|
||||
|
||||
</div>
|
||||
|
||||
@ -31,10 +22,7 @@
|
||||
|
||||
**来自 Anthropic 黑客马拉松获胜者的完整 Claude Code 配置集合。**
|
||||
|
||||
不止是配置文件，而是一整套完整系统：技能体系、本能行为、记忆优化、持续学习、安全扫描，以及研究优先的开发模式。
|
||||
包含可直接用于生产环境的智能体、技能模块、钩子、规则、MCP 配置，以及兼容传统命令的适配层——所有内容均经过 10 个多月高强度日常使用与真实产品开发迭代打磨而成。
|
||||
|
||||
可在 **Claude Code**、**Codex**、**Cursor**、**OpenCode**、**Gemini** 及其他 AI 智能体框架中通用。
|
||||
生产级代理、技能、钩子、命令、规则和 MCP 配置，经过 10 多个月构建真实产品的密集日常使用而演化。
|
||||
|
||||
---
|
||||
|
||||
@ -44,26 +32,20 @@
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td width="33%">
|
||||
<td width="50%">
|
||||
<a href="https://x.com/affaanmustafa/status/2012378465664745795">
|
||||
<img src="https://github.com/user-attachments/assets/1a471488-59cc-425b-8345-5245c7efbcef" alt="The Shorthand Guide to Everything Claude Code" />
|
||||
</a>
|
||||
</td>
|
||||
<td width="33%">
|
||||
<td width="50%">
|
||||
<a href="https://x.com/affaanmustafa/status/2014040193557471352">
|
||||
<img src="https://github.com/user-attachments/assets/c9ca43bc-b149-427f-b551-af6840c368f0" alt="The Longform Guide to Everything Claude Code" />
|
||||
</a>
|
||||
</td>
|
||||
<td width="33%">
|
||||
<a href="https://x.com/affaanmustafa/status/2033263813387223421">
|
||||
<img src="./assets/images/security/security-guide-header.png" alt="The Shorthand Guide to Everything Agentic Security" />
|
||||
</a>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="center"><b>精简指南</b><br/>设置、基础、理念。<b>先读这个。</b></td>
|
||||
<td align="center"><b>详细指南</b><br/>Token 优化、内存持久化、评估、并行化。</td>
|
||||
<td align="center"><b>安全指南</b><br/>攻击向量、沙箱技术、数据净化、CVE漏洞、Agent防护</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@ -78,31 +60,18 @@
|
||||
|
||||
---
|
||||
|
||||
## 最新动态
|
||||
|
||||
### v1.10.0 — 表面同步、运营工作流与 ECC 2.0 Alpha（2026年4月）
|
||||
|
||||
- **公共表面已与真实仓库同步** —— 元数据、目录数量、插件清单以及安装文档现在都与实际开源表面保持一致。
|
||||
- **运营与外向型工作流扩展** —— `brand-voice`、`social-graph-ranker`、`customer-billing-ops`、`google-workspace-ops` 等运营型 skill 已纳入同一系统。
|
||||
- **媒体与发布工具补齐** —— `manim-video`、`remotion-video-creation` 以及社媒发布能力让技术讲解和发布流程直接在同一仓库内完成。
|
||||
- **框架与产品表面继续扩展** —— `nestjs-patterns`、更完整的 Codex/OpenCode 安装表面，以及跨 harness 打包改进，让仓库不再局限于 Claude Code。
|
||||
- **ECC 2.0 alpha 已进入仓库** —— `ecc2/` 下的 Rust 控制层现已可在本地构建，并提供 `dashboard`、`start`、`sessions`、`status`、`stop`、`resume` 与 `daemon` 命令。
|
||||
- **生态加固持续推进** —— AgentShield、ECC Tools 成本控制、计费门户工作与网站刷新仍围绕核心插件持续交付。
|
||||
|
||||
## 快速开始
|
||||
|
||||
在 2 分钟内快速上手：
|
||||
|
||||
### 第一步：安装插件
|
||||
|
||||
> 注意：插件安装方式较为便捷，但如果你的 Claude Code 版本无法正常解析自托管市场条目，建议使用下方的开源安装脚本，稳定性更高。
|
||||
|
||||
```bash
|
||||
# 添加市场
|
||||
/plugin marketplace add affaan-m/everything-claude-code
|
||||
|
||||
# 安装插件
|
||||
/plugin install ecc@ecc
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
### 第二步：安装规则（必需）
|
||||
@ -112,57 +81,32 @@
|
||||
```bash
|
||||
# 首先克隆仓库
|
||||
git clone https://github.com/affaan-m/everything-claude-code.git
|
||||
cd everything-claude-code
|
||||
|
||||
# 安装依赖（选择你常用的包管理器）
|
||||
npm install # 或：pnpm install | yarn install | bun install
|
||||
|
||||
# macOS/Linux 系统
|
||||
|
||||
# 推荐方式：完整安装（完整配置文件）
|
||||
./install.sh --profile full
|
||||
|
||||
# 或仅为指定编程语言安装
|
||||
./install.sh typescript # 也可安装 python、golang、swift、php
|
||||
# ./install.sh typescript python golang swift php
|
||||
# ./install.sh --target cursor typescript
|
||||
# ./install.sh --target antigravity typescript
|
||||
# ./install.sh --target gemini --profile full
|
||||
# 复制规则目录（通用 + 语言特定）
|
||||
mkdir -p ~/.claude/rules
|
||||
cp -r everything-claude-code/rules/common ~/.claude/rules/
|
||||
cp -r everything-claude-code/rules/typescript ~/.claude/rules/ # 选择你的技术栈
|
||||
cp -r everything-claude-code/rules/python ~/.claude/rules/
|
||||
cp -r everything-claude-code/rules/golang ~/.claude/rules/
|
||||
cp -r everything-claude-code/rules/perl ~/.claude/rules/
|
||||
```
|
||||
|
||||
```powershell
|
||||
# Windows 系统（PowerShell）
|
||||
|
||||
# 推荐方式：完整安装（完整配置文件）
|
||||
.\install.ps1 --profile full
|
||||
|
||||
# 或仅为指定编程语言安装
|
||||
.\install.ps1 typescript # 也可安装 python、golang、swift、php
|
||||
# .\install.ps1 typescript python golang swift php
|
||||
# .\install.ps1 --target cursor typescript
|
||||
# .\install.ps1 --target antigravity typescript
|
||||
# .\install.ps1 --target gemini --profile full
|
||||
|
||||
# 通过 npm 安装的兼容入口，支持全平台使用
|
||||
npx ecc-install typescript
|
||||
```
|
||||
|
||||
如需手动安装说明，请查看 `rules/` 文件夹中的 README 文档。手动复制规则文件时，请直接复制**整个语言目录**（例如 `rules/common` 或 `rules/golang`），而非目录内的单个文件，以保证相对路径引用正常、文件名不会冲突。
|
||||
复制规则时，请复制整个目录（例如 `rules/common`、`rules/golang`），而不是复制目录内的文件；这样可以保留相对引用，并避免不同规则集中的同名文件互相覆盖。
|
||||
|
||||
### 第三步：开始使用
|
||||
|
||||
```bash
|
||||
# 尝试一个命令（插件安装使用命名空间形式）
|
||||
/ecc:plan "添加用户认证"
|
||||
/everything-claude-code:plan "添加用户认证"
|
||||
|
||||
# 手动安装（选项2）使用简短形式：
|
||||
# /plan "添加用户认证"
|
||||
|
||||
# 查看可用命令
|
||||
/plugin list ecc@ecc
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
**完成！** 你现在可以使用 47 个代理、181 个技能和 79 个命令。
|
||||
**完成！** 你现在可以使用 38 个代理、156 个技能和 72 个命令。
|
||||
|
||||
### multi-* 命令需要额外配置
|
||||
|
||||
@ -182,7 +126,7 @@ npx ecc-install typescript
|
||||
|
||||
## 跨平台支持
|
||||
|
||||
该插件现已**全面支持 Windows、macOS 和 Linux**，并与主流 IDE（Cursor、OpenCode、Antigravity）及命令行工具深度集成。所有钩子与脚本均已使用 Node.js 重写，以实现最佳兼容性。
|
||||
此插件现在完全支持 **Windows、macOS 和 Linux**。所有钩子和脚本都已用 Node.js 重写，以实现最大的兼容性。
|
||||
|
||||
### 包管理器检测
|
||||
|
||||
@ -213,18 +157,6 @@ node scripts/setup-package-manager.js --detect
|
||||
|
||||
或在 Claude Code 中使用 `/setup-pm` 命令。
|
||||
|
||||
### 钩子运行时控制
|
||||
|
||||
使用运行时标记调整严格度或临时禁用特定钩子：
|
||||
|
||||
```bash
|
||||
# 钩子严格度配置文件（默认值：standard）
|
||||
export ECC_HOOK_PROFILE=standard
|
||||
|
||||
# 以英文逗号分隔的钩子 ID 列表，用于禁用指定钩子
|
||||
export ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 里面有什么
|
||||
@ -233,198 +165,113 @@ export ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck"
|
||||
|
||||
```
|
||||
everything-claude-code/
|
||||
|-- .claude-plugin/ # 插件与应用商店清单
|
||||
| |-- plugin.json # 插件元数据与组件路径
|
||||
| |-- marketplace.json # 用于 /plugin marketplace add 的自托管应用商店目录
|
||||
|-- .claude-plugin/ # 插件和市场清单
|
||||
| |-- plugin.json # 插件元数据和组件路径
|
||||
| |-- marketplace.json # /plugin marketplace add 的市场目录
|
||||
|
|
||||
|-- agents/ # 36 个专用子智能体，用于任务委派
|
||||
|-- agents/ # 用于委托的专业子代理
|
||||
| |-- planner.md # 功能实现规划
|
||||
| |-- architect.md # 系统架构设计决策
|
||||
| |-- architect.md # 系统设计决策
|
||||
| |-- tdd-guide.md # 测试驱动开发
|
||||
| |-- code-reviewer.md # 代码质量与安全审查
|
||||
| |-- code-reviewer.md # 质量和安全审查
|
||||
| |-- security-reviewer.md # 漏洞分析
|
||||
| |-- build-error-resolver.md # 构建错误修复
|
||||
| |-- e2e-runner.md # Playwright 端到端测试
|
||||
| |-- refactor-cleaner.md # 无效代码清理
|
||||
| |-- doc-updater.md # 文档同步更新
|
||||
| |-- docs-lookup.md # 文档 / API 查阅
|
||||
| |-- chief-of-staff.md # 沟通梳理与文稿起草
|
||||
| |-- loop-operator.md # 自主循环执行
|
||||
| |-- harness-optimizer.md # 执行框架配置调优
|
||||
| |-- cpp-reviewer.md # C++ 代码审查
|
||||
| |-- cpp-build-resolver.md # C++ 构建错误修复
|
||||
| |-- go-reviewer.md # Go 代码审查
|
||||
| |-- go-build-resolver.md # Go 构建错误修复
|
||||
| |-- python-reviewer.md # Python 代码审查
|
||||
| |-- database-reviewer.md # 数据库 / Supabase 审查
|
||||
| |-- typescript-reviewer.md # TypeScript/JavaScript 代码审查
|
||||
| |-- java-reviewer.md # Java/Spring Boot 代码审查
|
||||
| |-- java-build-resolver.md # Java/Maven/Gradle 构建错误修复
|
||||
| |-- kotlin-reviewer.md # Kotlin/Android/KMP 代码审查
|
||||
| |-- kotlin-build-resolver.md # Kotlin/Gradle 构建错误修复
|
||||
| |-- rust-reviewer.md # Rust 代码审查
|
||||
| |-- rust-build-resolver.md # Rust 构建错误修复
|
||||
| |-- pytorch-build-resolver.md # PyTorch/CUDA 训练错误修复
|
||||
| |-- build-error-resolver.md
|
||||
| |-- e2e-runner.md # Playwright E2E 测试
|
||||
| |-- refactor-cleaner.md # 死代码清理
|
||||
| |-- doc-updater.md # 文档同步
|
||||
| |-- go-reviewer.md # Go 代码审查（新增）
|
||||
| |-- go-build-resolver.md # Go 构建错误解决（新增）
|
||||
|
|
||||
|-- skills/ # 工作流定义与领域知识库
|
||||
| |-- coding-standards/ # 各语言最佳实践
|
||||
| |-- clickhouse-io/ # ClickHouse 分析、查询与数据工程
|
||||
| |-- backend-patterns/ # API、数据库、缓存设计模式
|
||||
| |-- frontend-patterns/ # React、Next.js 开发模式
|
||||
| |-- frontend-slides/ # HTML 幻灯片与 PPTX 转网页工作流（新增）
|
||||
| |-- article-writing/ # 长文本写作，保留指定风格、避免通用 AI 腔调（新增）
|
||||
| |-- content-engine/ # 多平台社交内容创作与复用工作流（新增）
|
||||
| |-- market-research/ # 带来源引用的市场、竞品与投资方研究（新增）
|
||||
| |-- investor-materials/ # 融资路演 PPT、单页摘要、备忘录与财务模型（新增）
|
||||
| |-- investor-outreach/ # 定制化融资触达与跟进（新增）
|
||||
| |-- continuous-learning/ # 从会话中自动提取模式（长文本指南）
|
||||
| |-- continuous-learning-v2/ # 基于本能的学习，附带置信度评分
|
||||
| |-- iterative-retrieval/ # 为子智能体渐进式优化上下文
|
||||
| |-- strategic-compact/ # 手动上下文精简建议（长文本指南）
|
||||
| |-- tdd-workflow/ # 测试驱动开发方法论
|
||||
|-- skills/ # 工作流定义和领域知识
|
||||
| |-- coding-standards/ # 语言最佳实践
|
||||
| |-- backend-patterns/ # API、数据库、缓存模式
|
||||
| |-- frontend-patterns/ # React、Next.js 模式
|
||||
| |-- continuous-learning/ # 从会话中自动提取模式（详细指南）
|
||||
| |-- continuous-learning-v2/ # 基于直觉的学习与置信度评分
|
||||
| |-- iterative-retrieval/ # 子代理的渐进式上下文细化
|
||||
| |-- strategic-compact/ # 手动压缩建议（详细指南）
|
||||
| |-- tdd-workflow/ # TDD 方法论
|
||||
| |-- security-review/ # 安全检查清单
|
||||
| |-- eval-harness/ # 验证循环评估（长文本指南）
|
||||
| |-- verification-loop/ # 持续验证机制（长文本指南）
|
||||
| |-- videodb/ # 音视频采集、检索、编辑、生成与推流（新增）
|
||||
| |-- golang-patterns/ # Go 语言惯用写法与最佳实践
|
||||
| |-- golang-testing/ # Go 测试模式、TDD 与基准测试
|
||||
| |-- cpp-coding-standards/ # 遵循 C++ Core Guidelines 的编码规范（新增）
|
||||
| |-- cpp-testing/ # 基于 GoogleTest、CMake/CTest 的 C++ 测试（新增）
|
||||
| |-- django-patterns/ # Django 模式、模型与视图（新增）
|
||||
| |-- django-security/ # Django 安全最佳实践（新增）
|
||||
| |-- django-tdd/ # Django TDD 工作流（新增）
|
||||
| |-- django-verification/ # Django 验证循环（新增）
|
||||
| |-- laravel-patterns/ # Laravel 架构模式（新增）
|
||||
| |-- laravel-security/ # Laravel 安全最佳实践（新增）
|
||||
| |-- laravel-tdd/ # Laravel TDD 工作流（新增）
|
||||
| |-- laravel-verification/ # Laravel 验证循环（新增）
|
||||
| |-- python-patterns/ # Python 惯用写法与最佳实践（新增）
|
||||
| |-- python-testing/ # 基于 pytest 的 Python 测试（新增）
|
||||
| |-- springboot-patterns/ # Java Spring Boot 模式（新增）
|
||||
| |-- springboot-security/ # Spring Boot 安全（新增）
|
||||
| |-- springboot-tdd/ # Spring Boot TDD（新增）
|
||||
| |-- springboot-verification/ # Spring Boot 验证（新增）
|
||||
| |-- configure-ecc/ # 交互式安装向导（新增）
|
||||
| |-- security-scan/ # 集成 AgentShield 安全审计（新增）
|
||||
| |-- java-coding-standards/ # Java 编码规范（新增）
|
||||
| |-- jpa-patterns/ # JPA/Hibernate 模式（新增）
|
||||
| |-- postgres-patterns/ # PostgreSQL 优化模式（新增）
|
||||
| |-- nutrient-document-processing/ # 基于 Nutrient API 的文档处理（新增）
|
||||
| |-- docs/examples/project-guidelines-template.md # 项目专属技能模板
|
||||
| |-- database-migrations/ # 数据库迁移模式（Prisma、Drizzle、Django、Go）（新增）
|
||||
| |-- api-design/ # REST API 设计、分页、错误响应（新增）
|
||||
| |-- deployment-patterns/ # CI/CD、Docker、健康检查、回滚（新增）
|
||||
| |-- docker-patterns/ # Docker Compose、网络、数据卷、容器安全（新增）
|
||||
| |-- e2e-testing/ # Playwright E2E 模式与页面对象模型（新增）
|
||||
| |-- content-hash-cache-pattern/ # 用于文件处理的 SHA-256 内容哈希缓存（新增）
|
||||
| |-- cost-aware-llm-pipeline/ # LLM 成本优化、模型路由、预算跟踪（新增）
|
||||
| |-- regex-vs-llm-structured-text/ # 文本解析：正则与 LLM 选型决策框架（新增）
|
||||
| |-- swift-actor-persistence/ # 基于 Actor 的 Swift 线程安全数据持久化（新增）
|
||||
| |-- swift-protocol-di-testing/ # 基于协议的依赖注入，实现可测试 Swift 代码（新增）
|
||||
| |-- search-first/ # 先调研再编码工作流（新增）
|
||||
| |-- skill-stocktake/ # 技能与命令质量审计（新增）
|
||||
| |-- liquid-glass-design/ # iOS 26 Liquid Glass 设计系统（新增）
|
||||
| |-- foundation-models-on-device/ # 基于 Apple FoundationModels 的端侧大模型（新增）
|
||||
| |-- swift-concurrency-6-2/ # Swift 6.2 简洁并发编程（新增）
|
||||
| |-- perl-patterns/ # 现代 Perl 5.36+ 惯用写法与最佳实践（新增）
|
||||
| |-- perl-security/ # Perl 安全模式、污点模式、安全 I/O（新增）
|
||||
| |-- perl-testing/ # 基于 Test2::V0、prove、Devel::Cover 的 Perl TDD（新增）
|
||||
| |-- autonomous-loops/ # 自主循环模式：顺序流水线、PR 循环、DAG 编排（新增）
|
||||
| |-- plankton-code-quality/ # 基于 Plankton 钩子的实时代码质量管控（新增）
|
||||
| |-- eval-harness/ # 验证循环评估（详细指南）
|
||||
| |-- verification-loop/ # 持续验证（详细指南）
|
||||
| |-- golang-patterns/ # Go 惯用语和最佳实践（新增）
|
||||
| |-- golang-testing/ # Go 测试模式、TDD、基准测试（新增）
|
||||
| |-- cpp-testing/ # C++ 测试模式、GoogleTest、CMake/CTest（新增）
|
||||
| |-- perl-patterns/ # 现代 Perl 5.36+ 惯用语和最佳实践（新增）
|
||||
| |-- perl-security/ # Perl 安全模式、污染模式、安全 I/O（新增）
|
||||
| |-- perl-testing/ # 使用 Test2::V0、prove、Devel::Cover 的 Perl TDD（新增）
|
||||
|
|
||||
|-- commands/ # 传统斜杠命令兼容层；优先使用 skills/
|
||||
|-- commands/ # 用于快速执行的斜杠命令
|
||||
| |-- tdd.md # /tdd - 测试驱动开发
|
||||
| |-- plan.md # /plan - 实现规划
|
||||
| |-- e2e.md # /e2e - 生成端到端测试
|
||||
| |-- code-review.md # /code-review - 代码质量审查
|
||||
| |-- e2e.md # /e2e - E2E 测试生成
|
||||
| |-- code-review.md # /code-review - 质量审查
|
||||
| |-- build-fix.md # /build-fix - 修复构建错误
|
||||
| |-- refactor-clean.md # /refactor-clean - 清理无效代码
|
||||
| |-- learn.md # /learn - 会话中提取模式（长文本指南）
|
||||
| |-- learn-eval.md # /learn-eval - 提取、评估并保存模式（新增）
|
||||
| |-- checkpoint.md # /checkpoint - 保存验证状态（长文本指南）
|
||||
| |-- verify.md # /verify - 运行验证循环（长文本指南）
|
||||
| |-- refactor-clean.md # /refactor-clean - 死代码移除
|
||||
| |-- learn.md # /learn - 会话中提取模式（详细指南）
|
||||
| |-- checkpoint.md # /checkpoint - 保存验证状态（详细指南）
|
||||
| |-- verify.md # /verify - 运行验证循环（详细指南）
|
||||
| |-- setup-pm.md # /setup-pm - 配置包管理器
|
||||
| |-- go-review.md # /go-review - Go 代码审查（新增）
|
||||
| |-- go-test.md # /go-test - Go TDD 工作流（新增）
|
||||
| |-- go-build.md # /go-build - 修复 Go 构建错误（新增）
|
||||
| |-- skill-create.md # /skill-create - 从 Git 历史生成技能（新增）
|
||||
| |-- instinct-status.md # /instinct-status - 查看已学习本能（新增）
|
||||
| |-- instinct-import.md # /instinct-import - 导入本能（新增）
|
||||
| |-- instinct-export.md # /instinct-export - 导出本能（新增）
|
||||
| |-- evolve.md # /evolve - 将本能聚类为技能
|
||||
| |-- prune.md # /prune - 删除过期待处理本能（新增）
|
||||
| |-- pm2.md # /pm2 - PM2 服务生命周期管理（新增）
|
||||
| |-- multi-plan.md # /multi-plan - 多智能体任务拆解（新增）
|
||||
| |-- multi-execute.md # /multi-execute - 多智能体工作流编排（新增）
|
||||
| |-- multi-backend.md # /multi-backend - 后端多服务编排（新增）
|
||||
| |-- multi-frontend.md # /multi-frontend - 前端多服务编排（新增）
|
||||
| |-- multi-workflow.md # /multi-workflow - 通用多服务工作流（新增）
|
||||
| |-- orchestrate.md # /orchestrate - 多智能体协同调度
|
||||
| |-- sessions.md # /sessions - 会话历史管理
|
||||
| |-- eval.md # /eval - 按标准评估
|
||||
| |-- test-coverage.md # /test-coverage - 测试覆盖率分析
|
||||
| |-- update-docs.md # /update-docs - 更新文档
|
||||
| |-- update-codemaps.md # /update-codemaps - 更新代码映射
|
||||
| |-- python-review.md # /python-review - Python 代码审查（新增）
|
||||
| |-- skill-create.md # /skill-create - 从 git 历史生成技能（新增）
|
||||
| |-- instinct-status.md # /instinct-status - 查看学习的直觉（新增）
|
||||
| |-- instinct-import.md # /instinct-import - 导入直觉（新增）
|
||||
| |-- instinct-export.md # /instinct-export - 导出直觉（新增）
|
||||
| |-- evolve.md # /evolve - 将直觉聚类到技能中（新增）
|
||||
|
|
||||
|-- rules/ # 必须遵守的规范（复制到 ~/.claude/rules/）
|
||||
| |-- README.md # 结构概览与安装指南
|
||||
| |-- common/ # 与语言无关的通用原则
|
||||
| | |-- coding-style.md # 不可变性、文件组织规范
|
||||
|-- rules/ # 始终遵循的指南（复制到 ~/.claude/rules/）
|
||||
| |-- README.md # 结构概述和安装指南
|
||||
| |-- common/ # 与语言无关的原则
|
||||
| | |-- coding-style.md # 不可变性、文件组织
|
||||
| | |-- git-workflow.md # 提交格式、PR 流程
|
||||
| | |-- testing.md # TDD、80% 覆盖率要求
|
||||
| | |-- performance.md # 模型选型、上下文管理
|
||||
| | |-- patterns.md # 设计模式、项目骨架
|
||||
| | |-- performance.md # 模型选择、上下文管理
|
||||
| | |-- patterns.md # 设计模式、骨架项目
|
||||
| | |-- hooks.md # 钩子架构、TodoWrite
|
||||
| | |-- agents.md # 子智能体委派时机
|
||||
| | |-- security.md # 强制安全检查
|
||||
| |-- typescript/ # TypeScript/JavaScript 专属规范
|
||||
| |-- python/ # Python 专属规范
|
||||
| |-- golang/ # Go 专属规范
|
||||
| |-- swift/ # Swift 专属规范
|
||||
| |-- php/ # PHP 专属规范（新增）
|
||||
| | |-- agents.md # 何时委托给子代理
|
||||
| | |-- security.md # 强制性安全检查
|
||||
| |-- typescript/ # TypeScript/JavaScript 特定
|
||||
| |-- python/ # Python 特定
|
||||
| |-- golang/ # Go 特定
|
||||
| |-- perl/ # Perl 特定（新增）
|
||||
|
|
||||
|-- hooks/ # 基于触发器的自动化逻辑
|
||||
| |-- README.md # 钩子文档、使用示例与自定义指南
|
||||
| |-- hooks.json # 全部钩子配置（PreToolUse、PostToolUse、Stop 等）
|
||||
| |-- memory-persistence/ # 会话生命周期钩子（长文本指南）
|
||||
| |-- strategic-compact/ # 上下文精简建议（长文本指南）
|
||||
|-- hooks/ # 基于触发器的自动化
|
||||
| |-- hooks.json # 所有钩子配置（PreToolUse、PostToolUse、Stop 等）
|
||||
| |-- memory-persistence/ # 会话生命周期钩子（详细指南）
|
||||
| |-- strategic-compact/ # 压缩建议（详细指南）
|
||||
|
|
||||
|-- scripts/ # 跨平台 Node.js 脚本（新增）
|
||||
| |-- lib/ # 通用工具库
|
||||
| | |-- utils.js # 跨平台文件 / 路径 / 系统工具
|
||||
| | |-- package-manager.js # 包管理器检测与选择
|
||||
| |-- lib/ # 共享工具
|
||||
| | |-- utils.js # 跨平台文件/路径/系统工具
|
||||
| | |-- package-manager.js # 包管理器检测和选择
|
||||
| |-- hooks/ # 钩子实现
|
||||
| | |-- session-start.js # 会话启动时加载上下文
|
||||
| | |-- session-start.js # 会话开始时加载上下文
|
||||
| | |-- session-end.js # 会话结束时保存状态
|
||||
| | |-- pre-compact.js # 上下文精简前状态保存
|
||||
| | |-- suggest-compact.js # 策略性精简建议
|
||||
| | |-- pre-compact.js # 压缩前状态保存
|
||||
| | |-- suggest-compact.js # 战略性压缩建议
|
||||
| | |-- evaluate-session.js # 从会话中提取模式
|
||||
| |-- setup-package-manager.js # 交互式包管理器设置
|
||||
| |-- setup-package-manager.js # 交互式 PM 设置
|
||||
|
|
||||
|-- tests/ # 测试套件（新增）
|
||||
| |-- lib/ # 工具库测试
|
||||
| |-- lib/ # 库测试
|
||||
| |-- hooks/ # 钩子测试
|
||||
| |-- run-all.js # 运行全部测试
|
||||
| |-- run-all.js # 运行所有测试
|
||||
|
|
||||
|-- contexts/ # 动态注入的系统提示上下文（长文本指南）
|
||||
|-- contexts/ # 动态系统提示注入上下文（详细指南）
|
||||
| |-- dev.md # 开发模式上下文
|
||||
| |-- review.md # 代码审查模式上下文
|
||||
| |-- research.md # 研究 / 探索模式上下文
|
||||
| |-- research.md # 研究/探索模式上下文
|
||||
|
|
||||
|-- examples/ # 配置与会话示例
|
||||
| |-- CLAUDE.md # 项目级配置示例
|
||||
| |-- user-CLAUDE.md # 用户级配置示例
|
||||
| |-- saas-nextjs-CLAUDE.md # 真实 SaaS 项目（Next.js + Supabase + Stripe）
|
||||
| |-- go-microservice-CLAUDE.md # 真实 Go 微服务（gRPC + PostgreSQL）
|
||||
| |-- django-api-CLAUDE.md # 真实 Django REST API（DRF + Celery）
|
||||
| |-- laravel-api-CLAUDE.md # 真实 Laravel API（PostgreSQL + Redis）（新增）
|
||||
| |-- rust-api-CLAUDE.md # 真实 Rust API（Axum + SQLx + PostgreSQL）（新增）
|
||||
|-- examples/ # 示例配置和会话
|
||||
| |-- CLAUDE.md # 示例项目级配置
|
||||
| |-- user-CLAUDE.md # 示例用户级配置
|
||||
|
|
||||
|-- mcp-configs/ # MCP 服务端配置
|
||||
| |-- mcp-servers.json # GitHub、Supabase、Vercel、Railway 等配置
|
||||
|-- mcp-configs/ # MCP 服务器配置
|
||||
| |-- mcp-servers.json # GitHub、Supabase、Vercel、Railway 等
|
||||
|
|
||||
|-- marketplace.json # 自托管应用商店配置（用于 /plugin marketplace add）
|
||||
|-- marketplace.json # 自托管市场配置（用于 /plugin marketplace add）
|
||||
```
|
||||
|
||||
---
|
||||
@ -464,36 +311,6 @@ everything-claude-code/
|
||||
- **直觉集合** - 用于 continuous-learning-v2
|
||||
- **模式提取** - 从你的提交历史中学习
|
||||
|
||||
### AgentShield — 安全审计工具
|
||||
|
||||
> 于 Claude Code 黑客松（Cerebral Valley x Anthropic，2026 年 2 月）开发完成。包含 1282 项测试、98% 覆盖率、102 条静态分析规则。
|
||||
|
||||
扫描你的 Claude Code 配置，检测漏洞、错误配置与注入风险。
|
||||
|
||||
```bash
|
||||
# 快速扫描（无需安装）
|
||||
npx ecc-agentshield scan
|
||||
|
||||
# 自动修复安全问题
|
||||
npx ecc-agentshield scan --fix
|
||||
|
||||
# 调用 3 个 Opus 4.6 智能体进行深度分析
|
||||
npx ecc-agentshield scan --opus --stream
|
||||
|
||||
# 从零生成安全配置
|
||||
npx ecc-agentshield init
|
||||
```
|
||||
|
||||
**扫描范围：** CLAUDE.md、settings.json、MCP 配置、钩子、智能体定义与技能模块，覆盖 5 大类别 —— 密钥检测（14 种模式）、权限审计、钩子注入分析、MCP 服务风险评估、智能体配置审查。
|
||||
|
||||
**`--opus` 参数**：启动 3 个 Claude Opus 4.6 智能体组成红队/蓝队/审计管道。攻击者寻找利用链，防御者评估防护机制，审计者综合生成优先级风险报告。采用对抗推理，而非单纯模式匹配。
|
||||
|
||||
**输出格式：** 终端（彩色等级 A-F）、JSON（CI 流水线）、Markdown、HTML。发现严重问题时返回退出码 2，可用于构建门禁。
|
||||
|
||||
在 Claude Code 中使用 `/security-scan` 运行，或通过 [GitHub Action](https://github.com/affaan-m/agentshield) 集成到 CI。
|
||||
|
||||
[GitHub](https://github.com/affaan-m/agentshield) | [npm](https://www.npmjs.com/package/ecc-agentshield)
|
||||
|
||||
### 持续学习 v2
|
||||
|
||||
基于直觉的学习系统自动学习你的模式：
|
||||
@ -511,30 +328,6 @@ npx ecc-agentshield init
|
||||
|
||||
---
|
||||
|
||||
## 环境要求
|
||||
|
||||
### Claude Code 命令行版本
|
||||
**最低版本：v2.1.0 或更高**
|
||||
|
||||
由于插件系统处理钩子的机制发生变更，本插件要求 Claude Code CLI 版本不低于 v2.1.0。
|
||||
|
||||
查看当前版本：
|
||||
```bash
|
||||
claude --version
|
||||
```
|
||||
|
||||
### 重要提示：钩子自动加载机制
|
||||
> 警告：**贡献者请注意**：请勿在 `.claude-plugin/plugin.json` 中添加 `"hooks"` 字段。回归测试已强制禁止该操作。
|
||||
|
||||
Claude Code v2.1+ 会**按照约定自动加载**已安装插件中的 `hooks/hooks.json`。若在 `plugin.json` 中显式声明该文件，会触发重复检测错误：
|
||||
```
|
||||
检测到重复的钩子文件：./hooks/hooks.json 指向已加载的文件
|
||||
```
|
||||
|
||||
**历史说明**：该问题曾在本仓库中引发多次「修复-回滚」循环（[#29](https://github.com/affaan-m/everything-claude-code/issues/29)、[#52](https://github.com/affaan-m/everything-claude-code/issues/52)、[#103](https://github.com/affaan-m/everything-claude-code/issues/103)）。因 Claude Code 版本间行为变更导致混淆，现已添加回归测试，防止该问题再次出现。
|
||||
|
||||
---
|
||||
|
||||
## 安装
|
||||
|
||||
### 选项 1：作为插件安装（推荐）
|
||||
@ -546,7 +339,7 @@ Claude Code v2.1+ 会**按照约定自动加载**已安装插件中的 `hooks/ho
|
||||
/plugin marketplace add affaan-m/everything-claude-code
|
||||
|
||||
# 安装插件
|
||||
/plugin install ecc@ecc
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
或直接添加到你的 `~/.claude/settings.json`：
|
||||
@ -554,7 +347,7 @@ Claude Code v2.1+ 会**按照约定自动加载**已安装插件中的 `hooks/ho
|
||||
```json
|
||||
{
|
||||
"extraKnownMarketplaces": {
|
||||
"ecc": {
|
||||
"everything-claude-code": {
|
||||
"source": {
|
||||
"source": "github",
|
||||
"repo": "affaan-m/everything-claude-code"
|
||||
@ -562,7 +355,7 @@ Claude Code v2.1+ 会**按照约定自动加载**已安装插件中的 `hooks/ho
|
||||
}
|
||||
},
|
||||
"enabledPlugins": {
|
||||
"ecc@ecc": true
|
||||
"everything-claude-code@everything-claude-code": true
|
||||
}
|
||||
}
|
||||
```
|
||||
@ -575,72 +368,60 @@ Claude Code v2.1+ 会**按照约定自动加载**已安装插件中的 `hooks/ho
|
||||
> # 首先克隆仓库
|
||||
> git clone https://github.com/affaan-m/everything-claude-code.git
|
||||
>
|
||||
> # 方案 A：用户级规则（对所有项目生效）
|
||||
> # 选项 A：用户级规则（应用于所有项目）
|
||||
> mkdir -p ~/.claude/rules
|
||||
> cp -r everything-claude-code/rules/common ~/.claude/rules/
|
||||
> cp -r everything-claude-code/rules/typescript ~/.claude/rules/ # 选择你使用的技术栈
|
||||
> cp -r everything-claude-code/rules/typescript ~/.claude/rules/
|
||||
> cp -r everything-claude-code/rules/python ~/.claude/rules/
|
||||
> cp -r everything-claude-code/rules/golang ~/.claude/rules/
|
||||
> cp -r everything-claude-code/rules/php ~/.claude/rules/
|
||||
> cp -r everything-claude-code/rules/perl ~/.claude/rules/
|
||||
>
|
||||
> # 方案 B：项目级规则（仅对当前项目生效）
|
||||
> # 选项 B：项目级规则（仅应用于当前项目）
|
||||
> mkdir -p .claude/rules
|
||||
> cp -r everything-claude-code/rules/common .claude/rules/
|
||||
> cp -r everything-claude-code/rules/typescript .claude/rules/ # 选择你使用的技术栈
|
||||
> cp -r everything-claude-code/rules/typescript .claude/rules/
|
||||
> cp -r everything-claude-code/rules/python .claude/rules/
|
||||
> cp -r everything-claude-code/rules/golang .claude/rules/
|
||||
> cp -r everything-claude-code/rules/perl .claude/rules/
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
### 选项 2：手动安装
|
||||
|
||||
如果你希望手动控制安装内容，可按以下步骤操作：
|
||||
如果你希望对安装的内容进行手动控制：
|
||||
|
||||
```bash
|
||||
# 克隆仓库
|
||||
git clone https://github.com/affaan-m/everything-claude-code.git
|
||||
|
||||
# 将智能体文件复制到 Claude 配置目录
|
||||
# 将代理复制到你的 Claude 配置
|
||||
cp everything-claude-code/agents/*.md ~/.claude/agents/
|
||||
|
||||
# 复制规则目录（通用规则 + 特定语言规则）
|
||||
# 复制规则目录（通用 + 语言特定）
|
||||
mkdir -p ~/.claude/rules
|
||||
cp -r everything-claude-code/rules/common ~/.claude/rules/
|
||||
cp -r everything-claude-code/rules/typescript ~/.claude/rules/ # 选择你使用的技术栈
|
||||
cp -r everything-claude-code/rules/typescript ~/.claude/rules/ # 选择你的技术栈
|
||||
cp -r everything-claude-code/rules/python ~/.claude/rules/
|
||||
cp -r everything-claude-code/rules/golang ~/.claude/rules/
|
||||
cp -r everything-claude-code/rules/php ~/.claude/rules/
|
||||
cp -r everything-claude-code/rules/perl ~/.claude/rules/
|
||||
|
||||
# 优先复制技能模块（核心工作流）
|
||||
# 新用户推荐：仅复制核心/通用技能
|
||||
cp -r everything-claude-code/.agents/skills/* ~/.claude/skills/
|
||||
cp -r everything-claude-code/skills/search-first ~/.claude/skills/
|
||||
|
||||
# 可选：仅在需要时添加细分领域/框架专属技能
|
||||
# for s in django-patterns django-tdd laravel-patterns springboot-patterns; do
|
||||
# cp -r everything-claude-code/skills/$s ~/.claude/skills/
|
||||
# done
|
||||
|
||||
# 可选：迁移期间保留传统斜杠命令兼容
|
||||
mkdir -p ~/.claude/commands
|
||||
# 复制命令
|
||||
cp everything-claude-code/commands/*.md ~/.claude/commands/
|
||||
|
||||
# 复制技能
|
||||
cp -r everything-claude-code/skills/* ~/.claude/skills/
|
||||
```
|
||||
|
||||
#### 将钩子配置添加到 settings.json
|
||||
仅适用于手动安装：如果你没有通过 Claude 插件方式安装 ECC，可以将 `hooks/hooks.json` 中的钩子配置复制到你的 `~/.claude/settings.json` 文件中。
|
||||
#### 将钩子添加到 settings.json
|
||||
|
||||
如果你是通过 `/plugin install` 安装 ECC，请不要再把这些钩子复制到 `settings.json`。Claude Code v2.1+ 会自动加载插件中的 `hooks/hooks.json`，重复注册会导致重复执行以及 `${CLAUDE_PLUGIN_ROOT}` 无法解析。
|
||||
将 `hooks/hooks.json` 中的钩子复制到你的 `~/.claude/settings.json`。
|
||||
|
||||
#### 配置 MCP 服务
|
||||
从 `mcp-configs/mcp-servers.json` 中复制需要的 MCP 服务定义，粘贴到官方 Claude Code 配置文件 `~/.claude/settings.json` 中；
|
||||
若需要仓库本地的 MCP 访问权限，可粘贴到项目级配置文件 `.mcp.json` 中。
|
||||
#### 配置 MCP
|
||||
|
||||
如果你已自行运行 ECC 捆绑的 MCP 服务，设置以下环境变量：
|
||||
```bash
|
||||
export ECC_DISABLED_MCPS="github,context7,exa,playwright,sequential-thinking,memory"
|
||||
```
|
||||
ECC 托管的安装程序和 Codex 同步流程将跳过或移除这些服务，避免重复添加。
|
||||
将所需的 MCP 服务器从 `mcp-configs/mcp-servers.json` 复制到你的 `~/.claude.json`。
|
||||
|
||||
**重要提示**：将配置中的 `YOUR_*_HERE` 占位符替换为你真实的 API 密钥。
|
||||
**重要：** 将 `YOUR_*_HERE` 占位符替换为你的实际 API 密钥。
|
||||
|
||||
---
|
||||
|
||||
@ -734,11 +515,11 @@ node tests/hooks/hooks.test.js
|
||||
|
||||
### 贡献想法
|
||||
|
||||
- 特定语言技能（Rust、C#、Kotlin、Java）—— Go、Python、Perl、Swift 和 TypeScript 已内置
|
||||
- 特定框架配置（Rails、FastAPI）—— Django、NestJS、Spring Boot 和 Laravel 已内置
|
||||
- DevOps 智能体（Kubernetes、Terraform、AWS、Docker）
|
||||
- 测试策略（多种测试框架、视觉回归测试）
|
||||
- 领域专属知识库（机器学习、数据工程、移动端开发）
|
||||
- 特定语言的技能（Rust、C#、Kotlin、Java）- 现已包含 Go、Python、Perl、Swift 和 TypeScript！
|
||||
- 特定框架的配置（Django、Rails、Laravel）
|
||||
- DevOps 代理（Kubernetes、Terraform、AWS）
|
||||
- 测试策略（不同框架）
|
||||
- 特定领域的知识（ML、数据工程、移动）
|
||||
|
||||
---
|
||||
|
||||
@ -773,26 +554,6 @@ node tests/hooks/hooks.test.js
|
||||
|
||||
---
|
||||
|
||||
## 社区项目
|
||||
|
||||
基于 Everything Claude Code 构建或受其启发的项目：
|
||||
|
||||
| 项目 | 介绍 |
|
||||
|------|------|
|
||||
| [EVC](https://github.com/SaigonXIII/evc) | 营销智能体工作区 — 包含 42 条命令，面向内容运营、品牌管控与多渠道发布。[可视化概览](https://saigonxiii.github.io/evc)。 |
|
||||
|
||||
如果你用 ECC 做了项目，欢迎提交 PR 添加到这里。
|
||||
|
||||
---
|
||||
|
||||
## 赞助者
|
||||
|
||||
本项目免费开源。赞助支持项目持续维护与功能迭代。
|
||||
|
||||
[成为赞助者](https://github.com/sponsors/affaan-m) | [赞助档位](SPONSORS.md) | [赞助计划](SPONSORING.md)
|
||||
|
||||
---
|
||||
|
||||
## Star 历史
|
||||
|
||||
[](https://star-history.com/#affaan-m/everything-claude-code&Date)
|
||||
@ -801,10 +562,11 @@ node tests/hooks/hooks.test.js
|
||||
|
||||
## 链接
|
||||
|
||||
- **快速上手指南（入门首选）：** [Everything Claude Code 简明指南](https://x.com/affaanmustafa/status/2012378465664745795)
|
||||
- **长文指南（高阶进阶）：** [Everything Claude Code 完整版深度指南](https://x.com/affaanmustafa/status/2014040193557471352)
|
||||
- **安全指南：** [安全指南](./the-security-guide.md) | [推文详解](https://x.com/affaanmustafa/status/2033263813387223421)
|
||||
- **关注作者：** [@affaanmustafa](https://x.com/affaanmustafa)
|
||||
- **精简指南（从这里开始）：** [The Shorthand Guide to Everything Claude Code](https://x.com/affaanmustafa/status/2012378465664745795)
|
||||
- **详细指南（高级）：** [The Longform Guide to Everything Claude Code](https://x.com/affaanmustafa/status/2014040193557471352)
|
||||
- **关注：** [@affaanmustafa](https://x.com/affaanmustafa)
|
||||
- **zenith.chat:** [zenith.chat](https://zenith.chat)
|
||||
- **技能目录：** awesome-agent-skills（社区维护的智能体技能目录）
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ If you discover a security vulnerability in ECC, please report it responsibly.
|
||||
|
||||
**Do not open a public GitHub issue for security vulnerabilities.**
|
||||
|
||||
Instead, email **<security@ecc.tools>** with:
|
||||
Instead, email **security@ecc.tools** with:
|
||||
|
||||
- A description of the vulnerability
|
||||
- Steps to reproduce
|
||||
|
||||
@ -245,17 +245,9 @@ tmux attach -t dev
|
||||
- Marketplace cache not updated
|
||||
- Claude Code version incompatibility
|
||||
- Corrupted plugin files
|
||||
- Local Claude setup was wiped or reset
|
||||
|
||||
**Solutions:**
|
||||
```bash
|
||||
# First inspect what ECC still knows about this machine
|
||||
ecc list-installed
|
||||
ecc doctor
|
||||
ecc repair
|
||||
|
||||
# Only reinstall if doctor/repair cannot restore the missing files
|
||||
|
||||
# Inspect the plugin cache before changing it
|
||||
ls -la ~/.claude/plugins/cache/
|
||||
|
||||
@ -267,8 +259,6 @@ mkdir -p ~/.claude/plugins/cache
|
||||
# Claude Code → Extensions → Everything Claude Code → Uninstall
|
||||
# Then reinstall from marketplace
|
||||
|
||||
# If the issue is marketplace/account access, use ECC Tools billing/account recovery separately; do not use reinstall as a proxy for account recovery
|
||||
|
||||
# Check Claude Code version
|
||||
claude --version
|
||||
# Requires Claude Code 2.0+
|
||||
@ -380,7 +370,7 @@ chmod -R u+rwX,go+rX ~/.claude/homunculus
|
||||
|
||||
```bash
|
||||
# Install plugin dependencies
|
||||
cd ~/.claude/plugins/cache/ecc
|
||||
cd ~/.claude/plugins/cache/everything-claude-code
|
||||
npm install
|
||||
|
||||
# Or for manual install
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Working Context
|
||||
|
||||
Last updated: 2026-04-08
|
||||
Last updated: 2026-04-02
|
||||
|
||||
## Purpose
|
||||
|
||||
@ -9,11 +9,8 @@ Public ECC plugin repo for agents, skills, commands, hooks, rules, install surfa
|
||||
## Current Truth
|
||||
|
||||
- Default branch: `main`
|
||||
- Public release surface is aligned at `v1.10.0`
|
||||
- Public catalog truth is `47` agents, `79` commands, and `181` skills
|
||||
- Public plugin slug is now `ecc`; legacy `everything-claude-code` install paths remain supported for compatibility
|
||||
- Release discussion: `#1272`
|
||||
- ECC 2.0 exists in-tree and builds, but it is still alpha rather than GA
|
||||
- Immediate blocker addressed: CI lockfile drift and hook validation breakage fixed in `a273c62`
|
||||
- Local full suite status after fix: `1723/1723` passing
|
||||
- Main active operational work:
|
||||
- keep default branch green
|
||||
- continue issue-driven fixes from `main` now that the public PR backlog is at zero
|
||||
@ -27,16 +24,12 @@ Public ECC plugin repo for agents, skills, commands, hooks, rules, install surfa
|
||||
|
||||
## Active Queues
|
||||
|
||||
- PR backlog: reduced but active; keep direct-porting only safe ECC-native changes and close overlap, stale generators, and unaudited external-runtime lanes
|
||||
- Upstream branch backlog still needs selective mining and cleanup:
|
||||
- `origin/feat/hermes-generated-ops-skills` still has three unique commits, but only reusable ECC-native skills should be salvaged from it
|
||||
- multiple `origin/ecc-tools/*` automation branches are stale and should be pruned after confirming they carry no unique value
|
||||
- PR backlog: currently cleared on the public queue; new work should land through direct mainline fixes or fresh narrowly scoped PRs
|
||||
- Product:
|
||||
- selective install cleanup
|
||||
- control plane primitives
|
||||
- operator surface
|
||||
- self-improving skills
|
||||
- keep `agent.yaml` export parity with the shipped `commands/` and `skills/` directories so modern install surfaces do not silently lose command registration
|
||||
- Skill quality:
|
||||
- rewrite content-facing skills to use source-backed voice modeling
|
||||
- remove generic LLM rhetoric, canned CTA patterns, and forced platform stereotypes
|
||||
@ -91,13 +84,6 @@ Keep this file detailed for only the current sprint, blockers, and next actions.
|
||||
|
||||
## Latest Execution Notes
|
||||
|
||||
- 2026-04-05: Continued `#1213` overlap cleanup by narrowing `coding-standards` into the baseline cross-project conventions layer instead of deleting it. The skill now explicitly points detailed React/UI guidance to `frontend-patterns`, backend/API structure to `backend-patterns` / `api-design`, and keeps only reusable naming, readability, immutability, and code-quality expectations.
|
||||
- 2026-04-05: Added a packaging regression guard for the OpenCode release path after `#1287` showed the published `v1.10.0` artifact was still stale. `tests/scripts/build-opencode.test.js` now asserts the `npm pack --dry-run` tarball includes `.opencode/dist/index.js` plus compiled plugin/tool entrypoints, so future releases cannot silently omit the built OpenCode payload.
|
||||
- 2026-04-05: Landed `skills/agent-introspection-debugging` for `#829` as an ECC-native self-debugging framework. It is intentionally guidance-first rather than fake runtime automation: capture failure state, classify the pattern, apply the smallest contained recovery action, then emit a structured introspection report and hand off to `verification-loop` / `continuous-learning-v2` when appropriate.
|
||||
- 2026-04-05: Fixed the `main` npm CI break after the latest direct ports. `package-lock.json` had drifted behind `package.json` on the `globals` devDependency (`^17.1.0` vs `^17.4.0`), which caused all npm-based GitHub Actions jobs to fail at `npm ci`. Refreshed the lockfile only, verified `npm ci --ignore-scripts`, and kept the mixed-lock workspace otherwise untouched.
|
||||
- 2026-04-05: Direct-ported the useful discoverability part of `#1221` without duplicating a second healthcare compliance system. Added `skills/hipaa-compliance/SKILL.md` as a thin HIPAA-specific entrypoint that points into the canonical `healthcare-phi-compliance` / `healthcare-reviewer` lane, and wired both healthcare privacy skills into the `security` install module for selective installs.
|
||||
- 2026-04-05: Direct-ported the audited blockchain/web3 security lane from `#1222` into `main` as four self-contained skills: `defi-amm-security`, `evm-token-decimals`, `llm-trading-agent-security`, and `nodejs-keccak256`. These are now part of the `security` install module instead of living as an unmerged fork PR.
|
||||
- 2026-04-05: Finished the useful salvage pass from `#1203` directly on `main`. `skills/security-bounty-hunter`, `skills/api-connector-builder`, and `skills/dashboard-builder` are now in-tree as ECC-native rewrites instead of the thinner original community drafts. The original PR should be treated as superseded rather than merged.
|
||||
- 2026-04-02: `ECC-Tools/main` shipped `9566637` (`fix: prefer commit lookup over git ref resolution`). The PR-analysis fire is now fixed in the app repo by preferring explicit commit resolution before `git.getRef`, with regression coverage for pull refs and plain branch refs. Mirrored public tracking issue `#1184` in this repo was closed as resolved upstream.
|
||||
- 2026-04-02: Direct-ported the clean native-support core of `#1043` into `main`: `agents/csharp-reviewer.md`, `skills/dotnet-patterns/SKILL.md`, and `skills/csharp-testing/SKILL.md`. This fills the gap between existing C# rule/docs mentions and actual shipped C# review/testing guidance.
|
||||
- 2026-04-02: Direct-ported the clean native-support core of `#1055` into `main`: `agents/dart-build-resolver.md`, `commands/flutter-build.md`, `commands/flutter-review.md`, `commands/flutter-test.md`, `rules/dart/*`, and `skills/dart-flutter-patterns/SKILL.md`. The skill paths were wired into the current `framework-language` module instead of replaying the older PR's separate `flutter-dart` module layout.
|
||||
@ -143,37 +129,3 @@ Keep this file detailed for only the current sprint, blockers, and next actions.
|
||||
- 2026-04-02: Fixed `#1141` on `main` in `16e9b17`. The observer lifecycle is now session-aware instead of purely detached: `SessionStart` writes a project-scoped lease, `SessionEnd` removes that lease and stops the observer when the final lease disappears, `observe.sh` records project activity, and `observer-loop.sh` now exits on idle when no leases remain. Targeted validation passed with `bash -n`, `node tests/hooks/observer-memory.test.js`, `node tests/integration/hooks.test.js`, `node scripts/ci/validate-hooks.js hooks/hooks.json`, and `node scripts/ci/check-unicode-safety.js`.
|
||||
- 2026-04-02: Fixed the remaining Windows-only hook regression behind `#1070` by making `scripts/lib/utils.js#getHomeDir()` honor explicit `HOME` / `USERPROFILE` overrides before falling back to `os.homedir()`. This restores test-isolated observer state paths for hook integration runs on Windows. Added regression coverage in `tests/lib/utils.test.js`. Targeted validation passed with `node tests/lib/utils.test.js`, `node tests/integration/hooks.test.js`, `node tests/hooks/observer-memory.test.js`, and `node scripts/ci/check-unicode-safety.js`.
|
||||
- 2026-04-02: Direct-ported NestJS support for `#1022` into `main` as `skills/nestjs-patterns/SKILL.md` and wired it into the `framework-language` install module. Synced the repo catalog afterward (`38` agents, `72` commands, `156` skills) and updated the docs so NestJS is no longer listed as an unfilled framework gap.
|
||||
- 2026-04-05: Shipped `846ffb7` (`chore: ship v1.10.0 release surface refresh`). This updated README/plugin metadata/package versions, synced the explicit plugin agent inventory, bumped stale star/fork/contributor counts, created `docs/releases/1.10.0/*`, tagged and released `v1.10.0`, and posted the announcement discussion at `#1272`.
|
||||
- 2026-04-05: Salvaged the reusable Hermes-branch operator skills in `6eba30f` without replaying the full branch. Added `skills/github-ops`, `skills/knowledge-ops`, and `skills/hookify-rules`, wired them into install modules, and re-synced the repo to `159` skills. `knowledge-ops` was explicitly adapted to the current workspace model: live code in cloned repos, active truth in GitHub/Linear, broader non-code context in the KB/archive layers.
|
||||
- 2026-04-05: Fixed the remaining OpenCode npm-publish gap in `db6d52e`. The root package now builds `.opencode/dist` during `prepack`, includes the compiled OpenCode plugin assets in the published tarball, and carries a dedicated regression test (`tests/scripts/build-opencode.test.js`) so the package no longer ships only raw TypeScript source for that surface.
|
||||
- 2026-04-05: Added `skills/council`, direct-ported the safe `code-tour` lane from `#1193`, and re-synced the repo to `162` skills. `code-tour` stays self-contained and only produces `.tours/*.tour` artifacts with real file/line anchors; no external runtime or extension install is assumed inside the skill.
|
||||
- 2026-04-05: Closed the latest auto-generated ECC bundle PR wave (`#1275`-`#1281`) after deploying `ECC-Tools/main` fix `f615905`, which now blocks repo-level issue-comment `/analyze` requests from opening repeated bundle PRs while still allowing PR-thread retry analysis to run against immutable head SHAs.
|
||||
- 2026-04-05: Filled the SEO gap by direct-porting `agents/seo-specialist.md` and `skills/seo/SKILL.md` into `main`, then wiring `skills/seo` into `business-content`. This resolves the stale `team-builder` reference to an SEO specialist and brings the public catalog to `39` agents and `163` skills without merging the stale PR wholesale.
|
||||
- 2026-04-05: Salvaged the useful common-rule deltas from `#1214` directly into `rules/common/coding-style.md` and `rules/common/testing.md` (KISS/DRY/YAGNI reminders, naming conventions, code-smell guidance, and AAA-style test guidance), then closed the original mixed deletion PR. The broad skill removals in that PR were intentionally not replayed.
|
||||
- 2026-04-05: Fixed the stale-row bug in `.github/workflows/monthly-metrics.yml` with `bf5961e`. The workflow now refreshes the current month row in issue `#1087` instead of early-returning when the month already exists, and the dispatched run updated the April snapshot to the current star/fork/release counts.
|
||||
- 2026-04-05: Recovered the useful cost-control workflow from the divergent Hermes branch as a small ECC-native operator skill instead of replaying the branch. `skills/ecc-tools-cost-audit/SKILL.md` is now wired into `operator-workflows` and focused on webhook -> queue -> worker tracing, burn containment, quota bypass, premium-model leakage, and retry fanout in the sibling `ECC-Tools` repo.
|
||||
- 2026-04-05: Added `skills/council/SKILL.md` in `753da37` as an ECC-native four-voice decision workflow. The useful protocol from PR `#1254` was retained, but the shadow `~/.claude/notes` write path was explicitly removed in favor of `knowledge-ops`, `/save-session`, or direct GitHub/Linear updates when a decision delta matters.
|
||||
- 2026-04-05: Direct-ported the safe `globals` bump from PR `#1243` into `main` as part of the council lane and closed the PR as superseded.
|
||||
- 2026-04-05: Closed PR `#1232` after full audit. The proposed `skill-scout` workflow overlaps current `search-first`, `/skill-create`, and `skill-stocktake`; if a dedicated marketplace-discovery layer returns later it should be rebuilt on top of the current install/catalog model rather than landing as a parallel discovery path.
|
||||
- 2026-04-05: Ported the safe localized README switcher fixes from PR `#1209` directly into `main` rather than merging the docs PR wholesale. The navigation now consistently includes `Português (Brasil)` and `Türkçe` across the localized README switchers, while newer localized body copy stays intact.
|
||||
- 2026-04-05: Removed the stale InsAIts shipped surface from `main`. ECC no longer ships the external Python MCP entry, opt-in hook wiring, wrapper/monitor scripts, or current docs mentions for `insa-its`; changelog history remains, but the live product surface is now fully ECC-native again.
|
||||
- 2026-04-05: Salvaged the reusable Hermes-generated operator workflow lane without replaying the whole branch. Added six ECC-native top-level skills instead of the old nested `skills/hermes-generated/*` tree: `automation-audit-ops`, `email-ops`, `finance-billing-ops`, `messages-ops`, `research-ops`, and `terminal-ops`. `research-ops` now wraps the existing research stack, while the other five extend `operator-workflows` without introducing any external runtime assumptions.
|
||||
- 2026-04-05: Added `skills/product-capability` plus `docs/examples/product-capability-template.md` as the canonical PRD-to-SRS lane for issue `#1185`. This is the ECC-native capability-contract step between vague product intent and implementation, and it lives in `business-content` rather than spawning a parallel planning subsystem.
|
||||
- 2026-04-05: Tightened `product-lens` so it no longer overlaps the new capability-contract lane. `product-lens` now explicitly owns product diagnosis / brief validation, while `product-capability` owns implementation-ready capability plans and SRS-style constraints.
|
||||
- 2026-04-05: Continued `#1213` cleanup by removing stale references to the deleted `project-guidelines-example` skill from exported inventory/docs and marking `continuous-learning` v1 as a supported legacy path with an explicit handoff to `continuous-learning-v2`.
|
||||
- 2026-04-05: Removed the last orphaned localized `project-guidelines-example` docs from `docs/ko-KR` and `docs/zh-CN`. The template now lives only in `docs/examples/project-guidelines-template.md`, which matches the current repo surface and avoids shipping translated docs for a deleted skill.
|
||||
- 2026-04-05: Added `docs/HERMES-OPENCLAW-MIGRATION.md` as the current public migration guide for issue `#1051`. It reframes Hermes/OpenClaw as source systems to distill from, not the final runtime, and maps scheduler, dispatch, memory, skill, and service layers onto the ECC-native surfaces and ECC 2.0 backlog that already exist.
|
||||
- 2026-04-05: Landed `skills/agent-sort` and the legacy `/agent-sort` shim from issue `#916` as an ECC-native selective-install workflow. It classifies agents, skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using concrete repo evidence, then hands off installation changes to `configure-ecc` instead of inventing a parallel installer. Catalog truth is now `39` agents, `73` commands, and `179` skills.
|
||||
- 2026-04-05: Direct-ported the safe README-only `#1285` slice into `main` instead of merging the branch: added a small `Community Projects` section so downstream teams can link public work built on ECC without changing install, security, or runtime surfaces. Rejected `#1286` at review because it adds an external third-party GitHub Action (`hashgraph-online/codex-plugin-scanner`) that does not meet the current supply-chain policy.
|
||||
- 2026-04-05: Re-audited `origin/feat/hermes-generated-ops-skills` by full diff. The branch is still not mergeable: it deletes current ECC-native surfaces, regresses packaging/install metadata, and removes newer `main` content. Continued the selective-salvage policy instead of branch merge.
|
||||
- 2026-04-05: Selectively salvaged `skills/frontend-design` from the Hermes branch as a self-contained ECC-native skill, mirrored it into `.agents`, wired it into `framework-language`, and re-synced the catalog to `180` skills after validation. The branch itself remains reference-only until every remaining unique file is either ported intentionally or rejected.
|
||||
- 2026-04-05: Selectively salvaged the `hookify` command bundle plus the supporting `conversation-analyzer` agent from the Hermes branch. `hookify-rules` already existed as the canonical skill; this pass restores the user-facing command surfaces (`/hookify`, `/hookify-help`, `/hookify-list`, `/hookify-configure`) without pulling in any external runtime or branch-wide regressions. Catalog truth is now `40` agents, `77` commands, and `180` skills.
|
||||
- 2026-04-05: Selectively salvaged the self-contained review/development bundle from the Hermes branch: `review-pr`, `feature-dev`, and the supporting analyzer/architecture agents (`code-architect`, `code-explorer`, `code-simplifier`, `comment-analyzer`, `pr-test-analyzer`, `silent-failure-hunter`, `type-design-analyzer`). This adds ECC-native command surfaces around PR review and feature planning without merging the branch's broader regressions. Catalog truth is now `47` agents, `79` commands, and `180` skills.
|
||||
- 2026-04-05: Ported `docs/HERMES-SETUP.md` from the Hermes branch as a sanitized operator-topology document for the migration lane. This is docs-only support for `#1051`, not a runtime change and not a sign that the Hermes branch itself is mergeable.
|
||||
- 2026-04-05: Finished the useful salvage pass over `origin/feat/hermes-generated-ops-skills`. The remaining unique files were explicitly rejected:
|
||||
- duplicate git helper commands (`commit`, `commit-push-pr`, `clean-gone`) overlap current checkpoint / publish flows
|
||||
- `scripts/hooks/security-reminder*` adds a new Python-backed hook path not justified by current runtime policy
|
||||
- `skills/oura-health` and `skills/pmx-guidelines` are user- or project-specific, not canonical ECC surfaces
|
||||
- `docs/releases/2.0.0-preview/*` is premature collateral and should be rebuilt from current product truth later
|
||||
- nested `skills/hermes-generated/*` is superseded by the top-level ECC-native operator skills already ported to `main`
|
||||
- 2026-04-08: Fixed the command-export regression reported in `#1327` by restoring a canonical `commands:` section in `agent.yaml` and adding `tests/ci/agent-yaml-surface.test.js` to enforce exact parity between the YAML export surface and the real `commands/` directory. Verified with the full repo test sweep: `1764/1764` passing.
|
||||
|
||||
81
agent.yaml
81
agent.yaml
@ -107,6 +107,7 @@ skills:
|
||||
- postgres-patterns
|
||||
- product-lens
|
||||
- production-scheduling
|
||||
- project-guidelines-example
|
||||
- prompt-optimizer
|
||||
- python-patterns
|
||||
- python-testing
|
||||
@ -143,86 +144,6 @@ skills:
|
||||
- videodb
|
||||
- visa-doc-translate
|
||||
- x-api
|
||||
commands:
|
||||
- agent-sort
|
||||
- aside
|
||||
- build-fix
|
||||
- checkpoint
|
||||
- claw
|
||||
- code-review
|
||||
- context-budget
|
||||
- cpp-build
|
||||
- cpp-review
|
||||
- cpp-test
|
||||
- devfleet
|
||||
- docs
|
||||
- e2e
|
||||
- eval
|
||||
- evolve
|
||||
- feature-dev
|
||||
- flutter-build
|
||||
- flutter-review
|
||||
- flutter-test
|
||||
- gan-build
|
||||
- gan-design
|
||||
- go-build
|
||||
- go-review
|
||||
- go-test
|
||||
- gradle-build
|
||||
- harness-audit
|
||||
- hookify
|
||||
- hookify-configure
|
||||
- hookify-help
|
||||
- hookify-list
|
||||
- instinct-export
|
||||
- instinct-import
|
||||
- instinct-status
|
||||
- jira
|
||||
- kotlin-build
|
||||
- kotlin-review
|
||||
- kotlin-test
|
||||
- learn
|
||||
- learn-eval
|
||||
- loop-start
|
||||
- loop-status
|
||||
- model-route
|
||||
- multi-backend
|
||||
- multi-execute
|
||||
- multi-frontend
|
||||
- multi-plan
|
||||
- multi-workflow
|
||||
- orchestrate
|
||||
- plan
|
||||
- pm2
|
||||
- projects
|
||||
- promote
|
||||
- prompt-optimize
|
||||
- prp-commit
|
||||
- prp-implement
|
||||
- prp-plan
|
||||
- prp-pr
|
||||
- prp-prd
|
||||
- prune
|
||||
- python-review
|
||||
- quality-gate
|
||||
- refactor-clean
|
||||
- resume-session
|
||||
- review-pr
|
||||
- rules-distill
|
||||
- rust-build
|
||||
- rust-review
|
||||
- rust-test
|
||||
- santa-loop
|
||||
- save-session
|
||||
- sessions
|
||||
- setup-pm
|
||||
- skill-create
|
||||
- skill-health
|
||||
- tdd
|
||||
- test-coverage
|
||||
- update-codemaps
|
||||
- update-docs
|
||||
- verify
|
||||
tags:
|
||||
- agent-harness
|
||||
- developer-tools
|
||||
|
||||
@ -1,139 +0,0 @@
|
||||
---
|
||||
name: a11y-architect
|
||||
description: Accessibility Architect specializing in WCAG 2.2 compliance for Web and Native platforms. Use PROACTIVELY when designing UI components, establishing design systems, or auditing code for inclusive user experiences.
|
||||
tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
You are a Senior Accessibility Architect. Your goal is to ensure that every digital product is Perceivable, Operable, Understandable, and Robust (POUR) for all users, including those with visual, auditory, motor, or cognitive disabilities.
|
||||
|
||||
## Your Role
|
||||
|
||||
- **Architecting Inclusivity**: Design UI systems that natively support assistive technologies (Screen Readers, Voice Control, Switch Access).
|
||||
- **WCAG 2.2 Enforcement**: Apply the latest success criteria, focusing on new standards like Focus Appearance, Target Size, and Redundant Entry.
|
||||
- **Platform Strategy**: Bridge the gap between Web standards (WAI-ARIA) and Native frameworks (SwiftUI/Jetpack Compose).
|
||||
- **Technical Specifications**: Provide developers with precise attributes (roles, labels, hints, and traits) required for compliance.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Contextual Discovery
|
||||
|
||||
- Determine if the target is **Web**, **iOS**, or **Android**.
|
||||
- Analyze the user interaction (e.g., Is this a simple button or a complex data grid?).
|
||||
- Identify potential accessibility "blockers" (e.g., color-only indicators, missing focus containment in modals).
|
||||
|
||||
### Step 2: Strategic Implementation
|
||||
|
||||
- **Apply the Accessibility Skill**: Invoke specific logic to generate semantic code.
|
||||
- **Define Focus Flow**: Map out how a keyboard or screen reader user will move through the interface.
|
||||
- **Optimize Touch/Pointer**: Ensure all interactive elements meet the minimum **24x24 pixel** spacing or **44x44 pixel** target size requirements.
|
||||
|
||||
### Step 3: Validation & Documentation
|
||||
|
||||
- Review the output against the WCAG 2.2 Level AA checklist.
|
||||
- Provide a brief "Implementation Note" explaining _why_ certain attributes (like `aria-live` or `accessibilityHint`) were used.
|
||||
|
||||
## Output Format
|
||||
|
||||
For every component or page request, provide:
|
||||
|
||||
1. **The Code**: Semantic HTML/ARIA or Native code.
|
||||
2. **The Accessibility Tree**: A description of what a screen reader will announce.
|
||||
3. **Compliance Mapping**: A list of specific WCAG 2.2 criteria addressed.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example: Accessible Search Component
|
||||
|
||||
**Input**: "Create a search bar with a submit icon."
|
||||
**Action**: Ensuring the icon-only button has a visible label and the input is correctly labeled.
|
||||
**Output**:
|
||||
|
||||
```html
|
||||
<form role="search">
|
||||
<label for="site-search" class="sr-only">Search the site</label>
|
||||
<input type="search" id="site-search" name="q" />
|
||||
<button type="submit" aria-label="Search">
|
||||
<svg aria-hidden="true">...</svg>
|
||||
</button>
|
||||
</form>
|
||||
```
|
||||
|
||||
## WCAG 2.2 Core Compliance Checklist
|
||||
|
||||
### 1. Perceivable (Information must be presentable)
|
||||
|
||||
- [ ] **Text Alternatives**: All non-text content has a text alternative (Alt text or labels).
|
||||
- [ ] **Contrast**: Text meets 4.5:1; UI components/graphics meet 3:1 contrast ratios.
|
||||
- [ ] **Adaptable**: Content reflows and remains functional when resized up to 400%.
|
||||
|
||||
### 2. Operable (Interface components must be usable)
|
||||
|
||||
- [ ] **Keyboard Accessible**: Every interactive element is reachable via keyboard/switch control.
|
||||
- [ ] **Navigable**: Focus order is logical, and focus indicators are high-contrast (SC 2.4.11).
|
||||
- [ ] **Pointer Gestures**: Single-pointer alternatives exist for all dragging or multipoint gestures.
|
||||
- [ ] **Target Size**: Interactive elements are at least 24x24 CSS pixels (SC 2.5.8).
|
||||
|
||||
### 3. Understandable (Information must be clear)
|
||||
|
||||
- [ ] **Predictable**: Navigation and identification of elements are consistent across the app.
|
||||
- [ ] **Input Assistance**: Forms provide clear error identification and suggestions for fix.
|
||||
- [ ] **Redundant Entry**: Avoid asking for the same info twice in a single process (SC 3.3.7).
|
||||
|
||||
### 4. Robust (Content must be compatible)
|
||||
|
||||
- [ ] **Compatibility**: Maximize compatibility with assistive tech using valid Name, Role, and Value.
|
||||
- [ ] **Status Messages**: Screen readers are notified of dynamic changes via ARIA live regions.
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
| Issue | Why it fails |
|
||||
| :------------------------- | :------------------------------------------------------------------------------------------------- |
|
||||
| **"Click Here" Links** | Non-descriptive; screen reader users navigating by links won't know the destination. |
|
||||
| **Fixed-Sized Containers** | Prevents content reflow and breaks the layout at higher zoom levels. |
|
||||
| **Keyboard Traps** | Prevents users from navigating the rest of the page once they enter a component. |
|
||||
| **Auto-Playing Media** | Distracting for users with cognitive disabilities; interferes with screen reader audio. |
|
||||
| **Empty Buttons** | Icon-only buttons without an `aria-label` or `accessibilityLabel` are invisible to screen readers. |
|
||||
|
||||
## Accessibility Decision Record Template
|
||||
|
||||
For major UI decisions, use this format:
|
||||
|
||||
````markdown
|
||||
# ADR-ACC-[000]: [Title of the Accessibility Decision]
|
||||
|
||||
## Status
|
||||
|
||||
Proposed | **Accepted** | Deprecated | Superseded by [ADR-XXX]
|
||||
|
||||
## Context
|
||||
|
||||
_Describe the UI component or workflow being addressed._
|
||||
|
||||
- **Platform**: [Web | iOS | Android | Cross-platform]
|
||||
- **WCAG 2.2 Success Criterion**: [e.g., 2.5.8 Target Size (Minimum)]
|
||||
- **Problem**: What is the current accessibility barrier? (e.g., "The 'Close' button in the modal is too small for users with motor impairments.")
|
||||
|
||||
## Decision
|
||||
|
||||
_Detail the specific implementation choice._
|
||||
"We will implement a touch target of at least 44x44 points for all mobile navigation elements and 24x24 CSS pixels for web, ensuring a minimum 4px spacing between adjacent targets."
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Code/Spec
|
||||
|
||||
```[language]
|
||||
// Example: SwiftUI
|
||||
Button(action: close) {
|
||||
Image(systemName: "xmark")
|
||||
.frame(width: 44, height: 44) // Standardizing hit area
|
||||
}
|
||||
.accessibilityLabel("Close modal")
|
||||
```
|
||||
````
|
||||
|
||||
## Reference
|
||||
|
||||
- See skill `accessibility` to transform raw UI requirements into platform-specific accessible code (WAI-ARIA, SwiftUI, or Jetpack Compose) based on WCAG 2.2 criteria.
|
||||
@ -1,71 +0,0 @@
|
||||
---
|
||||
name: code-architect
|
||||
description: Designs feature architectures by analyzing existing codebase patterns and conventions, then providing implementation blueprints with concrete files, interfaces, data flow, and build order.
|
||||
model: sonnet
|
||||
tools: [Read, Grep, Glob, Bash]
|
||||
---
|
||||
|
||||
# Code Architect Agent
|
||||
|
||||
You design feature architectures based on a deep understanding of the existing codebase.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Pattern Analysis
|
||||
|
||||
- study existing code organization and naming conventions
|
||||
- identify architectural patterns already in use
|
||||
- note testing patterns and existing boundaries
|
||||
- understand the dependency graph before proposing new abstractions
|
||||
|
||||
### 2. Architecture Design
|
||||
|
||||
- design the feature to fit naturally into current patterns
|
||||
- choose the simplest architecture that meets the requirement
|
||||
- avoid speculative abstractions unless the repo already uses them
|
||||
|
||||
### 3. Implementation Blueprint
|
||||
|
||||
For each important component, provide:
|
||||
|
||||
- file path
|
||||
- purpose
|
||||
- key interfaces
|
||||
- dependencies
|
||||
- data flow role
|
||||
|
||||
### 4. Build Sequence
|
||||
|
||||
Order the implementation by dependency:
|
||||
|
||||
1. types and interfaces
|
||||
2. core logic
|
||||
3. integration layer
|
||||
4. UI
|
||||
5. tests
|
||||
6. docs
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Architecture: [Feature Name]
|
||||
|
||||
### Design Decisions
|
||||
- Decision 1: [Rationale]
|
||||
- Decision 2: [Rationale]
|
||||
|
||||
### Files to Create
|
||||
| File | Purpose | Priority |
|
||||
|------|---------|----------|
|
||||
|
||||
### Files to Modify
|
||||
| File | Changes | Priority |
|
||||
|------|---------|----------|
|
||||
|
||||
### Data Flow
|
||||
[Description]
|
||||
|
||||
### Build Sequence
|
||||
1. Step 1
|
||||
2. Step 2
|
||||
```
|
||||
@ -1,69 +0,0 @@
|
||||
---
|
||||
name: code-explorer
|
||||
description: Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, and documenting dependencies to inform new development.
|
||||
model: sonnet
|
||||
tools: [Read, Grep, Glob, Bash]
|
||||
---
|
||||
|
||||
# Code Explorer Agent
|
||||
|
||||
You deeply analyze codebases to understand how existing features work before new work begins.
|
||||
|
||||
## Analysis Process
|
||||
|
||||
### 1. Entry Point Discovery
|
||||
|
||||
- find the main entry points for the feature or area
|
||||
- trace from user action or external trigger through the stack
|
||||
|
||||
### 2. Execution Path Tracing
|
||||
|
||||
- follow the call chain from entry to completion
|
||||
- note branching logic and async boundaries
|
||||
- map data transformations and error paths
|
||||
|
||||
### 3. Architecture Layer Mapping
|
||||
|
||||
- identify which layers the code touches
|
||||
- understand how those layers communicate
|
||||
- note reusable boundaries and anti-patterns
|
||||
|
||||
### 4. Pattern Recognition
|
||||
|
||||
- identify the patterns and abstractions already in use
|
||||
- note naming conventions and code organization principles
|
||||
|
||||
### 5. Dependency Documentation
|
||||
|
||||
- map external libraries and services
|
||||
- map internal module dependencies
|
||||
- identify shared utilities worth reusing
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Exploration: [Feature/Area Name]
|
||||
|
||||
### Entry Points
|
||||
- [Entry point]: [How it is triggered]
|
||||
|
||||
### Execution Flow
|
||||
1. [Step]
|
||||
2. [Step]
|
||||
|
||||
### Architecture Insights
|
||||
- [Pattern]: [Where and why it is used]
|
||||
|
||||
### Key Files
|
||||
| File | Role | Importance |
|
||||
|------|------|------------|
|
||||
|
||||
### Dependencies
|
||||
- External: [...]
|
||||
- Internal: [...]
|
||||
|
||||
### Recommendations for New Development
|
||||
- Follow [...]
|
||||
- Reuse [...]
|
||||
- Avoid [...]
|
||||
```
|
||||
@ -1,47 +0,0 @@
|
||||
---
|
||||
name: code-simplifier
|
||||
description: Simplifies and refines code for clarity, consistency, and maintainability while preserving behavior. Focus on recently modified code unless instructed otherwise.
|
||||
model: sonnet
|
||||
tools: [Read, Write, Edit, Bash, Grep, Glob]
|
||||
---
|
||||
|
||||
# Code Simplifier Agent
|
||||
|
||||
You simplify code while preserving functionality.
|
||||
|
||||
## Principles
|
||||
|
||||
1. clarity over cleverness
|
||||
2. consistency with existing repo style
|
||||
3. preserve behavior exactly
|
||||
4. simplify only where the result is demonstrably easier to maintain
|
||||
|
||||
## Simplification Targets
|
||||
|
||||
### Structure
|
||||
|
||||
- extract deeply nested logic into named functions
|
||||
- replace complex conditionals with early returns where clearer
|
||||
- simplify callback chains with `async` / `await`
|
||||
- remove dead code and unused imports
|
||||
|
||||
### Readability
|
||||
|
||||
- prefer descriptive names
|
||||
- avoid nested ternaries
|
||||
- break long chains into intermediate variables when it improves clarity
|
||||
- use destructuring when it clarifies access
|
||||
|
||||
### Quality
|
||||
|
||||
- remove stray `console.log`
|
||||
- remove commented-out code
|
||||
- consolidate duplicated logic
|
||||
- unwind over-abstracted single-use helpers
|
||||
|
||||
## Approach
|
||||
|
||||
1. read the changed files
|
||||
2. identify simplification opportunities
|
||||
3. apply only functionally equivalent changes
|
||||
4. verify no behavioral change was introduced
|
||||
@ -1,45 +0,0 @@
|
||||
---
|
||||
name: comment-analyzer
|
||||
description: Analyze code comments for accuracy, completeness, maintainability, and comment rot risk.
|
||||
model: sonnet
|
||||
tools: [Read, Grep, Glob, Bash]
|
||||
---
|
||||
|
||||
# Comment Analyzer Agent
|
||||
|
||||
You ensure comments are accurate, useful, and maintainable.
|
||||
|
||||
## Analysis Framework
|
||||
|
||||
### 1. Factual Accuracy
|
||||
|
||||
- verify claims against the code
|
||||
- check parameter and return descriptions against implementation
|
||||
- flag outdated references
|
||||
|
||||
### 2. Completeness
|
||||
|
||||
- check whether complex logic has enough explanation
|
||||
- verify important side effects and edge cases are documented
|
||||
- ensure public APIs have complete enough comments
|
||||
|
||||
### 3. Long-Term Value
|
||||
|
||||
- flag comments that only restate the code
|
||||
- identify fragile comments that will rot quickly
|
||||
- surface TODO / FIXME / HACK debt
|
||||
|
||||
### 4. Misleading Elements
|
||||
|
||||
- comments that contradict the code
|
||||
- stale references to removed behavior
|
||||
- over-promised or under-described behavior
|
||||
|
||||
## Output Format
|
||||
|
||||
Provide advisory findings grouped by severity:
|
||||
|
||||
- `Inaccurate`
|
||||
- `Stale`
|
||||
- `Incomplete`
|
||||
- `Low-value`
|
||||
@ -1,52 +0,0 @@
|
||||
---
|
||||
name: conversation-analyzer
|
||||
description: Use this agent when analyzing conversation transcripts to find behaviors worth preventing with hooks. Triggered by /hookify without arguments.
|
||||
model: sonnet
|
||||
tools: [Read, Grep]
|
||||
---
|
||||
|
||||
# Conversation Analyzer Agent
|
||||
|
||||
You analyze conversation history to identify problematic Claude Code behaviors that should be prevented with hooks.
|
||||
|
||||
## What to Look For
|
||||
|
||||
### Explicit Corrections
|
||||
- "No, don't do that"
|
||||
- "Stop doing X"
|
||||
- "I said NOT to..."
|
||||
- "That's wrong, use Y instead"
|
||||
|
||||
### Frustrated Reactions
|
||||
- User reverting changes Claude made
|
||||
- Repeated "no" or "wrong" responses
|
||||
- User manually fixing Claude's output
|
||||
- Escalating frustration in tone
|
||||
|
||||
### Repeated Issues
|
||||
- Same mistake appearing multiple times in the conversation
|
||||
- Claude repeatedly using a tool in an undesired way
|
||||
- Patterns of behavior the user keeps correcting
|
||||
|
||||
### Reverted Changes
|
||||
- `git checkout -- file` or `git restore file` after Claude's edit
|
||||
- User undoing or reverting Claude's work
|
||||
- Re-editing files Claude just edited
|
||||
|
||||
## Output Format
|
||||
|
||||
For each identified behavior:
|
||||
|
||||
```yaml
|
||||
behavior: "Description of what Claude did wrong"
|
||||
frequency: "How often it occurred"
|
||||
severity: high|medium|low
|
||||
suggested_rule:
|
||||
name: "descriptive-rule-name"
|
||||
event: bash|file|stop|prompt
|
||||
pattern: "regex pattern to match"
|
||||
action: block|warn
|
||||
message: "What to show when triggered"
|
||||
```
|
||||
|
||||
Prioritize high-frequency, high-severity behaviors first.
|
||||
@ -1,45 +0,0 @@
|
||||
---
|
||||
name: pr-test-analyzer
|
||||
description: Review pull request test coverage quality and completeness, with emphasis on behavioral coverage and real bug prevention.
|
||||
model: sonnet
|
||||
tools: [Read, Grep, Glob, Bash]
|
||||
---
|
||||
|
||||
# PR Test Analyzer Agent
|
||||
|
||||
You review whether a PR's tests actually cover the changed behavior.
|
||||
|
||||
## Analysis Process
|
||||
|
||||
### 1. Identify Changed Code
|
||||
|
||||
- map changed functions, classes, and modules
|
||||
- locate corresponding tests
|
||||
- identify new untested code paths
|
||||
|
||||
### 2. Behavioral Coverage
|
||||
|
||||
- check that each feature has tests
|
||||
- verify edge cases and error paths
|
||||
- ensure important integrations are covered
|
||||
|
||||
### 3. Test Quality
|
||||
|
||||
- prefer meaningful assertions over no-throw checks
|
||||
- flag flaky patterns
|
||||
- check isolation and clarity of test names
|
||||
|
||||
### 4. Coverage Gaps
|
||||
|
||||
Rate gaps by impact:
|
||||
|
||||
- critical
|
||||
- important
|
||||
- nice-to-have
|
||||
|
||||
## Output Format
|
||||
|
||||
1. coverage summary
|
||||
2. critical gaps
|
||||
3. improvement suggestions
|
||||
4. positive observations
|
||||
@ -1,62 +0,0 @@
|
||||
---
|
||||
name: seo-specialist
|
||||
description: SEO specialist for technical SEO audits, on-page optimization, structured data, Core Web Vitals, and content/keyword mapping. Use for site audits, meta tag reviews, schema markup, sitemap and robots issues, and SEO remediation plans.
|
||||
tools: ["Read", "Grep", "Glob", "Bash", "WebSearch", "WebFetch"]
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
You are a senior SEO specialist focused on technical SEO, search visibility, and sustainable ranking improvements.
|
||||
|
||||
When invoked:
|
||||
1. Identify the scope: full-site audit, page-specific issue, schema problem, performance issue, or content planning task.
|
||||
2. Read the relevant source files and deployment-facing assets first.
|
||||
3. Prioritize findings by severity and likely ranking impact.
|
||||
4. Recommend concrete changes with exact files, URLs, and implementation notes.
|
||||
|
||||
## Audit Priorities
|
||||
|
||||
### Critical
|
||||
|
||||
- crawl or index blockers on important pages
|
||||
- `robots.txt` or meta-robots conflicts
|
||||
- canonical loops or broken canonical targets
|
||||
- redirect chains longer than two hops
|
||||
- broken internal links on key paths
|
||||
|
||||
### High
|
||||
|
||||
- missing or duplicate title tags
|
||||
- missing or duplicate meta descriptions
|
||||
- invalid heading hierarchy
|
||||
- malformed or missing JSON-LD on key page types
|
||||
- Core Web Vitals regressions on important pages
|
||||
|
||||
### Medium
|
||||
|
||||
- thin content
|
||||
- missing alt text
|
||||
- weak anchor text
|
||||
- orphan pages
|
||||
- keyword cannibalization
|
||||
|
||||
## Review Output
|
||||
|
||||
Use this format:
|
||||
|
||||
```text
|
||||
[SEVERITY] Issue title
|
||||
Location: path/to/file.tsx:42 or URL
|
||||
Issue: What is wrong and why it matters
|
||||
Fix: Exact change to make
|
||||
```
|
||||
|
||||
## Quality Bar
|
||||
|
||||
- no vague SEO folklore
|
||||
- no manipulative pattern recommendations
|
||||
- no advice detached from the actual site structure
|
||||
- recommendations should be implementable by the receiving engineer or content owner
|
||||
|
||||
## Reference
|
||||
|
||||
Use `skills/seo` for the canonical ECC SEO workflow and implementation guidance.
|
||||
@ -1,50 +0,0 @@
|
||||
---
|
||||
name: silent-failure-hunter
|
||||
description: Review code for silent failures, swallowed errors, bad fallbacks, and missing error propagation.
|
||||
model: sonnet
|
||||
tools: [Read, Grep, Glob, Bash]
|
||||
---
|
||||
|
||||
# Silent Failure Hunter Agent
|
||||
|
||||
You have zero tolerance for silent failures.
|
||||
|
||||
## Hunt Targets
|
||||
|
||||
### 1. Empty Catch Blocks
|
||||
|
||||
- `catch {}` or ignored exceptions
|
||||
- errors converted to `null` / empty arrays with no context
|
||||
|
||||
### 2. Inadequate Logging
|
||||
|
||||
- logs without enough context
|
||||
- wrong severity
|
||||
- log-and-forget handling
|
||||
|
||||
### 3. Dangerous Fallbacks
|
||||
|
||||
- default values that hide real failure
|
||||
- `.catch(() => [])`
|
||||
- graceful-looking paths that make downstream bugs harder to diagnose
|
||||
|
||||
### 4. Error Propagation Issues
|
||||
|
||||
- lost stack traces
|
||||
- generic rethrows
|
||||
- missing async handling
|
||||
|
||||
### 5. Missing Error Handling
|
||||
|
||||
- no timeout or error handling around network/file/db paths
|
||||
- no rollback around transactional work
|
||||
|
||||
## Output Format
|
||||
|
||||
For each finding:
|
||||
|
||||
- location
|
||||
- severity
|
||||
- issue
|
||||
- impact
|
||||
- fix recommendation
|
||||
@ -1,41 +0,0 @@
|
||||
---
|
||||
name: type-design-analyzer
|
||||
description: Analyze type design for encapsulation, invariant expression, usefulness, and enforcement.
|
||||
model: sonnet
|
||||
tools: [Read, Grep, Glob, Bash]
|
||||
---
|
||||
|
||||
# Type Design Analyzer Agent
|
||||
|
||||
You evaluate whether types make illegal states harder or impossible to represent.
|
||||
|
||||
## Evaluation Criteria
|
||||
|
||||
### 1. Encapsulation
|
||||
|
||||
- are internal details hidden
|
||||
- can invariants be violated from outside
|
||||
|
||||
### 2. Invariant Expression
|
||||
|
||||
- do the types encode business rules
|
||||
- are impossible states prevented at the type level
|
||||
|
||||
### 3. Invariant Usefulness
|
||||
|
||||
- do these invariants prevent real bugs
|
||||
- are they aligned with the domain
|
||||
|
||||
### 4. Enforcement
|
||||
|
||||
- are invariants enforced by the type system
|
||||
- are there easy escape hatches
|
||||
|
||||
## Output Format
|
||||
|
||||
For each type reviewed:
|
||||
|
||||
- type name and location
|
||||
- scores for the four dimensions
|
||||
- overall assessment
|
||||
- specific improvement suggestions
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 98 KiB |
@ -1,23 +0,0 @@
|
||||
---
|
||||
description: Legacy slash-entry shim for the agent-sort skill. Prefer the skill directly.
|
||||
---
|
||||
|
||||
# Agent Sort (Legacy Shim)
|
||||
|
||||
Use this only if you still invoke `/agent-sort`. The maintained workflow lives in `skills/agent-sort/SKILL.md`.
|
||||
|
||||
## Canonical Surface
|
||||
|
||||
- Prefer the `agent-sort` skill directly.
|
||||
- Keep this file only as a compatibility entry point.
|
||||
|
||||
## Arguments
|
||||
|
||||
`$ARGUMENTS`
|
||||
|
||||
## Delegation
|
||||
|
||||
Apply the `agent-sort` skill.
|
||||
- Classify ECC surfaces with concrete repo evidence.
|
||||
- Keep the result to DAILY vs LIBRARY.
|
||||
- If an install change is needed afterward, hand off to `configure-ecc` instead of re-implementing install logic here.
|
||||
@ -1,49 +0,0 @@
|
||||
---
|
||||
description: Guided feature development with codebase understanding and architecture focus
|
||||
---
|
||||
|
||||
A structured feature-development workflow that emphasizes understanding existing code before writing new code.
|
||||
|
||||
## Phases
|
||||
|
||||
### 1. Discovery
|
||||
|
||||
- read the feature request carefully
|
||||
- identify requirements, constraints, and acceptance criteria
|
||||
- ask clarifying questions if the request is ambiguous
|
||||
|
||||
### 2. Codebase Exploration
|
||||
|
||||
- use `code-explorer` to analyze the relevant existing code
|
||||
- trace execution paths and architecture layers
|
||||
- understand integration points and conventions
|
||||
|
||||
### 3. Clarifying Questions
|
||||
|
||||
- present findings from exploration
|
||||
- ask targeted design and edge-case questions
|
||||
- wait for user response before proceeding
|
||||
|
||||
### 4. Architecture Design
|
||||
|
||||
- use `code-architect` to design the feature
|
||||
- provide the implementation blueprint
|
||||
- wait for approval before implementing
|
||||
|
||||
### 5. Implementation
|
||||
|
||||
- implement the feature following the approved design
|
||||
- prefer TDD where appropriate
|
||||
- keep commits small and focused
|
||||
|
||||
### 6. Quality Review
|
||||
|
||||
- use `code-reviewer` to review the implementation
|
||||
- address critical and important issues
|
||||
- verify test coverage
|
||||
|
||||
### 7. Summary
|
||||
|
||||
- summarize what was built
|
||||
- list follow-up items or limitations
|
||||
- provide testing instructions
|
||||
@ -1,14 +0,0 @@
|
||||
---
|
||||
description: Enable or disable hookify rules interactively
|
||||
---
|
||||
|
||||
Interactively enable or disable existing hookify rules.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Find all `.claude/hookify.*.local.md` files
|
||||
2. Read the current state of each rule
|
||||
3. Present the list with current enabled / disabled status
|
||||
4. Ask which rules to toggle
|
||||
5. Update the `enabled:` field in the selected rule files
|
||||
6. Confirm the changes
|
||||
@ -1,46 +0,0 @@
|
||||
---
|
||||
description: Get help with the hookify system
|
||||
---
|
||||
|
||||
Display comprehensive hookify documentation.
|
||||
|
||||
## Hook System Overview
|
||||
|
||||
Hookify creates rule files that integrate with Claude Code's hook system to prevent unwanted behaviors.
|
||||
|
||||
### Event Types
|
||||
|
||||
- `bash`: triggers on Bash tool use and matches command patterns
|
||||
- `file`: triggers on Write/Edit tool use and matches file paths
|
||||
- `stop`: triggers when a session ends
|
||||
- `prompt`: triggers on user message submission and matches input patterns
|
||||
- `all`: triggers on all events
|
||||
|
||||
### Rule File Format
|
||||
|
||||
Files are stored as `.claude/hookify.{name}.local.md`:
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: descriptive-name
|
||||
enabled: true
|
||||
event: bash|file|stop|prompt|all
|
||||
action: block|warn
|
||||
pattern: "regex pattern to match"
|
||||
---
|
||||
Message to display when rule triggers.
|
||||
Supports multiple lines.
|
||||
```
|
||||
|
||||
### Commands
|
||||
|
||||
- `/hookify [description]` creates new rules and auto-analyzes the conversation when no description is given
|
||||
- `/hookify-list` lists configured rules
|
||||
- `/hookify-configure` toggles rules on or off
|
||||
|
||||
### Pattern Tips
|
||||
|
||||
- use regex syntax
|
||||
- for `bash`, match against the full command string
|
||||
- for `file`, match against the file path
|
||||
- test patterns before deploying
|
||||
@ -1,21 +0,0 @@
|
||||
---
|
||||
description: List all configured hookify rules
|
||||
---
|
||||
|
||||
Find and display all hookify rules in a formatted table.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Find all `.claude/hookify.*.local.md` files
|
||||
2. Read each file's frontmatter:
|
||||
- `name`
|
||||
- `enabled`
|
||||
- `event`
|
||||
- `action`
|
||||
- `pattern`
|
||||
3. Display them as a table:
|
||||
|
||||
| Rule | Enabled | Event | Pattern | File |
|
||||
|------|---------|-------|---------|------|
|
||||
|
||||
4. Show the rule count and remind the user that `/hookify-configure` can change state later.
|
||||
@ -1,50 +0,0 @@
|
||||
---
|
||||
description: Create hooks to prevent unwanted behaviors from conversation analysis or explicit instructions
|
||||
---
|
||||
|
||||
Create hook rules to prevent unwanted Claude Code behaviors by analyzing conversation patterns or explicit user instructions.
|
||||
|
||||
## Usage
|
||||
|
||||
`/hookify [description of behavior to prevent]`
|
||||
|
||||
If no arguments are provided, analyze the current conversation to find behaviors worth preventing.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Gather Behavior Info
|
||||
|
||||
- With arguments: parse the user's description of the unwanted behavior
|
||||
- Without arguments: use the `conversation-analyzer` agent to find:
|
||||
- explicit corrections
|
||||
- frustrated reactions to repeated mistakes
|
||||
- reverted changes
|
||||
- repeated similar issues
|
||||
|
||||
### Step 2: Present Findings
|
||||
|
||||
Show the user:
|
||||
|
||||
- behavior description
|
||||
- proposed event type
|
||||
- proposed pattern or matcher
|
||||
- proposed action
|
||||
|
||||
### Step 3: Generate Rule Files
|
||||
|
||||
For each approved rule, create a file at `.claude/hookify.{name}.local.md`:
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: rule-name
|
||||
enabled: true
|
||||
event: bash|file|stop|prompt|all
|
||||
action: block|warn
|
||||
pattern: "regex pattern"
|
||||
---
|
||||
Message shown when rule triggers.
|
||||
```
|
||||
|
||||
### Step 4: Confirm
|
||||
|
||||
Report created rules and how to manage them with `/hookify-list` and `/hookify-configure`.
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: "Quick commit with natural language file targeting — describe what to commit in plain English"
|
||||
argument-hint: "[target description] (blank = all changes)"
|
||||
description: Quick commit with natural language file targeting — describe what to commit in plain English
|
||||
argument-hint: [target description] (blank = all changes)
|
||||
---
|
||||
|
||||
# Smart Commit
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: "Create a GitHub PR from current branch with unpushed commits — discovers templates, analyzes changes, pushes"
|
||||
argument-hint: "[base-branch] (default: main)"
|
||||
description: Create a GitHub PR from current branch with unpushed commits — discovers templates, analyzes changes, pushes
|
||||
argument-hint: [base-branch] (default: main)
|
||||
---
|
||||
|
||||
# Create Pull Request
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
description: "Interactive PRD generator - problem-first, hypothesis-driven product spec with back-and-forth questioning"
|
||||
argument-hint: "[feature/product idea] (blank = start with questions)"
|
||||
description: Interactive PRD generator - problem-first, hypothesis-driven product spec with back-and-forth questioning
|
||||
argument-hint: [feature/product idea] (blank = start with questions)
|
||||
---
|
||||
|
||||
# Product Requirements Document Generator
|
||||
|
||||
@ -1,37 +0,0 @@
|
||||
---
|
||||
description: Comprehensive PR review using specialized agents
|
||||
---
|
||||
|
||||
Run a comprehensive multi-perspective review of a pull request.
|
||||
|
||||
## Usage
|
||||
|
||||
`/review-pr [PR-number-or-URL] [--focus=comments|tests|errors|types|code|simplify]`
|
||||
|
||||
If no PR is specified, review the current branch's PR. If no focus is specified, run the full review stack.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Identify the PR:
|
||||
- use `gh pr view` to get PR details, changed files, and diff
|
||||
2. Find project guidance:
|
||||
- look for `CLAUDE.md`, lint config, TypeScript config, repo conventions
|
||||
3. Run specialized review agents:
|
||||
- `code-reviewer`
|
||||
- `comment-analyzer`
|
||||
- `pr-test-analyzer`
|
||||
- `silent-failure-hunter`
|
||||
- `type-design-analyzer`
|
||||
- `code-simplifier`
|
||||
4. Aggregate results:
|
||||
- dedupe overlapping findings
|
||||
- rank by severity
|
||||
5. Report findings grouped by severity
|
||||
|
||||
## Confidence Rule
|
||||
|
||||
Only report issues with confidence >= 80:
|
||||
|
||||
- Critical: bugs, security, data loss
|
||||
- Important: missing tests, quality problems, style violations
|
||||
- Advisory: suggestions only when explicitly requested
|
||||
@ -29,9 +29,8 @@ Use `/sessions info` when you need operator-surface context for a swarm: branch,
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
|
||||
const sm = require(_r + '/scripts/lib/session-manager');
|
||||
const aa = require(_r + '/scripts/lib/session-aliases');
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
const path = require('path');
|
||||
|
||||
const result = sm.getAllSessions({ limit: 20 });
|
||||
@ -71,9 +70,8 @@ Load and display a session's content (by ID or alias).
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
|
||||
const sm = require(_r + '/scripts/lib/session-manager');
|
||||
const aa = require(_r + '/scripts/lib/session-aliases');
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
const id = process.argv[1];
|
||||
|
||||
// First try to resolve as alias
|
||||
@ -145,9 +143,8 @@ Create a memorable alias for a session.
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
|
||||
const sm = require(_r + '/scripts/lib/session-manager');
|
||||
const aa = require(_r + '/scripts/lib/session-aliases');
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const sessionId = process.argv[1];
|
||||
const aliasName = process.argv[2];
|
||||
@ -186,8 +183,7 @@ Delete an existing alias.
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
|
||||
const aa = require(_r + '/scripts/lib/session-aliases');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const aliasName = process.argv[1];
|
||||
if (!aliasName) {
|
||||
@ -216,9 +212,8 @@ Show detailed information about a session.
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
|
||||
const sm = require(_r + '/scripts/lib/session-manager');
|
||||
const aa = require(_r + '/scripts/lib/session-aliases');
|
||||
const sm = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-manager');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const id = process.argv[1];
|
||||
const resolved = aa.resolveAlias(id);
|
||||
@ -267,8 +262,7 @@ Show all session aliases.
|
||||
**Script:**
|
||||
```bash
|
||||
node -e "
|
||||
const _r = (()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();
|
||||
const aa = require(_r + '/scripts/lib/session-aliases');
|
||||
const aa = require((()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q)))return c}}catch(x){}return d})()+'/scripts/lib/session-aliases');
|
||||
|
||||
const aliases = aa.listAliases();
|
||||
console.log('Session Aliases (' + aliases.length + '):');
|
||||
|
||||
@ -13,21 +13,21 @@ Shows a comprehensive health dashboard for all skills in the portfolio with succ
|
||||
Run the skill health CLI in dashboard mode:
|
||||
|
||||
```bash
|
||||
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
|
||||
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
|
||||
node "$ECC_ROOT/scripts/skills-health.js" --dashboard
|
||||
```
|
||||
|
||||
For a specific panel only:
|
||||
|
||||
```bash
|
||||
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
|
||||
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
|
||||
node "$ECC_ROOT/scripts/skills-health.js" --dashboard --panel failures
|
||||
```
|
||||
|
||||
For machine-readable output:
|
||||
|
||||
```bash
|
||||
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
|
||||
ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
|
||||
node "$ECC_ROOT/scripts/skills-health.js" --dashboard --json
|
||||
```
|
||||
|
||||
|
||||
@ -1,239 +0,0 @@
|
||||
# Hermes / OpenClaw -> ECC Migration
|
||||
|
||||
This document is the public migration guide for moving a Hermes or OpenClaw-style operator setup into the current ECC model.
|
||||
|
||||
The goal is not to reproduce a private operator workspace byte-for-byte.
|
||||
|
||||
The goal is to preserve the useful workflow surface:
|
||||
|
||||
- reusable skills
|
||||
- stable automation entrypoints
|
||||
- cross-harness portability
|
||||
- schedulers / reminders / dispatch
|
||||
- durable context and operator memory
|
||||
|
||||
while removing the parts that should stay private:
|
||||
|
||||
- secrets
|
||||
- personal datasets
|
||||
- account tokens
|
||||
- local-only business artifacts
|
||||
|
||||
## Migration Thesis
|
||||
|
||||
Treat Hermes and OpenClaw as source systems, not as the final runtime.
|
||||
|
||||
ECC is the durable public system:
|
||||
|
||||
- skills
|
||||
- agents
|
||||
- commands
|
||||
- hooks
|
||||
- install surfaces
|
||||
- session adapters
|
||||
- ECC 2.0 control-plane work
|
||||
|
||||
Hermes and OpenClaw are useful inputs because they contain repeated operator workflows that can be distilled into ECC-native surfaces.
|
||||
|
||||
That means the shortest safe path is:
|
||||
|
||||
1. extract the reusable behavior
|
||||
2. translate it into ECC-native skills, hooks, docs, or adapter work
|
||||
3. keep secrets and personal data outside the repo
|
||||
|
||||
## Current Workspace Model
|
||||
|
||||
Use the current workspace split consistently:
|
||||
|
||||
- live code work happens in cloned repos under `~/GitHub`
|
||||
- repo-specific active execution context lives in repo-level `WORKING-CONTEXT.md`
|
||||
- broader non-code context can live in KB/archive layers
|
||||
- durable cross-machine truth should prefer GitHub, Linear, and the knowledge base
|
||||
|
||||
Do not rebuild a shadow private workspace inside the public repo.
|
||||
|
||||
## Translation Map
|
||||
|
||||
### 1. Scheduler / cron layer
|
||||
|
||||
Source examples:
|
||||
|
||||
- `cron/scheduler.py`
|
||||
- `jobs.py`
|
||||
- recurring readiness or accountability loops
|
||||
|
||||
Translate into:
|
||||
|
||||
- Claude-native scheduling where available
|
||||
- ECC hook / command automation for local repeatability
|
||||
- ECC 2.0 scheduler work under issue `#1050`
|
||||
|
||||
Today, the repo already has the right public framing:
|
||||
|
||||
- hooks for low-latency repo-local automation
|
||||
- commands for explicit operator actions
|
||||
- ECC 2.0 as the future long-lived scheduling/control plane
|
||||
|
||||
### 2. Gateway / dispatch layer
|
||||
|
||||
Source examples:
|
||||
|
||||
- Hermes gateway
|
||||
- mobile dispatch / remote nudges
|
||||
- operator routing between active sessions
|
||||
|
||||
Translate into:
|
||||
|
||||
- ECC session adapter and control-plane work
|
||||
- orchestration/session inspection commands
|
||||
- ECC 2.0 control-plane backlog under:
|
||||
- `#1045`
|
||||
- `#1046`
|
||||
- `#1047`
|
||||
- `#1048`
|
||||
|
||||
The public repo should describe the adapter boundary and control-plane model, not pretend the remote operator shell is already fully GA.
|
||||
|
||||
### 3. Memory layer
|
||||
|
||||
Source examples:
|
||||
|
||||
- `memory_tool.py`
|
||||
- local operator memory
|
||||
- business / ops context stores
|
||||
|
||||
Translate into:
|
||||
|
||||
- `knowledge-ops`
|
||||
- repo `WORKING-CONTEXT.md`
|
||||
- GitHub / Linear / KB-backed durable context
|
||||
- future deep memory work under `#1049`
|
||||
|
||||
The important distinction is:
|
||||
|
||||
- repo execution context belongs near the repo
|
||||
- broader non-code memory belongs in KB/archive systems
|
||||
- the public repo should document the boundary, not store private memory dumps
|
||||
|
||||
### 4. Skill layer
|
||||
|
||||
Source examples:
|
||||
|
||||
- Hermes skills
|
||||
- OpenClaw skills
|
||||
- generated operator playbooks
|
||||
|
||||
Translate into:
|
||||
|
||||
- ECC-native top-level skills when the workflow is reusable
|
||||
- docs/examples when the content is only a template
|
||||
- hooks or commands when the behavior is procedural rather than knowledge-shaped
|
||||
|
||||
Recent examples already salvaged this way:
|
||||
|
||||
- `knowledge-ops`
|
||||
- `github-ops`
|
||||
- `hookify-rules`
|
||||
- `automation-audit-ops`
|
||||
- `email-ops`
|
||||
- `finance-billing-ops`
|
||||
- `messages-ops`
|
||||
- `research-ops`
|
||||
- `terminal-ops`
|
||||
- `ecc-tools-cost-audit`
|
||||
|
||||
### 5. Tool / service layer
|
||||
|
||||
Source examples:
|
||||
|
||||
- custom service wrappers
|
||||
- API-key-backed local tools
|
||||
- browser automation glue
|
||||
|
||||
Translate into:
|
||||
|
||||
- MCP-backed surfaces when a connector exists
|
||||
- ECC-native operator skills when the workflow logic is the real asset
|
||||
- adapter/control-plane work when the missing piece is session/runtime coordination
|
||||
|
||||
Do not import opaque third-party runtimes into ECC just because a private workflow depended on them.
|
||||
|
||||
If a workflow is valuable:
|
||||
|
||||
1. understand the behavior
|
||||
2. rebuild the minimum ECC-native version
|
||||
3. document the auth/connectors required locally
|
||||
|
||||
## What Already Exists Publicly
|
||||
|
||||
The current repo already covers meaningful parts of the migration:
|
||||
|
||||
- ECC 2.0 adapter/control-plane discovery docs
|
||||
- orchestration/session inspection substrate
|
||||
- operator workflow skills
|
||||
- cost / billing / workflow audit skills
|
||||
- cross-harness install surfaces
|
||||
- AgentShield for config and agent-surface scanning
|
||||
|
||||
This means the migration problem is no longer "start from zero."
|
||||
|
||||
It is mostly:
|
||||
|
||||
- distilling missing private workflows
|
||||
- clarifying public docs
|
||||
- continuing the ECC 2.0 operator/control-plane buildout
|
||||
|
||||
ECC 2.0 now ships a bounded migration audit entrypoint:
|
||||
|
||||
- `ecc migrate audit --source ~/.hermes`
|
||||
- `ecc migrate plan --source ~/.hermes --output migration-plan.md`
|
||||
- `ecc migrate scaffold --source ~/.hermes --output-dir migration-artifacts`
|
||||
- `ecc migrate import-skills --source ~/.hermes --output-dir migration-artifacts/skills`
|
||||
- `ecc migrate import-tools --source ~/.hermes --output-dir migration-artifacts/tools`
|
||||
- `ecc migrate import-plugins --source ~/.hermes --output-dir migration-artifacts/plugins`
|
||||
- `ecc migrate import-schedules --source ~/.hermes --dry-run`
|
||||
- `ecc migrate import-remote --source ~/.hermes --dry-run`
|
||||
- `ecc migrate import-env --source ~/.hermes --dry-run`
|
||||
- `ecc migrate import-memory --source ~/.hermes`
|
||||
|
||||
Use that first to inventory the legacy workspace and map detected surfaces onto the current ECC2 scheduler, remote dispatch, memory graph, templates, and manual-translation lanes.
|
||||
|
||||
## What Still Belongs In Backlog
|
||||
|
||||
The remaining large migration themes are already tracked:
|
||||
|
||||
- `#1051` Hermes/OpenClaw migration
|
||||
- `#1049` deep memory layer
|
||||
- `#1050` autonomous scheduling
|
||||
- `#1048` universal harness compatibility layer
|
||||
- `#1046` agent orchestrator
|
||||
- `#1045` multi-session TUI manager
|
||||
- `#1047` visual worktree manager
|
||||
|
||||
That is the right place for the unresolved control-plane work.
|
||||
|
||||
Do not pretend the migration is "done" just because the public docs exist.
|
||||
|
||||
## Recommended Bring-Up Order
|
||||
|
||||
1. Keep the public ECC repo as the canonical reusable layer.
|
||||
2. Port reusable Hermes/OpenClaw workflows into ECC-native skills one lane at a time.
|
||||
3. Keep private auth and personal context outside the repo.
|
||||
4. Use GitHub / Linear / KB systems as durable truth.
|
||||
5. Treat ECC 2.0 as the path to a native operator shell, not as a finished product.
|
||||
|
||||
## Decision Rule
|
||||
|
||||
When reviewing a Hermes or OpenClaw artifact, ask:
|
||||
|
||||
1. Is this reusable across operators or only personal?
|
||||
2. Is the asset mainly knowledge, procedure, or runtime behavior?
|
||||
3. Should it become:
|
||||
- a skill
|
||||
- a command
|
||||
- a hook
|
||||
- a doc/example
|
||||
- a control-plane issue
|
||||
4. Does shipping it publicly leak secrets, private datasets, or personal operating state?
|
||||
|
||||
Only ship the reusable surface.
|
||||
@ -1,112 +0,0 @@
|
||||
# Hermes x ECC Setup
|
||||
|
||||
Hermes is the operator shell. ECC is the reusable system behind it.
|
||||
|
||||
This guide is the public, sanitized version of the Hermes stack used to run content, outreach, research, sales ops, finance checks, and engineering workflows from one terminal-native surface.
|
||||
|
||||
## What Ships Publicly
|
||||
|
||||
- ECC skills, agents, commands, hooks, and MCP configs from this repo
|
||||
- Hermes-generated workflow skills that are stable enough to reuse
|
||||
- a documented operator topology for chat, crons, workspace memory, and distribution flows
|
||||
- launch collateral for sharing the stack publicly
|
||||
|
||||
This guide does not include private secrets, live tokens, personal data, or a raw `~/.hermes` export.
|
||||
|
||||
## Architecture
|
||||
|
||||
Use Hermes as the front door and ECC as the reusable workflow substrate.
|
||||
|
||||
```text
|
||||
Telegram / CLI / TUI
|
||||
↓
|
||||
Hermes
|
||||
↓
|
||||
ECC skills + hooks + MCPs + generated workflow packs
|
||||
↓
|
||||
Google Drive / GitHub / browser automation / research APIs / media tools / finance tools
|
||||
```
|
||||
|
||||
## Public Workspace Map
|
||||
|
||||
Use this as the minimal surface to reproduce the setup without leaking private state.
|
||||
|
||||
- `~/.hermes/config.yaml`
|
||||
- model routing
|
||||
- MCP server registration
|
||||
- plugin loading
|
||||
- `~/.hermes/skills/ecc-imports/`
|
||||
- ECC skills copied in for Hermes-native use
|
||||
- `skills/hermes-generated/`
|
||||
- operator patterns distilled from repeated Hermes sessions
|
||||
- `~/.hermes/plugins/`
|
||||
- bridge plugins for hooks, reminders, and workflow-specific tool glue
|
||||
- `~/.hermes/cron/jobs.json`
|
||||
- scheduled automation runs with explicit prompts and channels
|
||||
- `~/.hermes/workspace/`
|
||||
- business, ops, health, content, and memory artifacts
|
||||
|
||||
## Recommended Capability Stack
|
||||
|
||||
### Core
|
||||
|
||||
- Hermes for chat, cron, orchestration, and workspace state
|
||||
- ECC for skills, rules, prompts, and cross-harness conventions
|
||||
- GitHub + Context7 + Exa + Firecrawl + Playwright as the baseline MCP layer
|
||||
|
||||
### Content
|
||||
|
||||
- FFmpeg for local edit and assembly
|
||||
- Remotion for programmable clips
|
||||
- fal.ai for image/video generation
|
||||
- ElevenLabs for voice, cleanup, and audio packaging
|
||||
- CapCut or VectCutAPI for final social-native polish
|
||||
|
||||
### Business Ops
|
||||
|
||||
- Google Drive as the system of record for docs, sheets, decks, and research dumps
|
||||
- Stripe for revenue and payment operations
|
||||
- GitHub for engineering execution
|
||||
- Telegram and iMessage-style channels for urgent nudges and approvals
|
||||
|
||||
## What Still Requires Local Auth
|
||||
|
||||
These stay local and should be configured per operator:
|
||||
|
||||
- Google OAuth token for Drive / Docs / Sheets / Slides
|
||||
- X / LinkedIn / outbound distribution credentials
|
||||
- Stripe keys
|
||||
- browser automation credentials and stealth/proxy settings
|
||||
- any CRM or project system credentials such as Linear or Apollo
|
||||
- Apple Health export or ingest path if health automations are enabled
|
||||
|
||||
## Suggested Bring-Up Order
|
||||
|
||||
0. Run `ecc migrate audit --source ~/.hermes` first to inventory the legacy workspace and see which parts already map onto ECC2.
|
||||
0.5. Generate and review artifacts with `ecc migrate plan` / `ecc migrate scaffold`, scaffold reusable legacy skills with `ecc migrate import-skills --output-dir migration-artifacts/skills`, scaffold legacy tool translation templates with `ecc migrate import-tools --output-dir migration-artifacts/tools`, scaffold legacy bridge plugins with `ecc migrate import-plugins --output-dir migration-artifacts/plugins`, preview recurring jobs with `ecc migrate import-schedules --dry-run`, preview gateway dispatch with `ecc migrate import-remote --dry-run`, preview safe env/service context with `ecc migrate import-env --dry-run`, then import sanitized workspace memory with `ecc migrate import-memory`.
|
||||
1. Install ECC and verify the baseline harness setup.
|
||||
2. Install Hermes and point it at ECC-imported skills.
|
||||
3. Register the MCP servers you actually use every day.
|
||||
4. Authenticate Google Drive first, then GitHub, then distribution channels.
|
||||
5. Start with a small cron surface: readiness check, content accountability, inbox triage, revenue monitor.
|
||||
6. Only then add heavier personal workflows like health, relationship graphing, or outbound sequencing.
|
||||
|
||||
## Why Hermes x ECC
|
||||
|
||||
This stack is useful when you want:
|
||||
|
||||
- one terminal-native place to run business and engineering operations
|
||||
- reusable skills instead of one-off prompts
|
||||
- automation that can nudge, audit, and escalate
|
||||
- a public repo that shows the system shape without exposing your private operator state
|
||||
|
||||
## Public Preview Scope
|
||||
|
||||
ECC 2.0 preview documents the Hermes surface and ships launch collateral now.
|
||||
|
||||
The remaining private pieces can be layered later:
|
||||
|
||||
- additional sanitized templates
|
||||
- richer public examples
|
||||
- more generated workflow packs
|
||||
- tighter CRM and Google Workspace integrations
|
||||
@ -1,214 +0,0 @@
|
||||
# Manual Adaptation Guide for Non-Native Harnesses
|
||||
|
||||
Use this guide when you want ECC behavior inside a harness that does not natively load `.claude/`, `.codex/`, `.opencode/`, `.cursor/`, or `.agent/` layouts.
|
||||
|
||||
This is the fallback path for tools like Grok and other chat-style interfaces that can accept system prompts, uploaded files, or pasted instructions, but cannot execute the repo's native install surfaces directly.
|
||||
|
||||
## When to Use This
|
||||
|
||||
Use manual adaptation when the target harness:
|
||||
|
||||
- does not auto-load repo folders
|
||||
- does not support custom slash commands
|
||||
- does not support hooks
|
||||
- does not support repo-local skill activation
|
||||
- has partial or no filesystem/tool access
|
||||
|
||||
Prefer a first-class ECC target whenever one exists:
|
||||
|
||||
- Claude Code
|
||||
- Codex
|
||||
- Cursor
|
||||
- OpenCode
|
||||
- CodeBuddy
|
||||
- Antigravity
|
||||
|
||||
Use this guide only when you need ECC behavior in a non-native harness.
|
||||
|
||||
## What You Are Reproducing
|
||||
|
||||
When you adapt ECC manually, you are trying to preserve four things:
|
||||
|
||||
1. Focused context instead of dumping the whole repo.
|
||||
2. Skill activation cues instead of hoping the model guesses the workflow.
|
||||
3. Command intent even when the harness has no slash-command system.
|
||||
4. Hook discipline even when the harness has no native automation.
|
||||
|
||||
You are not trying to mirror every file in the repo. You are trying to recreate the useful behavior with the smallest possible context bundle.
|
||||
|
||||
## The ECC-Native Fallback
|
||||
|
||||
Default to manual selection from the repo itself.
|
||||
|
||||
Start with only the files you actually need:
|
||||
|
||||
- one language or framework skill
|
||||
- one workflow skill
|
||||
- one domain skill if the task is specialized
|
||||
- one agent or command only if the harness benefits from explicit orchestration
|
||||
|
||||
Good minimal examples:
|
||||
|
||||
- Python feature work:
|
||||
- `skills/python-patterns/SKILL.md`
|
||||
- `skills/tdd-workflow/SKILL.md`
|
||||
- `skills/verification-loop/SKILL.md`
|
||||
- TypeScript API work:
|
||||
- `skills/backend-patterns/SKILL.md`
|
||||
- `skills/security-review/SKILL.md`
|
||||
- `skills/tdd-workflow/SKILL.md`
|
||||
- Content/outbound work:
|
||||
- `skills/brand-voice/SKILL.md`
|
||||
- `skills/content-engine/SKILL.md`
|
||||
- `skills/crosspost/SKILL.md`
|
||||
|
||||
If the harness supports file upload, upload only those files.
|
||||
|
||||
If the harness only supports pasted context, extract the relevant sections and paste a compressed bundle rather than the raw full files.
|
||||
|
||||
## Manual Context Packing
|
||||
|
||||
You do not need extra tooling to do this.
|
||||
|
||||
Use the repo directly:
|
||||
|
||||
```bash
|
||||
cd /path/to/everything-claude-code
|
||||
|
||||
sed -n '1,220p' skills/tdd-workflow/SKILL.md > /tmp/ecc-context.md
|
||||
printf '\n\n---\n\n' >> /tmp/ecc-context.md
|
||||
sed -n '1,220p' skills/backend-patterns/SKILL.md >> /tmp/ecc-context.md
|
||||
printf '\n\n---\n\n' >> /tmp/ecc-context.md
|
||||
sed -n '1,220p' skills/security-review/SKILL.md >> /tmp/ecc-context.md
|
||||
```
|
||||
|
||||
You can also use `rg` to identify the right skills before packing:
|
||||
|
||||
```bash
|
||||
rg -n "When to use|Use when|Trigger" skills -g 'SKILL.md'
|
||||
```
|
||||
|
||||
Optional: if you already use a repo packer like `repomix`, it can help compress selected files into one handoff document. It is a convenience tool, not the canonical ECC path.
|
||||
|
||||
## Compression Rules
|
||||
|
||||
When manually packing ECC for another harness:
|
||||
|
||||
- keep the task framing
|
||||
- keep the activation conditions
|
||||
- keep the workflow steps
|
||||
- keep the critical examples
|
||||
- remove repetitive prose first
|
||||
- remove unrelated variants second
|
||||
- avoid pasting whole directories when one or two skills are enough
|
||||
|
||||
If you need a tighter prompt format, convert the essential parts into a compact structured block:
|
||||
|
||||
```xml
|
||||
<skill name="tdd-workflow">
|
||||
<when>New feature, bug fix, or refactor that should be test-first.</when>
|
||||
<steps>
|
||||
<step>Write a failing test.</step>
|
||||
<step>Make it pass with the smallest change.</step>
|
||||
<step>Refactor and rerun validation.</step>
|
||||
</steps>
|
||||
</skill>
|
||||
```
|
||||
|
||||
## Reproducing Commands
|
||||
|
||||
If the harness has no slash-command system, define a small command registry in the system prompt or session preamble.
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
Command registry:
|
||||
- /plan -> use planner-style reasoning, produce a short execution plan, then act
|
||||
- /tdd -> follow the tdd-workflow skill
|
||||
- /review -> switch into code-review mode and enumerate findings first
|
||||
- /verify -> run a verification loop before claiming completion
|
||||
```
|
||||
|
||||
You are not implementing real commands. You are giving the harness explicit invocation handles that map to ECC behavior.
|
||||
|
||||
## Reproducing Hooks
|
||||
|
||||
If the harness has no native hooks, move the hook intent into the standing instructions.
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
Before writing code:
|
||||
1. Check whether a relevant skill should be activated.
|
||||
2. Check for security-sensitive changes.
|
||||
3. Prefer tests before implementation when feasible.
|
||||
|
||||
Before finalizing:
|
||||
1. Re-read the user request.
|
||||
2. Verify the main changed paths.
|
||||
3. State what was actually validated and what was not.
|
||||
```
|
||||
|
||||
That does not recreate true automation, but it captures the operational discipline of ECC.
|
||||
|
||||
## Harness Capability Matrix
|
||||
|
||||
| Capability | First-Class ECC Targets | Manual-Adaptation Targets |
|
||||
| --- | --- | --- |
|
||||
| Folder-based install | Native | No |
|
||||
| Slash commands | Native | Simulated in prompt |
|
||||
| Hooks | Native | Simulated in prompt |
|
||||
| Skill activation | Native | Manual |
|
||||
| Repo-local tooling | Native | Depends on harness |
|
||||
| Context packing | Optional | Required |
|
||||
|
||||
## Practical Grok-Style Setup
|
||||
|
||||
1. Pick the smallest useful bundle.
|
||||
2. Pack the selected ECC skill files into one upload or paste block.
|
||||
3. Add a short command registry.
|
||||
4. Add standing “hook intent” instructions.
|
||||
5. Start with one task and verify the harness follows the workflow before scaling up.
|
||||
|
||||
Example starter preamble:
|
||||
|
||||
```text
|
||||
You are operating with a manually adapted ECC bundle.
|
||||
|
||||
Active skills:
|
||||
- backend-patterns
|
||||
- tdd-workflow
|
||||
- security-review
|
||||
|
||||
Command registry:
|
||||
- /plan
|
||||
- /tdd
|
||||
- /verify
|
||||
|
||||
Before writing code, follow the active skill instructions.
|
||||
Before finalizing, verify what changed and report any remaining gaps.
|
||||
```
|
||||
|
||||
## Limitations
|
||||
|
||||
Manual adaptation is useful, but it is still second-class compared with native targets.
|
||||
|
||||
You lose:
|
||||
|
||||
- automatic install and sync
|
||||
- native hook execution
|
||||
- true command plumbing
|
||||
- reliable skill discovery at runtime
|
||||
- built-in multi-agent/worktree orchestration
|
||||
|
||||
So the rule is simple:
|
||||
|
||||
- use manual adaptation to carry ECC behavior into non-native harnesses
|
||||
- use native ECC targets whenever you want the full system
|
||||
|
||||
## Related Work
|
||||
|
||||
- [Issue #1186](https://github.com/affaan-m/everything-claude-code/issues/1186)
|
||||
- [Discussion #1077](https://github.com/affaan-m/everything-claude-code/discussions/1077)
|
||||
- [Antigravity Guide](./ANTIGRAVITY-GUIDE.md)
|
||||
- [Troubleshooting](./TROUBLESHOOTING.md)
|
||||
@ -909,7 +909,7 @@ npm run test:e2e
|
||||
## Additional Resources
|
||||
|
||||
- [CONTRIBUTING.md](../CONTRIBUTING.md) - General contribution guidelines
|
||||
- [project-guidelines-template](./examples/project-guidelines-template.md) - Project-specific skill template
|
||||
- [project-guidelines-example](../skills/project-guidelines-example/SKILL.md) - Project-specific skill template
|
||||
- [coding-standards](../skills/coding-standards/SKILL.md) - Example of standards skill
|
||||
- [tdd-workflow](../skills/tdd-workflow/SKILL.md) - Example of workflow skill
|
||||
- [security-review](../skills/security-review/SKILL.md) - Example of domain knowledge skill
|
||||
|
||||
@ -69,7 +69,6 @@ exit 2
|
||||
|
||||
## Related ECC Docs
|
||||
|
||||
- [hook-bug-workarounds.md](./hook-bug-workarounds.md) for the shorter hook/compaction/MCP recovery checklist.
|
||||
- [hooks/README.md](../hooks/README.md) for ECC's documented hook lifecycle and exit-code behavior.
|
||||
- [token-optimization.md](./token-optimization.md) for cost and context management settings.
|
||||
- [issue #644](https://github.com/affaan-m/everything-claude-code/issues/644) for the original report and tested environment.
|
||||
|
||||
@ -1,140 +0,0 @@
|
||||
# Capability Surface Selection
|
||||
|
||||
Use this as the routing guide when deciding whether a capability belongs in a rule, a skill, an MCP server, or a plain CLI/API workflow.
|
||||
|
||||
ECC does not treat these surfaces as interchangeable. The goal is to put each capability in the narrowest surface that preserves correctness, keeps token cost under control, and does not create unnecessary runtime or supply-chain drag.
|
||||
|
||||
## The Short Version
|
||||
|
||||
- `rules/` are for deterministic, always-on constraints that should be injected when a path or event matches.
|
||||
- `skills/` are for on-demand workflows, richer playbooks, and token-expensive guidance that should load only when relevant.
|
||||
- `MCP` is for interactive structured capabilities that benefit from a long-lived tool/resource surface across sessions or clients.
|
||||
- local `CLI` or repo scripts are for simple deterministic actions that do not need a persistent server.
|
||||
- direct `API` calls inside a skill are for narrow remote actions where a full MCP server would be heavier than the problem.
|
||||
|
||||
## Decision Order
|
||||
|
||||
Ask these questions in order:
|
||||
|
||||
1. Should this happen every time a path or event matches, with no model judgment involved?
|
||||
- Use a `rule`.
|
||||
2. Is this mostly a playbook, workflow, or advisory layer that should load only when the task actually needs it?
|
||||
- Use a `skill`.
|
||||
3. Does the capability need a structured interactive tool/resource interface that multiple harnesses or clients should call repeatedly?
|
||||
- Use `MCP`.
|
||||
4. Is it a simple local action that can run as a script without keeping a server alive?
|
||||
- Use a local `CLI` entrypoint or repo script, then wrap it with a skill if needed.
|
||||
5. Is it just one narrow remote integration step inside a larger workflow?
|
||||
- Call the external `API` directly from the skill or script.
|
||||
|
||||
## Surface-by-Surface Guidance
|
||||
|
||||
### Rules
|
||||
|
||||
Use rules for:
|
||||
|
||||
- path-scoped coding invariants
|
||||
- safety floors and permission constraints
|
||||
- harness/runtime constraints that should always apply
|
||||
- deterministic reminders that should not depend on model discretion
|
||||
|
||||
Do not use rules for:
|
||||
|
||||
- large playbooks that would bloat every matching edit
|
||||
- optional workflows
|
||||
- expensive domain context that only matters some of the time
|
||||
|
||||
### Skills
|
||||
|
||||
Use skills for:
|
||||
|
||||
- multi-step workflows
|
||||
- judgment-heavy guidance
|
||||
- domain playbooks that are expensive enough to load only on demand
|
||||
- orchestration across scripts, APIs, MCP tools, and adjacent skills
|
||||
|
||||
Do not use skills as a dumping ground for static invariants that really want deterministic routing.
|
||||
|
||||
### MCP
|
||||
|
||||
Use MCP when the capability benefits from:
|
||||
|
||||
- structured tool inputs/outputs
|
||||
- reusable resources or prompts
|
||||
- repeated cross-client usage
|
||||
- a stable interface that should work across Claude Code, Codex, Cursor, OpenCode, and related harnesses
|
||||
- a long-lived server process being worth the operational overhead
|
||||
|
||||
Avoid MCP when:
|
||||
|
||||
- the job is a one-shot local command
|
||||
- the only thing the server would do is shell out once
|
||||
- the server adds more install/runtime burden than product value
|
||||
|
||||
### CLI / Repo Scripts
|
||||
|
||||
Prefer a local script or CLI when:
|
||||
|
||||
- the action is deterministic
|
||||
- startup is cheap
|
||||
- the workflow is mostly local
|
||||
- there is no benefit to exposing a persistent tool/resource surface
|
||||
|
||||
This is often the right choice for:
|
||||
|
||||
- lint/test/build wrappers
|
||||
- local transforms
|
||||
- small installers
|
||||
- content generation that runs once per invocation
|
||||
|
||||
### Direct API Calls
|
||||
|
||||
Prefer direct API calls inside an existing skill or script when:
|
||||
|
||||
- the integration is narrow
|
||||
- the remote action is part of a larger workflow
|
||||
- you do not need a reusable transport surface yet
|
||||
|
||||
If the same remote integration becomes central, repeated, and multi-client, that is the signal to graduate it into an MCP surface.
|
||||
|
||||
## Cost and Reliability Bias
|
||||
|
||||
When two options are both viable:
|
||||
|
||||
- prefer the smaller runtime surface
|
||||
- prefer the lower token overhead
|
||||
- prefer the path with fewer external moving parts
|
||||
- prefer ECC-native packaging over introducing another third-party dependency
|
||||
|
||||
Do not normalize external plugin or package dependencies as first-class ECC surfaces unless the capability is clearly worth the maintenance, security, and install burden.
|
||||
|
||||
## Repo Policy
|
||||
|
||||
When bringing in ideas from external repos:
|
||||
|
||||
- copy the underlying idea, not the external dependency
|
||||
- repackage it as an ECC-native rule, skill, script, or MCP surface
|
||||
- rename it if the functionality has been materially expanded or reshaped for ECC
|
||||
- avoid shipping instructions that require users to install unrelated third-party packages unless that dependency is intentional, audited, and central to the workflow
|
||||
|
||||
## Examples
|
||||
|
||||
- A backend auth invariant that should always apply to `api/**` edits:
|
||||
- `rule`
|
||||
- A deeper API design and pagination playbook:
|
||||
- `skill`
|
||||
- A reusable remote search surface used across multiple harnesses:
|
||||
- `MCP`
|
||||
- A one-shot repo analyzer that reads local files and writes a report:
|
||||
- local `CLI` or script, optionally wrapped by a `skill`
|
||||
- A single billing-portal session creation step inside a broader customer-ops workflow:
|
||||
- direct `API` call inside the workflow
|
||||
|
||||
## Practical Heuristic
|
||||
|
||||
If you are unsure, start smaller:
|
||||
|
||||
- start with a `rule` for deterministic invariants
|
||||
- start with a `skill` for guidance/workflow
|
||||
- start with a script for one-shot execution
|
||||
- promote to `MCP` only when the structured server boundary is clearly paying for itself
|
||||
@ -1,84 +0,0 @@
|
||||
# Product Capability Template
|
||||
|
||||
Use this when product intent exists but the implementation constraints are still implicit.
|
||||
|
||||
The purpose is to create a durable capability contract, not another vague planning doc.
|
||||
|
||||
## Capability
|
||||
|
||||
- **Capability name:**
|
||||
- **Source:** PRD / issue / discussion / roadmap / founder note
|
||||
- **Primary actor:**
|
||||
- **Outcome after ship:**
|
||||
- **Success signal:**
|
||||
|
||||
## Product Intent
|
||||
|
||||
Describe the user-visible promise in one short paragraph.
|
||||
|
||||
## Constraints
|
||||
|
||||
List the rules that must be true before implementation starts:
|
||||
|
||||
- business rules
|
||||
- scope boundaries
|
||||
- invariants
|
||||
- rollout constraints
|
||||
- migration constraints
|
||||
- backwards compatibility constraints
|
||||
- billing / auth / compliance constraints
|
||||
|
||||
## Actors and Surfaces
|
||||
|
||||
- actor(s)
|
||||
- UI surfaces
|
||||
- API surfaces
|
||||
- automation / operator surfaces
|
||||
- reporting / dashboard surfaces
|
||||
|
||||
## States and Transitions
|
||||
|
||||
Describe the lifecycle in terms of explicit states and allowed transitions.
|
||||
|
||||
Example:
|
||||
|
||||
- `draft -> active -> paused -> completed`
|
||||
- `pending -> approved -> provisioned -> revoked`
|
||||
|
||||
## Interface Contract
|
||||
|
||||
- inputs
|
||||
- outputs
|
||||
- required side effects
|
||||
- failure states
|
||||
- retries / recovery
|
||||
- idempotency expectations
|
||||
|
||||
## Data Implications
|
||||
|
||||
- source of truth
|
||||
- new entities or fields
|
||||
- ownership boundaries
|
||||
- retention / deletion expectations
|
||||
|
||||
## Security and Policy
|
||||
|
||||
- trust boundaries
|
||||
- permission requirements
|
||||
- abuse paths
|
||||
- policy / governance requirements
|
||||
|
||||
## Non-Goals
|
||||
|
||||
List what this capability explicitly does not own.
|
||||
|
||||
## Open Questions
|
||||
|
||||
Capture the unresolved decisions blocking implementation.
|
||||
|
||||
## Handoff
|
||||
|
||||
- **Ready for implementation?**
|
||||
- **Needs architecture review?**
|
||||
- **Needs product clarification?**
|
||||
- **Next ECC lane:** `project-flow-ops` / `tdd-workflow` / `verification-loop` / other
|
||||
@ -1,74 +0,0 @@
|
||||
# Hook Bug Workarounds
|
||||
|
||||
Community-tested workarounds for current Claude Code bugs that can affect ECC hook-heavy setups.
|
||||
|
||||
This page is intentionally narrow: it collects the highest-signal operational fixes from the longer troubleshooting surface without repeating speculative or unsupported configuration advice. These are upstream Claude Code behaviors, not ECC bugs.
|
||||
|
||||
## When To Use This Page
|
||||
|
||||
Use this page when you are specifically debugging:
|
||||
|
||||
- false `Hook Error` labels on otherwise successful hook runs
|
||||
- earlier-than-expected compaction
|
||||
- MCP connectors that look authenticated but fail after compaction
|
||||
- hook edits that do not hot-reload
|
||||
- repeated `529 Overloaded` responses under heavy hook/tool pressure
|
||||
|
||||
For the fuller ECC troubleshooting surface, use [TROUBLESHOOTING.md](./TROUBLESHOOTING.md).
|
||||
|
||||
## High-Signal Workarounds
|
||||
|
||||
### False `Hook Error` labels
|
||||
|
||||
What helps:
|
||||
|
||||
- Consume stdin at the start of shell hooks (`input=$(cat)`).
|
||||
- Keep stdout quiet for simple allow/block hooks unless your hook explicitly requires structured stdout.
|
||||
- Send human-readable diagnostics to stderr.
|
||||
- Use the correct exit codes: `0` allow, `2` block, other non-zero values are treated as errors.
|
||||
|
||||
```bash
|
||||
input=$(cat)
|
||||
echo "[BLOCKED] Reason here" >&2
|
||||
exit 2
|
||||
```
|
||||
|
||||
### Earlier-than-expected compaction
|
||||
|
||||
What helps:
|
||||
|
||||
- Remove `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE` if lowering it causes earlier compaction in your build.
|
||||
- Prefer manual `/compact` at natural task boundaries.
|
||||
- Use ECC's `strategic-compact` guidance instead of forcing a lower threshold.
|
||||
|
||||
### MCP auth looks live but fails after compaction
|
||||
|
||||
What helps:
|
||||
|
||||
- Toggle the affected connector off and back on after compaction.
|
||||
- If your Claude Code build supports it, add a lightweight `PostCompact` reminder hook that tells you to re-check connector auth.
|
||||
- Treat this as a recovery reminder, not a permanent fix.
|
||||
|
||||
### Hook edits do not hot-reload
|
||||
|
||||
What helps:
|
||||
|
||||
- Restart the Claude Code session after changing hooks.
|
||||
- Advanced users sometimes use shell-local reload helpers, but ECC does not ship one because those approaches are shell- and platform-dependent.
|
||||
|
||||
### Repeated `529 Overloaded`
|
||||
|
||||
What helps:
|
||||
|
||||
- Reduce tool-definition pressure with `ENABLE_TOOL_SEARCH=auto:5` if your setup supports it.
|
||||
- Lower `MAX_THINKING_TOKENS` for routine work.
|
||||
- Route subagent work to a cheaper model such as `CLAUDE_CODE_SUBAGENT_MODEL=haiku` if your setup exposes that knob.
|
||||
- Disable unused MCP servers per project.
|
||||
- Compact manually at natural breakpoints instead of waiting for auto-compaction.
|
||||
|
||||
## Related ECC Docs
|
||||
|
||||
- [TROUBLESHOOTING.md](./TROUBLESHOOTING.md)
|
||||
- [token-optimization.md](./token-optimization.md)
|
||||
- [hooks/README.md](../hooks/README.md)
|
||||
- [issue #644](https://github.com/affaan-m/everything-claude-code/issues/644)
|
||||
@ -1,4 +1,4 @@
|
||||
**言語:** [English](../../README.md) | [Português (Brasil)](../pt-BR/README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](README.md) | [한국어](../ko-KR/README.md) | [Türkçe](../tr/README.md)
|
||||
**言語:** English | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](README.md) | [한국어](../ko-KR/README.md)
|
||||
|
||||
# Everything Claude Code
|
||||
|
||||
@ -13,15 +13,15 @@
|
||||
|
||||
|
||||
|
||||
> **140K+ stars** | **21K+ forks** | **170+ contributors** | **12+ language ecosystems**
|
||||
> **42K+ stars** | **5K+ forks** | **24 contributors** | **6 languages supported**
|
||||
|
||||
---
|
||||
|
||||
<div align="center">
|
||||
|
||||
**言語 / Language / 語言 / Dil**
|
||||
**言語 / Language / 語言**
|
||||
|
||||
[**English**](../../README.md) | [Português (Brasil)](../pt-BR/README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](README.md) | [한국어](../ko-KR/README.md) | [Türkçe](../tr/README.md)
|
||||
[**English**](README.md) | [简体中文](README.zh-CN.md) | [繁體中文](docs/zh-TW/README.md) | [日本語](docs/ja-JP/README.md)
|
||||
|
||||
</div>
|
||||
|
||||
@ -110,7 +110,7 @@
|
||||
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
|
||||
|
||||
# プラグインをインストール
|
||||
/plugin install ecc@ecc
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
### ステップ2：ルールをインストール（必須）
|
||||
@ -134,13 +134,13 @@ cp -r everything-claude-code/rules/golang/* ~/.claude/rules/
|
||||
|
||||
```bash
|
||||
# コマンドを試す（プラグインはネームスペース形式）
|
||||
/ecc:plan "ユーザー認証を追加"
|
||||
/everything-claude-code:plan "ユーザー認証を追加"
|
||||
|
||||
# 手動インストール（オプション2）は短縮形式：
|
||||
# /plan "ユーザー認証を追加"
|
||||
|
||||
# 利用可能なコマンドを確認
|
||||
/plugin list ecc@ecc
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
**完了です！** これで13のエージェント、43のスキル、31のコマンドにアクセスできます。
|
||||
@ -427,7 +427,7 @@ Duplicate hook file detected: ./hooks/hooks.json is already resolved to a loaded
|
||||
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
|
||||
|
||||
# プラグインをインストール
|
||||
/plugin install ecc@ecc
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
または、`~/.claude/settings.json` に直接追加：
|
||||
@ -435,7 +435,7 @@ Duplicate hook file detected: ./hooks/hooks.json is already resolved to a loaded
|
||||
```json
|
||||
{
|
||||
"extraKnownMarketplaces": {
|
||||
"ecc": {
|
||||
"everything-claude-code": {
|
||||
"source": {
|
||||
"source": "github",
|
||||
"repo": "affaan-m/everything-claude-code"
|
||||
@ -443,7 +443,7 @@ Duplicate hook file detected: ./hooks/hooks.json is already resolved to a loaded
|
||||
}
|
||||
},
|
||||
"enabledPlugins": {
|
||||
"ecc@ecc": true
|
||||
"everything-claude-code@everything-claude-code": true
|
||||
}
|
||||
}
|
||||
```
|
||||
@ -497,9 +497,7 @@ cp -r everything-claude-code/skills/* ~/.claude/skills/
|
||||
|
||||
#### settings.json にフックを追加
|
||||
|
||||
手動インストール時のみ、`hooks/hooks.json` のフックを `~/.claude/settings.json` にコピーします。
|
||||
|
||||
`/plugin install` で ECC を導入した場合は、これらのフックを `settings.json` にコピーしないでください。Claude Code v2.1+ はプラグインの `hooks/hooks.json` を自動読み込みするため、二重登録すると重複実行や `${CLAUDE_PLUGIN_ROOT}` の解決失敗が発生します。
|
||||
`hooks/hooks.json` のフックを `~/.claude/settings.json` にコピーします。
|
||||
|
||||
#### MCP を設定
|
||||
|
||||
|
||||
@ -207,8 +207,8 @@ Claudeの統合計画での欠落リスクを減らすために、両方のモ
|
||||
**計画が生成され、`.claude/plan/actual-feature-name.md`に保存されました**
|
||||
|
||||
**上記の計画をレビューしてください。以下のことができます:**
|
||||
- **計画を変更**: 調整が必要なことを教えてください、計画を更新します
|
||||
- **計画を実行**: 以下のコマンドを新しいセッションにコピー
|
||||
- **計画を変更**: 調整が必要なことを教えてください、計画を更新します
|
||||
- **計画を実行**: 以下のコマンドを新しいセッションにコピー
|
||||
|
||||
```
|
||||
/ccg:execute .claude/plan/actual-feature-name.md
|
||||
|
||||
@ -17,7 +17,7 @@ Everything Claude Code プロジェクトのインタラクティブなステッ
|
||||
## 前提条件
|
||||
|
||||
このスキルは起動前に Claude Code からアクセス可能である必要があります。ブートストラップには2つの方法があります：
|
||||
1. **プラグイン経由**: `/plugin install ecc@ecc` — プラグインがこのスキルを自動的にロードします
|
||||
1. **プラグイン経由**: `/plugin install everything-claude-code` — プラグインがこのスキルを自動的にロードします
|
||||
2. **手動**: このスキルのみを `~/.claude/skills/configure-ecc/SKILL.md` にコピーし、"configure ecc" と言って起動します
|
||||
|
||||
---
|
||||
@ -126,7 +126,7 @@ Options:
|
||||
|
||||
| スキル | 説明 |
|
||||
|-------|-------------|
|
||||
| `docs/examples/project-guidelines-template.md` | プロジェクト固有のスキルを作成するためのテンプレート |
|
||||
| `project-guidelines-example` | プロジェクト固有のスキルを作成するためのテンプレート |
|
||||
|
||||
### 2c: インストールの実行
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
**언어:** [English](../../README.md) | [Português (Brasil)](../pt-BR/README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](../ja-JP/README.md) | 한국어 | [Türkçe](../tr/README.md)
|
||||
**언어:** [English](../../README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](../ja-JP/README.md) | 한국어
|
||||
|
||||
# Everything Claude Code
|
||||
|
||||
@ -22,9 +22,9 @@
|
||||
|
||||
<div align="center">
|
||||
|
||||
**Language / 语言 / 語言 / 언어 / Dil**
|
||||
**Language / 语言 / 語言 / 언어**
|
||||
|
||||
[**English**](../../README.md) | [Português (Brasil)](../pt-BR/README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](../ja-JP/README.md) | [한국어](README.md) | [Türkçe](../tr/README.md)
|
||||
[**English**](../../README.md) | [简体中文](../../README.zh-CN.md) | [繁體中文](../zh-TW/README.md) | [日本語](../ja-JP/README.md) | [한국어](README.md)
|
||||
|
||||
</div>
|
||||
|
||||
@ -115,7 +115,7 @@
|
||||
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
|
||||
|
||||
# 플러그인 설치
|
||||
/plugin install ecc@ecc
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
### 2단계: 룰 설치 (필수)
|
||||
@ -141,13 +141,13 @@ cd everything-claude-code
|
||||
|
||||
```bash
|
||||
# 커맨드 실행 (플러그인 설치 시 네임스페이스 형태 사용)
|
||||
/ecc:plan "사용자 인증 추가"
|
||||
/everything-claude-code:plan "사용자 인증 추가"
|
||||
|
||||
# 수동 설치(옵션 2) 시에는 짧은 형태를 사용:
|
||||
# /plan "사용자 인증 추가"
|
||||
|
||||
# 사용 가능한 커맨드 확인
|
||||
/plugin list ecc@ecc
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
**끝!** 이제 16개 에이전트, 65개 스킬, 40개 커맨드를 사용할 수 있습니다.
|
||||
@ -359,7 +359,7 @@ Claude Code v2.1+는 설치된 플러그인의 `hooks/hooks.json`을 **자동으
|
||||
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
|
||||
|
||||
# 플러그인 설치
|
||||
/plugin install ecc@ecc
|
||||
/plugin install everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
또는 `~/.claude/settings.json`에 직접 추가:
|
||||
@ -367,7 +367,7 @@ Claude Code v2.1+는 설치된 플러그인의 `hooks/hooks.json`을 **자동으
|
||||
```json
|
||||
{
|
||||
"extraKnownMarketplaces": {
|
||||
"ecc": {
|
||||
"everything-claude-code": {
|
||||
"source": {
|
||||
"source": "github",
|
||||
"repo": "affaan-m/everything-claude-code"
|
||||
@ -375,7 +375,7 @@ Claude Code v2.1+는 설치된 플러그인의 `hooks/hooks.json`을 **자동으
|
||||
}
|
||||
},
|
||||
"enabledPlugins": {
|
||||
"ecc@ecc": true
|
||||
"everything-claude-code@everything-claude-code": true
|
||||
}
|
||||
}
|
||||
```
|
||||
@ -489,8 +489,8 @@ rules/
|
||||
|
||||
| 하고 싶은 것 | 사용할 커맨드 | 사용되는 에이전트 |
|
||||
|-------------|-------------|-----------------|
|
||||
| 새 기능 계획하기 | `/ecc:plan "인증 추가"` | planner |
|
||||
| 시스템 아키텍처 설계 | `/ecc:plan` + architect 에이전트 | architect |
|
||||
| 새 기능 계획하기 | `/everything-claude-code:plan "인증 추가"` | planner |
|
||||
| 시스템 아키텍처 설계 | `/everything-claude-code:plan` + architect 에이전트 | architect |
|
||||
| 테스트를 먼저 작성하며 코딩 | `/tdd` | tdd-guide |
|
||||
| 방금 작성한 코드 리뷰 | `/code-review` | code-reviewer |
|
||||
| 빌드 실패 수정 | `/build-fix` | build-error-resolver |
|
||||
@ -507,7 +507,7 @@ rules/
|
||||
|
||||
**새로운 기능 시작:**
|
||||
```
|
||||
/ecc:plan "OAuth를 사용한 사용자 인증 추가"
|
||||
/everything-claude-code:plan "OAuth를 사용한 사용자 인증 추가"
|
||||
→ planner가 구현 청사진 작성
|
||||
/tdd → tdd-guide가 테스트 먼저 작성 강제
|
||||
/code-review → code-reviewer가 코드 검토
|
||||
@ -535,7 +535,7 @@ rules/
|
||||
<summary><b>설치된 에이전트/커맨드 확인은 어떻게 하나요?</b></summary>
|
||||
|
||||
```bash
|
||||
/plugin list ecc@ecc
|
||||
/plugin list everything-claude-code@everything-claude-code
|
||||
```
|
||||
|
||||
플러그인에서 사용할 수 있는 모든 에이전트, 커맨드, 스킬을 보여줍니다.
|
||||
|
||||
349
docs/ko-KR/skills/project-guidelines-example/SKILL.md
Normal file
349
docs/ko-KR/skills/project-guidelines-example/SKILL.md
Normal file
@ -0,0 +1,349 @@
|
||||
---
|
||||
name: project-guidelines-example
|
||||
description: "실제 프로덕션 애플리케이션을 기반으로 한 프로젝트별 스킬 템플릿 예시."
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# 프로젝트 가이드라인 스킬 (예시)
|
||||
|
||||
이것은 프로젝트별 스킬의 예시입니다. 자신의 프로젝트에 맞는 템플릿으로 사용하세요.
|
||||
|
||||
실제 프로덕션 애플리케이션을 기반으로 합니다: [Zenith](https://zenith.chat) - AI 기반 고객 발견 플랫폼.
|
||||
|
||||
## 사용 시점
|
||||
|
||||
이 스킬이 설계된 특정 프로젝트에서 작업할 때 참조하세요. 프로젝트 스킬에는 다음이 포함됩니다:
|
||||
- 아키텍처 개요
|
||||
- 파일 구조
|
||||
- 코드 패턴
|
||||
- 테스팅 요구사항
|
||||
- 배포 워크플로우
|
||||
|
||||
---
|
||||
|
||||
## 아키텍처 개요
|
||||
|
||||
**기술 스택:**
|
||||
- **Frontend**: Next.js 15 (App Router), TypeScript, React
|
||||
- **Backend**: FastAPI (Python), Pydantic 모델
|
||||
- **Database**: Supabase (PostgreSQL)
|
||||
- **AI**: Claude API (도구 호출 및 구조화된 출력)
|
||||
- **Deployment**: Google Cloud Run
|
||||
- **Testing**: Playwright (E2E), pytest (백엔드), React Testing Library
|
||||
|
||||
**서비스:**
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Frontend │
|
||||
│ Next.js 15 + TypeScript + TailwindCSS │
|
||||
│ Deployed: Vercel / Cloud Run │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Backend │
|
||||
│ FastAPI + Python 3.11 + Pydantic │
|
||||
│ Deployed: Cloud Run │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
┌───────────────┼───────────────┐
|
||||
▼ ▼ ▼
|
||||
┌──────────┐ ┌──────────┐ ┌──────────┐
|
||||
│ Supabase │ │ Claude │ │ Redis │
|
||||
│ Database │ │ API │ │ Cache │
|
||||
└──────────┘ └──────────┘ └──────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 파일 구조
|
||||
|
||||
```
|
||||
project/
|
||||
├── frontend/
|
||||
│ └── src/
|
||||
│ ├── app/ # Next.js app router 페이지
|
||||
│ │ ├── api/ # API 라우트
|
||||
│ │ ├── (auth)/ # 인증 보호 라우트
|
||||
│ │ └── workspace/ # 메인 앱 워크스페이스
|
||||
│ ├── components/ # React 컴포넌트
|
||||
│ │ ├── ui/ # 기본 UI 컴포넌트
|
||||
│ │ ├── forms/ # 폼 컴포넌트
|
||||
│ │ └── layouts/ # 레이아웃 컴포넌트
|
||||
│ ├── hooks/ # 커스텀 React hooks
|
||||
│ ├── lib/ # 유틸리티
|
||||
│ ├── types/ # TypeScript 정의
|
||||
│ └── config/ # 설정
|
||||
│
|
||||
├── backend/
|
||||
│ ├── routers/ # FastAPI 라우트 핸들러
|
||||
│ ├── models.py # Pydantic 모델
|
||||
│ ├── main.py # FastAPI 앱 엔트리
|
||||
│ ├── auth_system.py # 인증
|
||||
│ ├── database.py # 데이터베이스 작업
|
||||
│ ├── services/ # 비즈니스 로직
|
||||
│ └── tests/ # pytest 테스트
|
||||
│
|
||||
├── deploy/ # 배포 설정
|
||||
├── docs/ # 문서
|
||||
└── scripts/ # 유틸리티 스크립트
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 코드 패턴
|
||||
|
||||
### API 응답 형식 (FastAPI)
|
||||
|
||||
```python
|
||||
from pydantic import BaseModel
|
||||
from typing import Generic, TypeVar, Optional
|
||||
|
||||
T = TypeVar('T')
|
||||
|
||||
class ApiResponse(BaseModel, Generic[T]):
|
||||
success: bool
|
||||
data: Optional[T] = None
|
||||
error: Optional[str] = None
|
||||
|
||||
@classmethod
|
||||
def ok(cls, data: T) -> "ApiResponse[T]":
|
||||
return cls(success=True, data=data)
|
||||
|
||||
@classmethod
|
||||
def fail(cls, error: str) -> "ApiResponse[T]":
|
||||
return cls(success=False, error=error)
|
||||
```
|
||||
|
||||
### Frontend API 호출 (TypeScript)
|
||||
|
||||
```typescript
|
||||
interface ApiResponse<T> {
|
||||
success: boolean
|
||||
data?: T
|
||||
error?: string
|
||||
}
|
||||
|
||||
async function fetchApi<T>(
|
||||
endpoint: string,
|
||||
options?: RequestInit
|
||||
): Promise<ApiResponse<T>> {
|
||||
try {
|
||||
const response = await fetch(`/api${endpoint}`, {
|
||||
...options,
|
||||
headers: {
|
||||
'Content-Type': 'application/json',
|
||||
...options?.headers,
|
||||
},
|
||||
})
|
||||
|
||||
if (!response.ok) {
|
||||
return { success: false, error: `HTTP ${response.status}` }
|
||||
}
|
||||
|
||||
return await response.json()
|
||||
} catch (error) {
|
||||
return { success: false, error: String(error) }
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Claude AI 통합 (구조화된 출력)
|
||||
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
from pydantic import BaseModel
|
||||
|
||||
class AnalysisResult(BaseModel):
|
||||
summary: str
|
||||
key_points: list[str]
|
||||
confidence: float
|
||||
|
||||
async def analyze_with_claude(content: str) -> AnalysisResult:
|
||||
client = Anthropic()
|
||||
|
||||
response = client.messages.create(
|
||||
model="claude-sonnet-4-5-20250514",
|
||||
max_tokens=1024,
|
||||
messages=[{"role": "user", "content": content}],
|
||||
tools=[{
|
||||
"name": "provide_analysis",
|
||||
"description": "Provide structured analysis",
|
||||
"input_schema": AnalysisResult.model_json_schema()
|
||||
}],
|
||||
tool_choice={"type": "tool", "name": "provide_analysis"}
|
||||
)
|
||||
|
||||
# Extract tool use result
|
||||
tool_use = next(
|
||||
block for block in response.content
|
||||
if block.type == "tool_use"
|
||||
)
|
||||
|
||||
return AnalysisResult(**tool_use.input)
|
||||
```
|
||||
|
||||
### 커스텀 Hooks (React)
|
||||
|
||||
```typescript
|
||||
import { useState, useCallback } from 'react'
|
||||
|
||||
interface UseApiState<T> {
|
||||
data: T | null
|
||||
loading: boolean
|
||||
error: string | null
|
||||
}
|
||||
|
||||
export function useApi<T>(
|
||||
fetchFn: () => Promise<ApiResponse<T>>
|
||||
) {
|
||||
const [state, setState] = useState<UseApiState<T>>({
|
||||
data: null,
|
||||
loading: false,
|
||||
error: null,
|
||||
})
|
||||
|
||||
const execute = useCallback(async () => {
|
||||
setState(prev => ({ ...prev, loading: true, error: null }))
|
||||
|
||||
const result = await fetchFn()
|
||||
|
||||
if (result.success) {
|
||||
setState({ data: result.data!, loading: false, error: null })
|
||||
} else {
|
||||
setState({ data: null, loading: false, error: result.error! })
|
||||
}
|
||||
}, [fetchFn])
|
||||
|
||||
return { ...state, execute }
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 테스팅 요구사항
|
||||
|
||||
### Backend (pytest)
|
||||
|
||||
```bash
|
||||
# Run all tests
|
||||
poetry run pytest tests/
|
||||
|
||||
# Run with coverage
|
||||
poetry run pytest tests/ --cov=. --cov-report=html
|
||||
|
||||
# Run specific test file
|
||||
poetry run pytest tests/test_auth.py -v
|
||||
```
|
||||
|
||||
**테스트 구조:**
|
||||
```python
|
||||
import pytest
|
||||
from httpx import AsyncClient
|
||||
from main import app
|
||||
|
||||
@pytest.fixture
|
||||
async def client():
|
||||
async with AsyncClient(app=app, base_url="http://test") as ac:
|
||||
yield ac
|
||||
|
||||
@pytest.mark.asyncio
|
||||
async def test_health_check(client: AsyncClient):
|
||||
response = await client.get("/health")
|
||||
assert response.status_code == 200
|
||||
assert response.json()["status"] == "healthy"
|
||||
```
|
||||
|
||||
### Frontend (React Testing Library)
|
||||
|
||||
```bash
|
||||
# Run tests
|
||||
npm run test
|
||||
|
||||
# Run with coverage
|
||||
npm run test -- --coverage
|
||||
|
||||
# Run E2E tests
|
||||
npm run test:e2e
|
||||
```
|
||||
|
||||
**테스트 구조:**
|
||||
```typescript
|
||||
import { render, screen, fireEvent } from '@testing-library/react'
|
||||
import { WorkspacePanel } from './WorkspacePanel'
|
||||
|
||||
describe('WorkspacePanel', () => {
|
||||
it('renders workspace correctly', () => {
|
||||
render(<WorkspacePanel />)
|
||||
expect(screen.getByRole('main')).toBeInTheDocument()
|
||||
})
|
||||
|
||||
it('handles session creation', async () => {
|
||||
render(<WorkspacePanel />)
|
||||
fireEvent.click(screen.getByText('New Session'))
|
||||
expect(await screen.findByText('Session created')).toBeInTheDocument()
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 배포 워크플로우
|
||||
|
||||
### 배포 전 체크리스트
|
||||
|
||||
- [ ] 모든 테스트가 로컬에서 통과
|
||||
- [ ] `npm run build` 성공 (frontend)
|
||||
- [ ] `poetry run pytest` 통과 (backend)
|
||||
- [ ] 하드코딩된 시크릿 없음
|
||||
- [ ] 환경 변수 문서화됨
|
||||
- [ ] 데이터베이스 마이그레이션 준비됨
|
||||
|
||||
### 배포 명령어
|
||||
|
||||
```bash
|
||||
# Build and deploy frontend
|
||||
cd frontend && npm run build
|
||||
gcloud run deploy frontend --source .
|
||||
|
||||
# Build and deploy backend
|
||||
cd backend
|
||||
gcloud run deploy backend --source .
|
||||
```
|
||||
|
||||
### 환경 변수
|
||||
|
||||
```bash
|
||||
# Frontend (.env.local)
|
||||
NEXT_PUBLIC_API_URL=https://api.example.com
|
||||
NEXT_PUBLIC_SUPABASE_URL=https://xxx.supabase.co
|
||||
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...
|
||||
|
||||
# Backend (.env)
|
||||
DATABASE_URL=postgresql://...
|
||||
ANTHROPIC_API_KEY=sk-ant-...
|
||||
SUPABASE_URL=https://xxx.supabase.co
|
||||
SUPABASE_KEY=eyJ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 핵심 규칙
|
||||
|
||||
1. **코드, 주석, 문서에 이모지 없음**
|
||||
2. **불변성** - 객체나 배열을 절대 변형하지 않음
|
||||
3. **TDD** - 구현 전에 테스트 작성
|
||||
4. **80% 커버리지** 최소
|
||||
5. **작은 파일 여러 개** - 200-400줄이 일반적, 800줄 최대
|
||||
6. **프로덕션 코드에 console.log 없음**
|
||||
7. **적절한 에러 처리** (try/catch 사용)
|
||||
8. **입력 유효성 검사** (Pydantic/Zod 사용)
|
||||
|
||||
---
|
||||
|
||||
## 관련 스킬
|
||||
|
||||
- `coding-standards.md` - 일반 코딩 모범 사례
|
||||
- `backend-patterns.md` - API 및 데이터베이스 패턴
|
||||
- `frontend-patterns.md` - React 및 Next.js 패턴
|
||||
- `tdd-workflow/` - 테스트 주도 개발 방법론
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user