mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-03 07:33:31 +08:00
Compare commits
1 Commits
ecc-tools/
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
635fcbd715 |
@@ -23,50 +23,23 @@ Write long-form content that sounds like an actual person with a point of view,
|
||||
4. Use proof instead of adjectives.
|
||||
5. Never invent facts, credibility, or customer evidence.
|
||||
|
||||
## Voice Capture Workflow
|
||||
## Voice Handling
|
||||
|
||||
If the user wants a specific voice, collect one or more of:
|
||||
- published articles
|
||||
- newsletters
|
||||
- X posts or threads
|
||||
- docs or memos
|
||||
- launch notes
|
||||
- a style guide
|
||||
|
||||
Then extract:
|
||||
- sentence length and rhythm
|
||||
- whether the writing is compressed, explanatory, sharp, or formal
|
||||
- how parentheses are used
|
||||
- how often the writer asks questions
|
||||
- whether the writer uses fragments, lists, or hard pivots
|
||||
- formatting habits such as headers, bullets, code blocks, pull quotes
|
||||
- what the writer clearly avoids
|
||||
If the user wants a specific voice, run `brand-voice` first and reuse its `VOICE PROFILE`.
|
||||
Do not duplicate a second style-analysis pass here unless the user explicitly asks for one.
|
||||
|
||||
If no voice references are given, default to a sharp operator voice: concrete, unsentimental, useful.
|
||||
|
||||
## Affaan / ECC Voice Reference
|
||||
|
||||
When matching Affaan / ECC voice, bias toward:
|
||||
- direct claims over scene-setting
|
||||
- high specificity
|
||||
- parentheticals used for qualification or over-clarification, not comedy
|
||||
- capitalization chosen situationally, not as a gimmick
|
||||
- very low tolerance for fake thought-leadership cadence
|
||||
- almost no bait questions
|
||||
|
||||
## Banned Patterns
|
||||
|
||||
Delete and rewrite any of these:
|
||||
- "In today's rapidly evolving landscape"
|
||||
- "game-changer", "cutting-edge", "revolutionary"
|
||||
- "no fluff"
|
||||
- "not X, just Y"
|
||||
- "here's why this matters" as a standalone bridge
|
||||
- fake vulnerability arcs
|
||||
- a closing question added only to juice engagement
|
||||
- forced lowercase
|
||||
- corny parenthetical asides
|
||||
- biography padding that does not move the argument
|
||||
- generic AI throat-clearing that delays the point
|
||||
|
||||
## Writing Process
|
||||
|
||||
@@ -101,6 +74,6 @@ Delete and rewrite any of these:
|
||||
Before delivering:
|
||||
- factual claims are backed by provided sources
|
||||
- generic AI transitions are gone
|
||||
- the voice matches the supplied examples
|
||||
- the voice matches the supplied examples or the agreed `VOICE PROFILE`
|
||||
- every section adds something new
|
||||
- formatting matches the intended medium
|
||||
|
||||
@@ -38,50 +38,28 @@ Before drafting, identify the source set:
|
||||
If the user wants a specific voice, build a voice profile from real examples before writing.
|
||||
Use `brand-voice` as the canonical workflow when voice consistency matters across more than one output.
|
||||
|
||||
## Voice Capture Workflow
|
||||
## Voice Handling
|
||||
|
||||
Run `brand-voice` first when:
|
||||
`brand-voice` is the canonical voice layer.
|
||||
|
||||
Run it first when:
|
||||
|
||||
- there are multiple downstream outputs
|
||||
- the user explicitly cares about writing style
|
||||
- the content is launch, outreach, or reputation-sensitive
|
||||
|
||||
At minimum, produce a compact `VOICE PROFILE` covering:
|
||||
- rhythm
|
||||
- compression
|
||||
- capitalization
|
||||
- parenthetical use
|
||||
- question use
|
||||
- preferred moves
|
||||
- banned moves
|
||||
|
||||
Do not start drafting until the voice profile is clear enough to enforce.
|
||||
|
||||
## Affaan / ECC Voice Reference
|
||||
|
||||
When the user wants Affaan / ECC voice specifically, default to this unless newer examples clearly override it:
|
||||
- direct, compressed, concrete
|
||||
- strong preference for specific claims, numbers, mechanisms, and receipts
|
||||
- parentheticals used to qualify, narrow, or over-clarify, not to do corny bits
|
||||
- lowercase is optional, not mandatory
|
||||
- questions are rare and should not be added as bait
|
||||
- transitions should feel earned, not polished
|
||||
- tone can be sharp or blunt, but should not sound like a content marketer
|
||||
Reuse the resulting `VOICE PROFILE` here instead of rebuilding a second voice model.
|
||||
If the user wants Affaan / ECC voice specifically, still treat `brand-voice` as the source of truth and feed it the best live or source-derived material available.
|
||||
|
||||
## Hard Bans
|
||||
|
||||
Delete and rewrite any of these:
|
||||
- "In today's rapidly evolving landscape"
|
||||
- "game-changer", "revolutionary", "cutting-edge"
|
||||
- "no fluff"
|
||||
- "not X, just Y"
|
||||
- "here's why this matters" unless it is followed immediately by something concrete
|
||||
- "Excited to share"
|
||||
- fake curiosity gaps
|
||||
- ending with a LinkedIn-style question just to farm replies
|
||||
- forced lowercase when the source voice does not call for it
|
||||
- forced casualness on LinkedIn
|
||||
- parenthetical jokes that were not present in the source voice
|
||||
- fake engagement padding that was not present in the source material
|
||||
|
||||
## Platform Adaptation Rules
|
||||
|
||||
|
||||
@@ -39,13 +39,8 @@ Use `content-engine` first if the source still needs voice shaping.
|
||||
|
||||
Run `brand-voice` first if the source voice is not already captured in the current session.
|
||||
|
||||
Before adapting, note:
|
||||
- how blunt or explanatory the source is
|
||||
- whether the source uses fragments, lists, or longer transitions
|
||||
- whether the source uses parentheses
|
||||
- whether the source avoids questions, hashtags, or CTA language
|
||||
|
||||
The adaptation should preserve that fingerprint.
|
||||
Reuse the resulting `VOICE PROFILE` directly.
|
||||
Do not build a second ad hoc voice checklist here unless the user explicitly wants a fresh override for this campaign.
|
||||
|
||||
### Step 3: Adapt by Platform Constraint
|
||||
|
||||
@@ -91,7 +86,6 @@ Delete and rewrite any of these:
|
||||
- "Here's what I learned"
|
||||
- "What do you think?"
|
||||
- "link in bio" unless that is literally true
|
||||
- "not X, just Y"
|
||||
- generic "professional takeaway" paragraphs that were not in the source
|
||||
|
||||
## Output Format
|
||||
|
||||
@@ -1,150 +1,442 @@
|
||||
```markdown
|
||||
# everything-claude-code Development Patterns
|
||||
---
|
||||
name: everything-claude-code-conventions
|
||||
description: Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.
|
||||
---
|
||||
|
||||
> Auto-generated skill from repository analysis
|
||||
# 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 provides a comprehensive guide to the development patterns, workflows, and coding conventions used in the `everything-claude-code` repository. It covers how to add or update skills, commands, install targets, hooks, and documentation, as well as the repository's JavaScript coding style and testing patterns. This guide is intended for contributors looking to maintain consistency and efficiency when working within this codebase.
|
||||
This skill teaches Claude the development patterns and conventions used in everything-claude-code.
|
||||
|
||||
## Coding Conventions
|
||||
## Tech Stack
|
||||
|
||||
- **Language:** JavaScript (no framework detected)
|
||||
- **File Naming:** Use `camelCase` for JavaScript files and folders.
|
||||
- Example: `mySkill.js`, `installTarget.js`
|
||||
- **Import Style:** Use relative imports.
|
||||
- Example:
|
||||
```js
|
||||
import myUtil from './utils/myUtil.js';
|
||||
```
|
||||
- **Export Style:** Mixed (both default and named exports are used).
|
||||
- Example:
|
||||
```js
|
||||
// Named export
|
||||
export function doSomething() { ... }
|
||||
- **Primary Language**: JavaScript
|
||||
- **Architecture**: hybrid module organization
|
||||
- **Test Location**: separate
|
||||
|
||||
// Default export
|
||||
export default MyComponent;
|
||||
```
|
||||
- **Commit Messages:** Follow [Conventional Commits](https://www.conventionalcommits.org/) with prefixes like `fix`, `feat`, `docs`, `chore`.
|
||||
- Example: `feat: add support for new install target`
|
||||
- **Documentation:** Each skill or command should have a `SKILL.md` or markdown documentation file in its directory.
|
||||
## When to Use This Skill
|
||||
|
||||
## Workflows
|
||||
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
|
||||
|
||||
### Add or Update a Skill
|
||||
**Trigger:** When adding or updating a skill for agents or workflows
|
||||
**Command:** `/add-skill`
|
||||
## Commit Conventions
|
||||
|
||||
1. Create or update `SKILL.md` in `skills/[skill-name]/` or `.agents/skills/[skill-name]/`.
|
||||
2. Optionally add or update related reference files (e.g., `references/*.md`, `assets/*.py`).
|
||||
3. Register the skill in `manifests/install-modules.json` and/or `manifests/install-components.json`.
|
||||
4. Update `AGENTS.md`, `README.md`, and `docs/zh-CN/AGENTS.md` as needed.
|
||||
5. If the skill is agent-facing, update `.agents/skills/[skill-name]/SKILL.md`.
|
||||
Follow these commit message conventions based on 500 analyzed commits.
|
||||
|
||||
**Example:**
|
||||
```json
|
||||
// manifests/install-modules.json
|
||||
{
|
||||
"skills": [
|
||||
"myNewSkill"
|
||||
]
|
||||
### 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
|
||||
|
||||
### Add or Update a Command Workflow
|
||||
**Trigger:** When introducing or refining a workflow command
|
||||
**Command:** `/add-command`
|
||||
These workflows were detected from analyzing commit patterns.
|
||||
|
||||
1. Create or update a command markdown file in `commands/` or `.claude/commands/`.
|
||||
2. Iterate based on review feedback (fixes, improvements, removal of external links, etc.).
|
||||
3. Update related documentation or references if needed.
|
||||
### Database Migration
|
||||
|
||||
**Example:**
|
||||
```markdown
|
||||
// commands/myCommand.md
|
||||
# My Command
|
||||
Description and usage...
|
||||
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
|
||||
|
||||
### Refactor Skill or Agent Structure
|
||||
**Trigger:** When reorganizing skills, merging/splitting logic, or extracting shared code
|
||||
**Command:** `/refactor-skill`
|
||||
Standard feature implementation workflow
|
||||
|
||||
1. Edit multiple `SKILL.md` files in `skills/` and/or `.agents/skills/`.
|
||||
2. Update `AGENTS.md`, `README.md`, `README.zh-CN.md`, and `docs/zh-CN/*` as needed.
|
||||
3. Update `manifests/install-modules.json` or related manifests.
|
||||
4. Remove or merge obsolete command files.
|
||||
**Frequency**: ~22 times per month
|
||||
|
||||
---
|
||||
**Steps**:
|
||||
1. Add feature implementation
|
||||
2. Add tests for feature
|
||||
3. Update documentation
|
||||
|
||||
### Add or Update Install Target
|
||||
**Trigger:** When supporting a new platform or updating install logic
|
||||
**Command:** `/add-install-target`
|
||||
**Files typically involved**:
|
||||
- `manifests/*`
|
||||
- `schemas/*`
|
||||
- `**/*.test.*`
|
||||
- `**/api/**`
|
||||
|
||||
1. Add or update install scripts and documentation under a dot-directory (e.g., `.codebuddy/`, `.gemini/`).
|
||||
2. Update `manifests/install-modules.json` and `schemas/ecc-install-config.schema.json`.
|
||||
3. Update or create scripts in `scripts/lib/install-targets/[target].js`.
|
||||
4. Update `registry.js` and `install-manifests.js` as needed.
|
||||
5. Add or update tests in `tests/lib/install-targets.test.js`.
|
||||
|
||||
**Example:**
|
||||
```js
|
||||
// scripts/lib/install-targets/codeBuddy.js
|
||||
export function installCodeBuddy() { ... }
|
||||
**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
|
||||
|
||||
### Update Hooks and Automation
|
||||
**Trigger:** When improving or fixing hooks, audit logs, or CI/CD automation
|
||||
**Command:** `/update-hook`
|
||||
Adds a new programming language to the rules system, including coding style, hooks, patterns, security, and testing guidelines.
|
||||
|
||||
1. Edit `hooks/hooks.json` and/or add/update `scripts/hooks/*.js`.
|
||||
2. Update or add related test files in `tests/hooks/` or `tests/scripts/`.
|
||||
3. Edit `.github/workflows/*.yml` for CI/CD changes.
|
||||
4. Update `package.json` or related config if needed.
|
||||
**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
|
||||
|
||||
### Documentation Sync and Guidance Update
|
||||
**Trigger:** When updating repo guidance, syncing documentation, or clarifying workflows
|
||||
**Command:** `/update-docs`
|
||||
**Files typically involved**:
|
||||
- `rules/*/coding-style.md`
|
||||
- `rules/*/hooks.md`
|
||||
- `rules/*/patterns.md`
|
||||
- `rules/*/security.md`
|
||||
- `rules/*/testing.md`
|
||||
|
||||
1. Edit one or more of `AGENTS.md`, `README.md`, `README.zh-CN.md`, `WORKING-CONTEXT.md`, and `docs/zh-CN/*`.
|
||||
2. Update or add `.claude-plugin/README.md`, `.codex-plugin/README.md`, or `the-shortform-guide.md` as needed.
|
||||
3. Optionally update `package.json` or `scripts/ci/catalog.js` if documentation affects tooling.
|
||||
|
||||
---
|
||||
|
||||
## Testing Patterns
|
||||
|
||||
- **Test Files:** Use the `*.test.js` naming convention.
|
||||
- Example: `mySkill.test.js`
|
||||
- **Framework:** Not explicitly detected; follow standard JavaScript testing practices.
|
||||
- **Location:** Tests are typically located in `tests/` directories, mirroring the structure of the code they test.
|
||||
- **Example:**
|
||||
```js
|
||||
// tests/mySkill.test.js
|
||||
import { mySkill } from '../skills/mySkill.js';
|
||||
|
||||
test('mySkill does something', () => {
|
||||
expect(mySkill()).toBe(true);
|
||||
});
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
| Command | Purpose |
|
||||
|--------------------|--------------------------------------------------------|
|
||||
| /add-skill | Add or update a skill and register it in manifests |
|
||||
| /add-command | Add or update a command workflow |
|
||||
| /refactor-skill | Refactor skill or agent structure |
|
||||
| /add-install-target| Add or update an install target integration |
|
||||
| /update-hook | Update hooks, automation, or CI/CD workflows |
|
||||
| /update-docs | Sync or update documentation and repo guidance |
|
||||
**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 Workflow Surface
|
||||
|
||||
Adds or updates a workflow entrypoint. Default to skills-first; only add a command shim when legacy slash compatibility is still required.
|
||||
|
||||
**Frequency**: ~1 times per month
|
||||
|
||||
**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
|
||||
```
|
||||
|
||||
### 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.*
|
||||
|
||||
@@ -24,6 +24,11 @@ Write investor communication that is short, concrete, and easy to act on.
|
||||
4. Stay concise.
|
||||
5. Never send copy that could go to any investor.
|
||||
|
||||
## Voice Handling
|
||||
|
||||
If the user's voice matters, run `brand-voice` first and reuse its `VOICE PROFILE`.
|
||||
This skill should keep the investor-specific structure and ask discipline, not recreate its own parallel voice system.
|
||||
|
||||
## Hard Bans
|
||||
|
||||
Delete and rewrite any of these:
|
||||
@@ -31,7 +36,6 @@ Delete and rewrite any of these:
|
||||
- "excited to share"
|
||||
- generic thesis praise without a real tie-in
|
||||
- vague founder adjectives
|
||||
- "no fluff"
|
||||
- begging language
|
||||
- soft closing questions when a direct ask is clearer
|
||||
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
name: add-or-update-skill
|
||||
description: Workflow command scaffold for add-or-update-skill in everything-claude-code.
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /add-or-update-skill
|
||||
|
||||
Use this workflow when working on **add-or-update-skill** in `everything-claude-code`.
|
||||
|
||||
## Goal
|
||||
|
||||
Adds a new skill or updates an existing skill in the agents or skills directory, with documentation and registration in manifests.
|
||||
|
||||
## Common Files
|
||||
|
||||
- `skills/*/SKILL.md`
|
||||
- `.agents/skills/*/SKILL.md`
|
||||
- `manifests/install-modules.json`
|
||||
- `manifests/install-components.json`
|
||||
- `AGENTS.md`
|
||||
- `README.md`
|
||||
|
||||
## Suggested Sequence
|
||||
|
||||
1. Understand the current state and failure mode before editing.
|
||||
2. Make the smallest coherent change that satisfies the workflow goal.
|
||||
3. Run the most relevant verification for touched files.
|
||||
4. Summarize what changed and what still needs review.
|
||||
|
||||
## Typical Commit Signals
|
||||
|
||||
- Create or update SKILL.md in skills/[skill-name]/ or .agents/skills/[skill-name]/
|
||||
- Optionally add or update related reference files (e.g., references/*.md, assets/*.py)
|
||||
- Update manifests/install-modules.json and/or manifests/install-components.json to register the skill
|
||||
- Update AGENTS.md, README.md, and docs/zh-CN/AGENTS.md as needed
|
||||
- If skill is agent-facing, update .agents/skills/[skill-name]/SKILL.md
|
||||
|
||||
## Notes
|
||||
|
||||
- Treat this as a scaffold, not a hard-coded script.
|
||||
- Update the command if the workflow evolves materially.
|
||||
@@ -14,9 +14,8 @@ Standard feature implementation workflow
|
||||
|
||||
## Common Files
|
||||
|
||||
- `.opencode/*`
|
||||
- `.opencode/plugins/*`
|
||||
- `.opencode/plugins/lib/*`
|
||||
- `manifests/*`
|
||||
- `schemas/*`
|
||||
- `**/*.test.*`
|
||||
- `**/api/**`
|
||||
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
name: refactoring
|
||||
description: Workflow command scaffold for refactoring in everything-claude-code.
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /refactoring
|
||||
|
||||
Use this workflow when working on **refactoring** in `everything-claude-code`.
|
||||
|
||||
## Goal
|
||||
|
||||
Code refactoring and cleanup workflow
|
||||
|
||||
## Common Files
|
||||
|
||||
- `src/**/*`
|
||||
|
||||
## Suggested Sequence
|
||||
|
||||
1. Understand the current state and failure mode before editing.
|
||||
2. Make the smallest coherent change that satisfies the workflow goal.
|
||||
3. Run the most relevant verification for touched files.
|
||||
4. Summarize what changed and what still needs review.
|
||||
|
||||
## Typical Commit Signals
|
||||
|
||||
- Ensure tests pass before refactor
|
||||
- Refactor code structure
|
||||
- Verify tests still pass
|
||||
|
||||
## Notes
|
||||
|
||||
- Treat this as a scaffold, not a hard-coded script.
|
||||
- Update the command if the workflow evolves materially.
|
||||
@@ -2,7 +2,7 @@
|
||||
"version": "1.3",
|
||||
"schemaVersion": "1.0",
|
||||
"generatedBy": "ecc-tools",
|
||||
"generatedAt": "2026-04-02T18:08:28.699Z",
|
||||
"generatedAt": "2026-03-20T12:07:36.496Z",
|
||||
"repo": "https://github.com/affaan-m/everything-claude-code",
|
||||
"profiles": {
|
||||
"requested": "full",
|
||||
@@ -148,9 +148,9 @@
|
||||
".claude/research/everything-claude-code-research-playbook.md",
|
||||
".claude/team/everything-claude-code-team-config.json",
|
||||
".claude/enterprise/controls.md",
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/refactoring.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
".claude/commands/add-language-rules.md"
|
||||
],
|
||||
"packageFiles": {
|
||||
"runtime-core": [
|
||||
@@ -178,9 +178,9 @@
|
||||
".claude/enterprise/controls.md"
|
||||
],
|
||||
"workflow-pack": [
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/refactoring.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
".claude/commands/add-language-rules.md"
|
||||
]
|
||||
},
|
||||
"moduleFiles": {
|
||||
@@ -209,9 +209,9 @@
|
||||
".claude/enterprise/controls.md"
|
||||
],
|
||||
"workflow-pack": [
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/refactoring.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
".claude/commands/add-language-rules.md"
|
||||
]
|
||||
},
|
||||
"files": [
|
||||
@@ -285,6 +285,11 @@
|
||||
"path": ".claude/enterprise/controls.md",
|
||||
"description": "Enterprise governance scaffold for approvals, audit posture, and escalation."
|
||||
},
|
||||
{
|
||||
"moduleId": "workflow-pack",
|
||||
"path": ".claude/commands/database-migration.md",
|
||||
"description": "Workflow command scaffold for database-migration."
|
||||
},
|
||||
{
|
||||
"moduleId": "workflow-pack",
|
||||
"path": ".claude/commands/feature-development.md",
|
||||
@@ -292,27 +297,22 @@
|
||||
},
|
||||
{
|
||||
"moduleId": "workflow-pack",
|
||||
"path": ".claude/commands/refactoring.md",
|
||||
"description": "Workflow command scaffold for refactoring."
|
||||
},
|
||||
{
|
||||
"moduleId": "workflow-pack",
|
||||
"path": ".claude/commands/add-or-update-skill.md",
|
||||
"description": "Workflow command scaffold for add-or-update-skill."
|
||||
"path": ".claude/commands/add-language-rules.md",
|
||||
"description": "Workflow command scaffold for add-language-rules."
|
||||
}
|
||||
],
|
||||
"workflows": [
|
||||
{
|
||||
"command": "database-migration",
|
||||
"path": ".claude/commands/database-migration.md"
|
||||
},
|
||||
{
|
||||
"command": "feature-development",
|
||||
"path": ".claude/commands/feature-development.md"
|
||||
},
|
||||
{
|
||||
"command": "refactoring",
|
||||
"path": ".claude/commands/refactoring.md"
|
||||
},
|
||||
{
|
||||
"command": "add-or-update-skill",
|
||||
"path": ".claude/commands/add-or-update-skill.md"
|
||||
"command": "add-language-rules",
|
||||
"path": ".claude/commands/add-language-rules.md"
|
||||
}
|
||||
],
|
||||
"adapters": {
|
||||
@@ -320,9 +320,9 @@
|
||||
"skillPath": ".claude/skills/everything-claude-code/SKILL.md",
|
||||
"identityPath": ".claude/identity.json",
|
||||
"commandPaths": [
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/refactoring.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
".claude/commands/add-language-rules.md"
|
||||
]
|
||||
},
|
||||
"codex": {
|
||||
|
||||
@@ -10,5 +10,5 @@
|
||||
"javascript"
|
||||
],
|
||||
"suggestedBy": "ecc-tools-repo-analysis",
|
||||
"createdAt": "2026-04-02T18:09:33.367Z"
|
||||
"createdAt": "2026-03-20T12:07:57.119Z"
|
||||
}
|
||||
@@ -18,4 +18,4 @@ Use this when the task is documentation-heavy, source-sensitive, or requires bro
|
||||
|
||||
- Primary language: JavaScript
|
||||
- Framework: Not detected
|
||||
- Workflows detected: 8
|
||||
- Workflows detected: 10
|
||||
@@ -4,7 +4,7 @@ Generated by ECC Tools from repository history. Review before treating it as a h
|
||||
|
||||
## Commit Workflow
|
||||
|
||||
- Prefer `conventional` commit messaging with prefixes such as fix, feat, docs, chore.
|
||||
- Prefer `conventional` commit messaging with prefixes such as fix, test, feat, docs.
|
||||
- Keep new changes aligned with the existing pull-request and review flow already present in the repo.
|
||||
|
||||
## Architecture
|
||||
@@ -24,9 +24,9 @@ Generated by ECC Tools from repository history. Review before treating it as a h
|
||||
|
||||
## Detected Workflows
|
||||
|
||||
- database-migration: Database schema changes with migration files
|
||||
- feature-development: Standard feature implementation workflow
|
||||
- refactoring: Code refactoring and cleanup workflow
|
||||
- add-or-update-skill: Adds a new skill or updates an existing skill in the agents or skills directory, with documentation and registration in manifests.
|
||||
- add-language-rules: Adds a new programming language to the rules system, including coding style, hooks, patterns, security, and testing guidelines.
|
||||
|
||||
## Review Reminder
|
||||
|
||||
|
||||
@@ -1,150 +1,442 @@
|
||||
```markdown
|
||||
# everything-claude-code Development Patterns
|
||||
---
|
||||
name: everything-claude-code-conventions
|
||||
description: Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.
|
||||
---
|
||||
|
||||
> Auto-generated skill from repository analysis
|
||||
# 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 provides a comprehensive guide to the development patterns, workflows, and coding conventions used in the `everything-claude-code` repository. It covers how to add or update skills, commands, install targets, hooks, and documentation, as well as the repository's JavaScript coding style and testing patterns. This guide is intended for contributors looking to maintain consistency and efficiency when working within this codebase.
|
||||
This skill teaches Claude the development patterns and conventions used in everything-claude-code.
|
||||
|
||||
## Coding Conventions
|
||||
## Tech Stack
|
||||
|
||||
- **Language:** JavaScript (no framework detected)
|
||||
- **File Naming:** Use `camelCase` for JavaScript files and folders.
|
||||
- Example: `mySkill.js`, `installTarget.js`
|
||||
- **Import Style:** Use relative imports.
|
||||
- Example:
|
||||
```js
|
||||
import myUtil from './utils/myUtil.js';
|
||||
```
|
||||
- **Export Style:** Mixed (both default and named exports are used).
|
||||
- Example:
|
||||
```js
|
||||
// Named export
|
||||
export function doSomething() { ... }
|
||||
- **Primary Language**: JavaScript
|
||||
- **Architecture**: hybrid module organization
|
||||
- **Test Location**: separate
|
||||
|
||||
// Default export
|
||||
export default MyComponent;
|
||||
```
|
||||
- **Commit Messages:** Follow [Conventional Commits](https://www.conventionalcommits.org/) with prefixes like `fix`, `feat`, `docs`, `chore`.
|
||||
- Example: `feat: add support for new install target`
|
||||
- **Documentation:** Each skill or command should have a `SKILL.md` or markdown documentation file in its directory.
|
||||
## When to Use This Skill
|
||||
|
||||
## Workflows
|
||||
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
|
||||
|
||||
### Add or Update a Skill
|
||||
**Trigger:** When adding or updating a skill for agents or workflows
|
||||
**Command:** `/add-skill`
|
||||
## Commit Conventions
|
||||
|
||||
1. Create or update `SKILL.md` in `skills/[skill-name]/` or `.agents/skills/[skill-name]/`.
|
||||
2. Optionally add or update related reference files (e.g., `references/*.md`, `assets/*.py`).
|
||||
3. Register the skill in `manifests/install-modules.json` and/or `manifests/install-components.json`.
|
||||
4. Update `AGENTS.md`, `README.md`, and `docs/zh-CN/AGENTS.md` as needed.
|
||||
5. If the skill is agent-facing, update `.agents/skills/[skill-name]/SKILL.md`.
|
||||
Follow these commit message conventions based on 500 analyzed commits.
|
||||
|
||||
**Example:**
|
||||
```json
|
||||
// manifests/install-modules.json
|
||||
{
|
||||
"skills": [
|
||||
"myNewSkill"
|
||||
]
|
||||
### 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
|
||||
|
||||
### Add or Update a Command Workflow
|
||||
**Trigger:** When introducing or refining a workflow command
|
||||
**Command:** `/add-command`
|
||||
These workflows were detected from analyzing commit patterns.
|
||||
|
||||
1. Create or update a command markdown file in `commands/` or `.claude/commands/`.
|
||||
2. Iterate based on review feedback (fixes, improvements, removal of external links, etc.).
|
||||
3. Update related documentation or references if needed.
|
||||
### Database Migration
|
||||
|
||||
**Example:**
|
||||
```markdown
|
||||
// commands/myCommand.md
|
||||
# My Command
|
||||
Description and usage...
|
||||
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
|
||||
|
||||
### Refactor Skill or Agent Structure
|
||||
**Trigger:** When reorganizing skills, merging/splitting logic, or extracting shared code
|
||||
**Command:** `/refactor-skill`
|
||||
Standard feature implementation workflow
|
||||
|
||||
1. Edit multiple `SKILL.md` files in `skills/` and/or `.agents/skills/`.
|
||||
2. Update `AGENTS.md`, `README.md`, `README.zh-CN.md`, and `docs/zh-CN/*` as needed.
|
||||
3. Update `manifests/install-modules.json` or related manifests.
|
||||
4. Remove or merge obsolete command files.
|
||||
**Frequency**: ~22 times per month
|
||||
|
||||
---
|
||||
**Steps**:
|
||||
1. Add feature implementation
|
||||
2. Add tests for feature
|
||||
3. Update documentation
|
||||
|
||||
### Add or Update Install Target
|
||||
**Trigger:** When supporting a new platform or updating install logic
|
||||
**Command:** `/add-install-target`
|
||||
**Files typically involved**:
|
||||
- `manifests/*`
|
||||
- `schemas/*`
|
||||
- `**/*.test.*`
|
||||
- `**/api/**`
|
||||
|
||||
1. Add or update install scripts and documentation under a dot-directory (e.g., `.codebuddy/`, `.gemini/`).
|
||||
2. Update `manifests/install-modules.json` and `schemas/ecc-install-config.schema.json`.
|
||||
3. Update or create scripts in `scripts/lib/install-targets/[target].js`.
|
||||
4. Update `registry.js` and `install-manifests.js` as needed.
|
||||
5. Add or update tests in `tests/lib/install-targets.test.js`.
|
||||
|
||||
**Example:**
|
||||
```js
|
||||
// scripts/lib/install-targets/codeBuddy.js
|
||||
export function installCodeBuddy() { ... }
|
||||
**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
|
||||
|
||||
### Update Hooks and Automation
|
||||
**Trigger:** When improving or fixing hooks, audit logs, or CI/CD automation
|
||||
**Command:** `/update-hook`
|
||||
Adds a new programming language to the rules system, including coding style, hooks, patterns, security, and testing guidelines.
|
||||
|
||||
1. Edit `hooks/hooks.json` and/or add/update `scripts/hooks/*.js`.
|
||||
2. Update or add related test files in `tests/hooks/` or `tests/scripts/`.
|
||||
3. Edit `.github/workflows/*.yml` for CI/CD changes.
|
||||
4. Update `package.json` or related config if needed.
|
||||
**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
|
||||
|
||||
### Documentation Sync and Guidance Update
|
||||
**Trigger:** When updating repo guidance, syncing documentation, or clarifying workflows
|
||||
**Command:** `/update-docs`
|
||||
**Files typically involved**:
|
||||
- `rules/*/coding-style.md`
|
||||
- `rules/*/hooks.md`
|
||||
- `rules/*/patterns.md`
|
||||
- `rules/*/security.md`
|
||||
- `rules/*/testing.md`
|
||||
|
||||
1. Edit one or more of `AGENTS.md`, `README.md`, `README.zh-CN.md`, `WORKING-CONTEXT.md`, and `docs/zh-CN/*`.
|
||||
2. Update or add `.claude-plugin/README.md`, `.codex-plugin/README.md`, or `the-shortform-guide.md` as needed.
|
||||
3. Optionally update `package.json` or `scripts/ci/catalog.js` if documentation affects tooling.
|
||||
|
||||
---
|
||||
|
||||
## Testing Patterns
|
||||
|
||||
- **Test Files:** Use the `*.test.js` naming convention.
|
||||
- Example: `mySkill.test.js`
|
||||
- **Framework:** Not explicitly detected; follow standard JavaScript testing practices.
|
||||
- **Location:** Tests are typically located in `tests/` directories, mirroring the structure of the code they test.
|
||||
- **Example:**
|
||||
```js
|
||||
// tests/mySkill.test.js
|
||||
import { mySkill } from '../skills/mySkill.js';
|
||||
|
||||
test('mySkill does something', () => {
|
||||
expect(mySkill()).toBe(true);
|
||||
});
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
| Command | Purpose |
|
||||
|--------------------|--------------------------------------------------------|
|
||||
| /add-skill | Add or update a skill and register it in manifests |
|
||||
| /add-command | Add or update a command workflow |
|
||||
| /refactor-skill | Refactor skill or agent structure |
|
||||
| /add-install-target| Add or update an install target integration |
|
||||
| /update-hook | Update hooks, automation, or CI/CD workflows |
|
||||
| /update-docs | Sync or update documentation and repo guidance |
|
||||
**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.*
|
||||
|
||||
@@ -7,9 +7,9 @@
|
||||
".agents/skills/everything-claude-code/SKILL.md"
|
||||
],
|
||||
"commandFiles": [
|
||||
".claude/commands/database-migration.md",
|
||||
".claude/commands/feature-development.md",
|
||||
".claude/commands/refactoring.md",
|
||||
".claude/commands/add-or-update-skill.md"
|
||||
".claude/commands/add-language-rules.md"
|
||||
],
|
||||
"updatedAt": "2026-04-02T18:08:28.699Z"
|
||||
"updatedAt": "2026-03-20T12:07:36.496Z"
|
||||
}
|
||||
@@ -111,3 +111,4 @@ Keep this file detailed for only the current sprint, blockers, and next actions.
|
||||
- 2026-04-01: Added `connections-optimizer` as the review-first social-graph reorganization workflow for X and LinkedIn, with explicit pruning modes, browser fallback expectations, and Apple Mail drafting guidance.
|
||||
- 2026-04-01: Added `manim-video` as the reusable technical explainer lane and seeded it with a starter network-graph scene so launch and systems animations do not depend on one-off scratch scripts.
|
||||
- 2026-04-02: Re-extracted `social-graph-ranker` as a standalone primitive because the weighted bridge-decay model is reusable outside the full lead workflow. `lead-intelligence` now points to it for canonical graph ranking instead of carrying the full algorithm explanation inline, while `connections-optimizer` stays the broader operator layer for pruning, adds, and outbound review packs.
|
||||
- 2026-04-02: Applied the same consolidation rule to the writing lane. `brand-voice` remains the canonical voice system, while `content-engine`, `crosspost`, `article-writing`, and `investor-outreach` now keep only workflow-specific guidance instead of duplicating a second Affaan/ECC voice model or repeating the full ban list in multiple places.
|
||||
|
||||
@@ -23,50 +23,23 @@ Write long-form content that sounds like an actual person with a point of view,
|
||||
4. Use proof instead of adjectives.
|
||||
5. Never invent facts, credibility, or customer evidence.
|
||||
|
||||
## Voice Capture Workflow
|
||||
## Voice Handling
|
||||
|
||||
If the user wants a specific voice, collect one or more of:
|
||||
- published articles
|
||||
- newsletters
|
||||
- X posts or threads
|
||||
- docs or memos
|
||||
- launch notes
|
||||
- a style guide
|
||||
|
||||
Then extract:
|
||||
- sentence length and rhythm
|
||||
- whether the writing is compressed, explanatory, sharp, or formal
|
||||
- how parentheses are used
|
||||
- how often the writer asks questions
|
||||
- whether the writer uses fragments, lists, or hard pivots
|
||||
- formatting habits such as headers, bullets, code blocks, pull quotes
|
||||
- what the writer clearly avoids
|
||||
If the user wants a specific voice, run `brand-voice` first and reuse its `VOICE PROFILE`.
|
||||
Do not duplicate a second style-analysis pass here unless the user explicitly asks for one.
|
||||
|
||||
If no voice references are given, default to a sharp operator voice: concrete, unsentimental, useful.
|
||||
|
||||
## Affaan / ECC Voice Reference
|
||||
|
||||
When matching Affaan / ECC voice, bias toward:
|
||||
- direct claims over scene-setting
|
||||
- high specificity
|
||||
- parentheticals used for qualification or over-clarification, not comedy
|
||||
- capitalization chosen situationally, not as a gimmick
|
||||
- very low tolerance for fake thought-leadership cadence
|
||||
- almost no bait questions
|
||||
|
||||
## Banned Patterns
|
||||
|
||||
Delete and rewrite any of these:
|
||||
- "In today's rapidly evolving landscape"
|
||||
- "game-changer", "cutting-edge", "revolutionary"
|
||||
- "no fluff"
|
||||
- "not X, just Y"
|
||||
- "here's why this matters" as a standalone bridge
|
||||
- fake vulnerability arcs
|
||||
- a closing question added only to juice engagement
|
||||
- forced lowercase
|
||||
- corny parenthetical asides
|
||||
- biography padding that does not move the argument
|
||||
- generic AI throat-clearing that delays the point
|
||||
|
||||
## Writing Process
|
||||
|
||||
@@ -101,6 +74,6 @@ Delete and rewrite any of these:
|
||||
Before delivering:
|
||||
- factual claims are backed by provided sources
|
||||
- generic AI transitions are gone
|
||||
- the voice matches the supplied examples
|
||||
- the voice matches the supplied examples or the agreed `VOICE PROFILE`
|
||||
- every section adds something new
|
||||
- formatting matches the intended medium
|
||||
|
||||
@@ -38,50 +38,28 @@ Before drafting, identify the source set:
|
||||
If the user wants a specific voice, build a voice profile from real examples before writing.
|
||||
Use `brand-voice` as the canonical workflow when voice consistency matters across more than one output.
|
||||
|
||||
## Voice Capture Workflow
|
||||
## Voice Handling
|
||||
|
||||
Run `brand-voice` first when:
|
||||
`brand-voice` is the canonical voice layer.
|
||||
|
||||
Run it first when:
|
||||
|
||||
- there are multiple downstream outputs
|
||||
- the user explicitly cares about writing style
|
||||
- the content is launch, outreach, or reputation-sensitive
|
||||
|
||||
At minimum, produce a compact `VOICE PROFILE` covering:
|
||||
- rhythm
|
||||
- compression
|
||||
- capitalization
|
||||
- parenthetical use
|
||||
- question use
|
||||
- preferred moves
|
||||
- banned moves
|
||||
|
||||
Do not start drafting until the voice profile is clear enough to enforce.
|
||||
|
||||
## Affaan / ECC Voice Reference
|
||||
|
||||
When the user wants Affaan / ECC voice specifically, default to this unless newer examples clearly override it:
|
||||
- direct, compressed, concrete
|
||||
- strong preference for specific claims, numbers, mechanisms, and receipts
|
||||
- parentheticals used to qualify, narrow, or over-clarify, not to do corny bits
|
||||
- lowercase is optional, not mandatory
|
||||
- questions are rare and should not be added as bait
|
||||
- transitions should feel earned, not polished
|
||||
- tone can be sharp or blunt, but should not sound like a content marketer
|
||||
Reuse the resulting `VOICE PROFILE` here instead of rebuilding a second voice model.
|
||||
If the user wants Affaan / ECC voice specifically, still treat `brand-voice` as the source of truth and feed it the best live or source-derived material available.
|
||||
|
||||
## Hard Bans
|
||||
|
||||
Delete and rewrite any of these:
|
||||
- "In today's rapidly evolving landscape"
|
||||
- "game-changer", "revolutionary", "cutting-edge"
|
||||
- "no fluff"
|
||||
- "not X, just Y"
|
||||
- "here's why this matters" unless it is followed immediately by something concrete
|
||||
- "Excited to share"
|
||||
- fake curiosity gaps
|
||||
- ending with a LinkedIn-style question just to farm replies
|
||||
- forced lowercase when the source voice does not call for it
|
||||
- forced casualness on LinkedIn
|
||||
- parenthetical jokes that were not present in the source voice
|
||||
- fake engagement padding that was not present in the source material
|
||||
|
||||
## Platform Adaptation Rules
|
||||
|
||||
|
||||
@@ -39,13 +39,8 @@ Use `content-engine` first if the source still needs voice shaping.
|
||||
|
||||
Run `brand-voice` first if the source voice is not already captured in the current session.
|
||||
|
||||
Before adapting, note:
|
||||
- how blunt or explanatory the source is
|
||||
- whether the source uses fragments, lists, or longer transitions
|
||||
- whether the source uses parentheses
|
||||
- whether the source avoids questions, hashtags, or CTA language
|
||||
|
||||
The adaptation should preserve that fingerprint.
|
||||
Reuse the resulting `VOICE PROFILE` directly.
|
||||
Do not build a second ad hoc voice checklist here unless the user explicitly wants a fresh override for this campaign.
|
||||
|
||||
### Step 3: Adapt by Platform Constraint
|
||||
|
||||
@@ -91,7 +86,6 @@ Delete and rewrite any of these:
|
||||
- "Here's what I learned"
|
||||
- "What do you think?"
|
||||
- "link in bio" unless that is literally true
|
||||
- "not X, just Y"
|
||||
- generic "professional takeaway" paragraphs that were not in the source
|
||||
|
||||
## Output Format
|
||||
|
||||
@@ -24,6 +24,11 @@ Write investor communication that is short, concrete, and easy to act on.
|
||||
4. Stay concise.
|
||||
5. Never send copy that could go to any investor.
|
||||
|
||||
## Voice Handling
|
||||
|
||||
If the user's voice matters, run `brand-voice` first and reuse its `VOICE PROFILE`.
|
||||
This skill should keep the investor-specific structure and ask discipline, not recreate its own parallel voice system.
|
||||
|
||||
## Hard Bans
|
||||
|
||||
Delete and rewrite any of these:
|
||||
@@ -31,7 +36,6 @@ Delete and rewrite any of these:
|
||||
- "excited to share"
|
||||
- generic thesis praise without a real tie-in
|
||||
- vague founder adjectives
|
||||
- "no fluff"
|
||||
- begging language
|
||||
- soft closing questions when a direct ask is clearer
|
||||
|
||||
|
||||
Reference in New Issue
Block a user