feat: add everything-claude-code ECC bundle (.agents/skills/everything-claude-code/SKILL.md)

This commit is contained in:
ecc-tools[bot]
2026-04-01 00:56:58 +00:00
committed by GitHub
parent ae04e63200
commit b133a0d4dd

View File

@@ -1,442 +1,173 @@
---
name: everything-claude-code-conventions
description: Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.
---
```markdown
# everything-claude-code Development Patterns
# Everything Claude Code Conventions
> Generated from [affaan-m/everything-claude-code](https://github.com/affaan-m/everything-claude-code) on 2026-03-20
> Auto-generated skill from repository analysis
## Overview
This skill teaches Claude the development patterns and conventions used in everything-claude-code.
This skill documents the core development patterns, coding conventions, and workflows used in the `everything-claude-code` JavaScript repository. It is designed to help contributors understand how to add new skills, agents, commands, install targets, and maintain the codebase according to established conventions. The repository is framework-agnostic, uses conventional commits, and supports modular extension via skills, agents, and command workflows.
## Tech Stack
## Coding Conventions
- **Primary Language**: JavaScript
- **Architecture**: hybrid module organization
- **Test Location**: separate
- **File Naming:**
Use `camelCase` for JavaScript files (e.g., `installManifests.js`), and descriptive names for markdown/config files (e.g., `SKILL.md`, `install-modules.json`).
## When to Use This Skill
- **Import Style:**
Use relative imports for modules:
```js
const registry = require('../lib/install-targets/registry');
```
Activate this skill when:
- Making changes to this repository
- Adding new features following established patterns
- Writing tests that match project conventions
- Creating commits with proper message format
- **Export Style:**
Both CommonJS (`module.exports = ...`) and ES module (`export default ...`) styles may be used, depending on file context.
## Commit Conventions
- **Commit Messages:**
Follow [Conventional Commits](https://www.conventionalcommits.org/) with prefixes such as `fix`, `feat`, `docs`, `chore`.
Example:
```
feat: add Gemini install target support
```
Follow these commit message conventions based on 500 analyzed commits.
- **Test Files:**
Test files follow the `*.test.js` pattern and are colocated with the code under test or in a `tests/` directory.
### Commit Style: Conventional Commits
## Workflows
### Prefixes Used
### Add New Install Target
**Trigger:** When supporting a new IDE, platform, or environment for ECC installation
**Command:** `/add-install-target`
- `fix`
- `test`
- `feat`
- `docs`
1. Create a new install target script, e.g., `scripts/lib/install-targets/{target}-project.js`, `.{target}/install.sh`, or `.{target}/install.js`.
2. Add documentation for the new target, such as `.{target}/README.md`, `.{target}/README.zh-CN.md`, or `.{target}/GEMINI.md`.
3. Update `manifests/install-modules.json` to register the new target.
4. Update schemas:
- `schemas/ecc-install-config.schema.json`
- `schemas/install-modules.schema.json`
5. Update logic in:
- `scripts/lib/install-manifests.js`
- `scripts/lib/install-targets/registry.js`
6. Add or update tests in `tests/lib/install-targets.test.js`.
7. Update `README.md` if public-facing install instructions change.
### Message Guidelines
- Average message length: ~65 characters
- Keep first line concise and descriptive
- Use imperative mood ("Add feature" not "Added feature")
*Commit message example*
```text
feat(rules): add C# language support
**Example:**
```js
// scripts/lib/install-targets/gemini-project.js
module.exports = function installGemini() {
// Installation logic for Gemini
};
```
*Commit message example*
```text
chore(deps-dev): bump flatted (#675)
```
*Commit message example*
```text
fix: auto-detect ECC root from plugin cache when CLAUDE_PLUGIN_ROOT is unset (#547) (#691)
```
*Commit message example*
```text
docs: add Antigravity setup and usage guide (#552)
```
*Commit message example*
```text
merge: PR #529 — feat(skills): add documentation-lookup, bun-runtime, nextjs-turbopack; feat(agents): add rust-reviewer
```
*Commit message example*
```text
Revert "Add Kiro IDE support (.kiro/) (#548)"
```
*Commit message example*
```text
Add Kiro IDE support (.kiro/) (#548)
```
*Commit message example*
```text
feat: add block-no-verify hook for Claude Code and Cursor (#649)
```
## Architecture
### Project Structure: Single Package
This project uses **hybrid** module organization.
### Configuration Files
- `.github/workflows/ci.yml`
- `.github/workflows/maintenance.yml`
- `.github/workflows/monthly-metrics.yml`
- `.github/workflows/release.yml`
- `.github/workflows/reusable-release.yml`
- `.github/workflows/reusable-test.yml`
- `.github/workflows/reusable-validate.yml`
- `.opencode/package.json`
- `.opencode/tsconfig.json`
- `.prettierrc`
- `eslint.config.js`
- `package.json`
### Guidelines
- This project uses a hybrid organization
- Follow existing patterns when adding new code
## Code Style
### Language: JavaScript
### Naming Conventions
| Element | Convention |
|---------|------------|
| Files | camelCase |
| Functions | camelCase |
| Classes | PascalCase |
| Constants | SCREAMING_SNAKE_CASE |
### Import Style: Relative Imports
### Export Style: Mixed Style
*Preferred import style*
```typescript
// Use relative imports
import { Button } from '../components/Button'
import { useAuth } from './hooks/useAuth'
```
## Testing
### Test Framework
No specific test framework detected — use the repository's existing test patterns.
### File Pattern: `*.test.js`
### Test Types
- **Unit tests**: Test individual functions and components in isolation
- **Integration tests**: Test interactions between multiple components/services
### Coverage
This project has coverage reporting configured. Aim for 80%+ coverage.
## Error Handling
### Error Handling Style: Try-Catch Blocks
*Standard error handling pattern*
```typescript
try {
const result = await riskyOperation()
return result
} catch (error) {
console.error('Operation failed:', error)
throw new Error('User-friendly message')
}
```
## Common Workflows
These workflows were detected from analyzing commit patterns.
### Database Migration
Database schema changes with migration files
**Frequency**: ~2 times per month
**Steps**:
1. Create migration file
2. Update schema definitions
3. Generate/update types
**Files typically involved**:
- `**/schema.*`
- `migrations/*`
**Example commit sequence**:
```
feat: implement --with/--without selective install flags (#679)
fix: sync catalog counts with filesystem (27 agents, 113 skills, 58 commands) (#693)
feat(rules): add Rust language rules (rebased #660) (#686)
```
### Feature Development
Standard feature implementation workflow
**Frequency**: ~22 times per month
**Steps**:
1. Add feature implementation
2. Add tests for feature
3. Update documentation
**Files typically involved**:
- `manifests/*`
- `schemas/*`
- `**/*.test.*`
- `**/api/**`
**Example commit sequence**:
```
feat(skills): add documentation-lookup, bun-runtime, nextjs-turbopack; feat(agents): add rust-reviewer
docs(skills): align documentation-lookup with CONTRIBUTING template; add cross-harness (Codex/Cursor) skill copies
fix: address PR review — skill template (When to use, How it works, Examples), bun.lock, next build note, rust-reviewer CI note, doc-lookup privacy/uncertainty
```
### Add Language Rules
Adds a new programming language to the rules system, including coding style, hooks, patterns, security, and testing guidelines.
**Frequency**: ~2 times per month
**Steps**:
1. Create a new directory under rules/{language}/
2. Add coding-style.md, hooks.md, patterns.md, security.md, and testing.md files with language-specific content
3. Optionally reference or link to related skills
**Files typically involved**:
- `rules/*/coding-style.md`
- `rules/*/hooks.md`
- `rules/*/patterns.md`
- `rules/*/security.md`
- `rules/*/testing.md`
**Example commit sequence**:
```
Create a new directory under rules/{language}/
Add coding-style.md, hooks.md, patterns.md, security.md, and testing.md files with language-specific content
Optionally reference or link to related skills
```
### Add New Skill
Adds a new skill to the system, documenting its workflow, triggers, and usage, often with supporting scripts.
**Frequency**: ~4 times per month
**Steps**:
1. Create a new directory under skills/{skill-name}/
2. Add SKILL.md with documentation (When to Use, How It Works, Examples, etc.)
3. Optionally add scripts or supporting files under skills/{skill-name}/scripts/
4. Address review feedback and iterate on documentation
**Files typically involved**:
- `skills/*/SKILL.md`
- `skills/*/scripts/*.sh`
- `skills/*/scripts/*.js`
**Example commit sequence**:
```
Create a new directory under skills/{skill-name}/
Add SKILL.md with documentation (When to Use, How It Works, Examples, etc.)
Optionally add scripts or supporting files under skills/{skill-name}/scripts/
Address review feedback and iterate on documentation
```
### Add New Agent
Adds a new agent to the system for code review, build resolution, or other automated tasks.
**Frequency**: ~2 times per month
**Steps**:
1. Create a new agent markdown file under agents/{agent-name}.md
2. Register the agent in AGENTS.md
3. Optionally update README.md and docs/COMMAND-AGENT-MAP.md
**Files typically involved**:
- `agents/*.md`
- `AGENTS.md`
- `README.md`
- `docs/COMMAND-AGENT-MAP.md`
**Example commit sequence**:
```
Create a new agent markdown file under agents/{agent-name}.md
Register the agent in AGENTS.md
Optionally update README.md and docs/COMMAND-AGENT-MAP.md
```
### Add New Command
Adds a new command to the system, often paired with a backing skill.
**Frequency**: ~1 times per month
**Steps**:
1. Create a new markdown file under commands/{command-name}.md
2. Optionally add or update a backing skill under skills/{skill-name}/SKILL.md
**Files typically involved**:
- `commands/*.md`
- `skills/*/SKILL.md`
**Example commit sequence**:
```
Create a new markdown file under commands/{command-name}.md
Optionally add or update a backing skill under skills/{skill-name}/SKILL.md
```
### Sync Catalog Counts
Synchronizes the documented counts of agents, skills, and commands in AGENTS.md and README.md with the actual repository state.
**Frequency**: ~3 times per month
**Steps**:
1. Update agent, skill, and command counts in AGENTS.md
2. Update the same counts in README.md (quick-start, comparison table, etc.)
3. Optionally update other documentation files
**Files typically involved**:
- `AGENTS.md`
- `README.md`
**Example commit sequence**:
```
Update agent, skill, and command counts in AGENTS.md
Update the same counts in README.md (quick-start, comparison table, etc.)
Optionally update other documentation files
```
### Add Cross Harness Skill Copies
Adds skill copies for different agent harnesses (e.g., Codex, Cursor, Antigravity) to ensure compatibility across platforms.
**Frequency**: ~2 times per month
**Steps**:
1. Copy or adapt SKILL.md to .agents/skills/{skill}/SKILL.md and/or .cursor/skills/{skill}/SKILL.md
2. Optionally add harness-specific openai.yaml or config files
3. Address review feedback to align with CONTRIBUTING template
**Files typically involved**:
- `.agents/skills/*/SKILL.md`
- `.cursor/skills/*/SKILL.md`
- `.agents/skills/*/agents/openai.yaml`
**Example commit sequence**:
```
Copy or adapt SKILL.md to .agents/skills/{skill}/SKILL.md and/or .cursor/skills/{skill}/SKILL.md
Optionally add harness-specific openai.yaml or config files
Address review feedback to align with CONTRIBUTING template
```
### Add Or Update Hook
Adds or updates git or bash hooks to enforce workflow, quality, or security policies.
**Frequency**: ~1 times per month
**Steps**:
1. Add or update hook scripts in hooks/ or scripts/hooks/
2. Register the hook in hooks/hooks.json or similar config
3. Optionally add or update tests in tests/hooks/
**Files typically involved**:
- `hooks/*.hook`
- `hooks/hooks.json`
- `scripts/hooks/*.js`
- `tests/hooks/*.test.js`
- `.cursor/hooks.json`
**Example commit sequence**:
```
Add or update hook scripts in hooks/ or scripts/hooks/
Register the hook in hooks/hooks.json or similar config
Optionally add or update tests in tests/hooks/
```
### Address Review Feedback
Addresses code review feedback by updating documentation, scripts, or configuration for clarity, correctness, or convention alignment.
**Frequency**: ~4 times per month
**Steps**:
1. Edit SKILL.md, agent, or command files to address reviewer comments
2. Update examples, headings, or configuration as requested
3. Iterate until all review feedback is resolved
**Files typically involved**:
- `skills/*/SKILL.md`
- `agents/*.md`
- `commands/*.md`
- `.agents/skills/*/SKILL.md`
- `.cursor/skills/*/SKILL.md`
**Example commit sequence**:
```
Edit SKILL.md, agent, or command files to address reviewer comments
Update examples, headings, or configuration as requested
Iterate until all review feedback is resolved
```
## Best Practices
Based on analysis of the codebase, follow these practices:
### Do
- Use conventional commit format (feat:, fix:, etc.)
- Follow *.test.js naming pattern
- Use camelCase for file names
- Prefer mixed exports
### Don't
- Don't write vague commit messages
- Don't skip tests for new features
- Don't deviate from established patterns without discussion
---
*This skill was auto-generated by [ECC Tools](https://ecc.tools). Review and customize as needed for your team.*
### Add New Skill or Agent
**Trigger:** When introducing a new capability, workflow, or agent persona
**Command:** `/add-skill`
1. Create a new `SKILL.md` in `skills/{skill-name}/` or `.agents/skills/{skill-name}/`.
2. For agents, add definitions in `agents/{agent-name}.md` or `.codex/agents/{agent-name}.toml`.
3. Update `manifests/install-modules.json` if the skill is installable.
4. Update `AGENTS.md` and/or `README.md` to document the new skill/agent.
5. Add supporting files as needed (e.g., `rules/`, `prompts/`, orchestration scripts).
6. If orchestration is needed, add a shell or JS orchestrator (e.g., `scripts/{skill-name}.sh`).
**Example:**
```markdown
# skills/mySkill/SKILL.md
## Overview
Describes the "mySkill" capability for ECC.
## Usage
...
```
---
### Add or Update Command Workflow
**Trigger:** When adding or improving CLI commands or workflows
**Command:** `/add-command`
1. Create or modify a command markdown file in `commands/{command-name}.md` or `.claude/commands/{command-name}.md`.
2. Add YAML frontmatter and sections for Purpose, Usage, and Output.
3. Iterate based on review feedback (fix placeholders, add error handling, clarify protocol).
4. Update related commands or documentation if part of a workflow.
5. Document artifact storage locations if applicable.
**Example:**
```markdown
---
name: install
description: Install a new ECC module
---
## Purpose
...
## Usage
...
```
---
### Agent or Skill Bundle Import
**Trigger:** When bulk importing conventions, agent definitions, or skill documentation
**Command:** `/import-bundle`
1. Add multiple files in `.claude/commands/`, `.claude/enterprise/`, `.claude/team/`, `.claude/research/`, `.claude/rules/`, `.codex/agents/`, `.claude/skills/`, `.agents/skills/`, etc.
2. Include team config, identity, guardrails, research playbook, and skills documentation.
3. No code/test changes—just documentation and config import.
---
### Dependency Update via Dependabot
**Trigger:** When Dependabot creates a PR for a new dependency version
**Command:** `/update-dependencies`
1. Update versions in `package.json`, `package-lock.json`, or `yarn.lock`.
2. Update `.github/workflows/*.yml` for GitHub Actions if needed.
3. Commit with a standard Dependabot message.
4. Update `.github/dependabot.yml` for configuration if necessary.
---
### Refactor or Fix Skill or Agent
**Trigger:** When a skill/agent needs to be removed, merged, or reworked
**Command:** `/remove-skill`
1. Remove or modify `SKILL.md` in `skills/{skill-name}/` or `agents/{agent-name}.md`.
2. Update `manifests/install-modules.json` and documentation.
3. Restore or remove associated files as needed.
4. Document the reason for the change (e.g., security, redundancy).
---
## Testing Patterns
- **Test Files:**
All test files use the `*.test.js` pattern.
- **Framework:**
No specific testing framework detected; use standard Node.js assertions or your preferred test runner.
- **Location:**
Tests are typically placed in a `tests/` directory or alongside the source files.
**Example:**
```js
// tests/lib/install-targets.test.js
const installGemini = require('../../scripts/lib/install-targets/gemini-project');
test('Gemini install target works', () => {
expect(installGemini()).toBeDefined();
});
```
## Commands
| Command | Purpose |
|---------------------|--------------------------------------------------------------|
| /add-install-target | Add support for a new install target (IDE/platform) |
| /add-skill | Add a new skill or agent to the ECC system |
| /add-command | Add or update a CLI command or workflow |
| /import-bundle | Bulk import agent/skill bundles or conventions documentation |
| /update-dependencies| Update dependencies via Dependabot |
| /remove-skill | Refactor, remove, or revert a skill or agent |
```