agentleFS
NCMFNNCMFN/ClaudeCode/.agents/skills/everything-claude-code/SKILL.md

everything-claude-code

Skill0 starsChanged 8 months agoMITView on GitHub

js const registry = require('../lib/install-targets/registry'); feat: add Gemini install target support js // scripts/lib/install-targets/gemini-project.js module.exports = function installGemini() { // Installation logic for Gemini }; markdown # skills/mySkill/SKILL.md

12 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use brand-discovery, competitive-platform-analysis and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • ysyecustSkill

    brand-discovery

    Use when a brand needs to discover or articulate its identity through structured multi-session interviews. Covers purpose, positioning, audience, personality, voice, narrative, and founder-brand tension across 8 modules using laddering, 5 Whys, and projective techniques. Produces a resumable session with disk-persisted state and a master brandbook (90_SYNTHESIS.md).

    Also in 3 projects that use this

  • ysyecustSkill

    competitive-platform-analysis

    Use when scoping a competitive landscape — identifying, categorising, and score-filtering a competitor set before any benchmarking begins. Decides who counts as a competitor, which tier they belong to, and which sources to mine. First step in the three-skill competitive pipeline; precedes benchmark-methodology.

    Also in 3 projects that use this

  • niloykumarbarmanSkill

    agent-sort

    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.

    Also in 4 projects that use this

  • +2 more from ysyecust

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 0 are common, 7 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Create or update the canonical skill under skills/{skill-name}/SKILL.md Only if needed, add or update commands/{command-name}.md as a …

    line 109
  2. Distinctive:

    Only if needed, add or update commands/{command-name}.md as a compatibility shim

    line 110
  3. Distinctive:

    Trigger: When bulk importing conventions, agent definitions, or skill documentation

    line 128
  4. Very specific:

    Add multiple files in .claude/commands/, .claude/enterprise/, .claude/team/, .claude/research/, .claude/rules/, .codex/agents/, …

    line 131
  5. Distinctive:

    No code/test changes—just documentation and config import.

    line 133
  6. Distinctive:

    Trigger: When Dependabot creates a PR for a new dependency version

    line 138
  7. Very specific:

    Update versions in package.json, package-lock.json, or yarn.lock.

    line 141
  8. Very specific:

    Update .github/workflows/*.yml for GitHub Actions if needed.

    line 142
  9. Distinctive:

    Commit with a standard Dependabot message.

    line 143
  10. Very specific:

    Update .github/dependabot.yml for configuration if necessary.

    line 144
  11. Distinctive:

    Trigger: When a skill/agent needs to be removed, merged, or reworked

    line 149
  12. Very specific:

    Remove or modify SKILL.md in skills/{skill-name}/ or agents/{agent-name}.md.

    line 152
  13. Very specific:

    Update manifests/install-modules.json and documentation.

    line 153
  14. Distinctive:

    Document the reason for the change (e.g., security, redundancy).

    line 155
  15. Very specific:

    All test files use the *.test.js pattern.

    line 162
  16. Very specific:

    No specific testing framework detected.

    line 164

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
# everything-claude-code Development Patterns

> Auto-generated skill from repository analysis

## Overview

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.

## Coding Conventions

- **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`).

- **Import Style:**  
  Use relative imports for modules:
  ```js
  const registry = require('../lib/install-targets/registry');
  • Export Style:
    Both CommonJS (module.exports = ...) and ES module (export default ...) styles may be used, depending on file context.
  • Commit Messages:
    Follow Conventional Commits with prefixes such as fix, feat, docs, chore.
    Example:
    feat: add Gemini install target support
  • Test Files:
    Test files follow the *.test.js pattern and are colocated with the code under test or in a tests/ directory.

Workflows

Add New Install Target

Trigger: When supporting a new IDE, platform, or environment for ECC installation
Command: /add-install-target

  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.

Example:

// scripts/lib/install-targets/gemini-project.js
module.exports = function installGemini() {
  // Installation logic for Gemini
};

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:

# skills/mySkill/SKILL.md

## Overview
Describes the "mySkill" capability for ECC.

## Usage
...

Add New Workflow Surface

Adds or updates a workflow entrypoint. Default to skills-first; only add a command shim when legacy slash compatibility is still required.

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.

Steps:

  1. Create or update the canonical workflow under skills/{skill-name}/SKILL.md
  2. Only if needed, add or update commands/{command-name}.md as a compatibility shim

Files typically involved:

  • skills/*/SKILL.md
  • commands/*.md (only when a legacy shim is intentionally retained)

Example commit sequence:

Create or update the canonical skill under skills/{skill-name}/SKILL.md
Only if needed, add or update commands/{command-name}.md as a compatibility shim
**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:

// tests/lib/install-targets.test.js
const installGemini = require('../../scripts/lib/install-targets/gemini-project');

test('Gemini install target works', () => {
  expect(installGemini()).toBeDefined();
});

Commands

CommandPurpose
/add-install-targetAdd support for a new install target (IDE/platform)
/add-skillAdd a new skill or agent to the ECC system
/add-commandAdd or update a CLI command or workflow
/import-bundleBulk import agent/skill bundles or conventions documentation
/update-dependenciesUpdate dependencies via Dependabot
/remove-skillRefactor, remove, or revert a skill or agent

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.