Everything Claude Code Conventions
Match affaan-m/everything-claude-code repo patterns—JavaScript layout, tests, and conventional commits—when the agent edits that project.
Overview
Everything Claude Code Conventions is an agent skill for the Build phase that teaches JavaScript, test placement, and Conventional Commits patterns specific to the everything-claude-code repository.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill everything-claude-code-conventionsWhat is this skill?
- Conventional Commits style derived from 500 analyzed commits with prefixes fix, test, feat, and docs
- JavaScript hybrid module organization with tests in a separate location
- Activate when adding features, writing tests, or formatting commits in everything-claude-code
- Imperative mood subject lines (~65 character guidance) with scoped examples like feat(rules) and fix(auto-detect)
- Bridges agent edits to project-specific ECC root and plugin cache behaviors referenced in commit history
- 4 commit prefixes: fix, test, feat, docs
Adoption & trust: 4.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps proposing commits and file layouts that do not match the everything-claude-code repo’s tested conventions.
Who is it for?
Contributors or fork maintainers actively patching affaan-m/everything-claude-code with Claude Code, Cursor, or Codex.
Skip if: Unrelated greenfield JavaScript apps or repos that use a different commit standard and test layout.
When should I use this skill?
Making changes to everything-claude-code; adding features; writing matching tests; creating properly formatted commits.
What do I get? / Deliverables
Edits and commits align with ECC hybrid modules, separate test locations, and conventional commit prefixes maintainers already use.
- Commits following ECC Conventional Commits examples
- Features and tests placed per hybrid module and separate test layout
Recommended Skills
Journey fit
Canonical shelf is Build/docs because the skill teaches repository conventions and commit/test patterns rather than shipping or marketing work. Docs is the right facet for generated convention guides agents consult before changing ECC structure or messaging.
How it compares
Repo-local convention skill—not a generic linter rules pack or MCP documentation server.
Common Questions / FAQ
Who is everything-claude-code-conventions for?
Anyone using AI agents to change the everything-claude-code repository who needs matching commit and project structure rules.
When should I use everything-claude-code-conventions?
During Build when adding ECC features, writing tests in the separate test tree, or crafting conventional commits before opening a PR.
Is everything-claude-code-conventions safe to install?
It is documentation-only guidance for one repo; review the Security Audits panel on this Prism page and still follow normal code review before merging.
SKILL.md
READMESKILL.md - Everything Claude Code Conventions
# Everything Claude Code Conventions > Generated from [affaan-m/everything-claude-code](https://github.com/affaan-m/everything-claude-code) on 2026-03-20 ## Overview This skill teaches Claude the development patterns and conventions used in everything-claude-code. ## Tech Stack - **Primary Language**: JavaScript - **Architecture**: hybrid module organization - **Test Location**: separate ## When to Use This Skill 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 ## Commit Conventions Follow these commit message conventions based on 500 analyzed commits. ### Commit Style: Conventional Commits ### Prefixes Used - `fix` - `test` - `feat` - `docs` ### 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 ``` *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