mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-11 02:33:10 +08:00
Compare commits
3 Commits
contrib/mo
...
feat/skill
| Author | SHA1 | Date | |
|---|---|---|---|
|
b1d3d13ccf | ||
|
|
6040746ea5 | ||
|
|
bdbcc5d4df |
@@ -1,12 +1,11 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"name": "everything-claude-code",
|
||||
"interface": {
|
||||
"displayName": "Everything Claude Code"
|
||||
},
|
||||
"plugins": [
|
||||
{
|
||||
"name": "ecc",
|
||||
"version": "2.0.0-rc.1",
|
||||
"name": "everything-claude-code",
|
||||
"source": {
|
||||
"source": "local",
|
||||
"path": "../.."
|
||||
|
||||
@@ -1,152 +0,0 @@
|
||||
---
|
||||
name: agent-introspection-debugging
|
||||
description: Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports.
|
||||
---
|
||||
|
||||
# Agent Introspection Debugging
|
||||
|
||||
Use this skill when an agent run is failing repeatedly, consuming tokens without progress, looping on the same tools, or drifting away from the intended task.
|
||||
|
||||
This is a workflow skill, not a hidden runtime. It teaches the agent to debug itself systematically before escalating to a human.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- Maximum tool call / loop-limit failures
|
||||
- Repeated retries with no forward progress
|
||||
- Context growth or prompt drift that starts degrading output quality
|
||||
- File-system or environment state mismatch between expectation and reality
|
||||
- Tool failures that are likely recoverable with diagnosis and a smaller corrective action
|
||||
|
||||
## Scope Boundaries
|
||||
|
||||
Activate this skill for:
|
||||
- capturing failure state before retrying blindly
|
||||
- diagnosing common agent-specific failure patterns
|
||||
- applying contained recovery actions
|
||||
- producing a structured human-readable debug report
|
||||
|
||||
Do not use this skill as the primary source for:
|
||||
- feature verification after code changes; use `verification-loop`
|
||||
- framework-specific debugging when a narrower ECC skill already exists
|
||||
- runtime promises the current harness cannot enforce automatically
|
||||
|
||||
## Four-Phase Loop
|
||||
|
||||
### Phase 1: Failure Capture
|
||||
|
||||
Before trying to recover, record the failure precisely.
|
||||
|
||||
Capture:
|
||||
- error type, message, and stack trace when available
|
||||
- last meaningful tool call sequence
|
||||
- what the agent was trying to do
|
||||
- current context pressure: repeated prompts, oversized pasted logs, duplicated plans, or runaway notes
|
||||
- current environment assumptions: cwd, branch, relevant service state, expected files
|
||||
|
||||
Minimum capture template:
|
||||
|
||||
```markdown
|
||||
## Failure Capture
|
||||
- Session / task:
|
||||
- Goal in progress:
|
||||
- Error:
|
||||
- Last successful step:
|
||||
- Last failed tool / command:
|
||||
- Repeated pattern seen:
|
||||
- Environment assumptions to verify:
|
||||
```
|
||||
|
||||
### Phase 2: Root-Cause Diagnosis
|
||||
|
||||
Match the failure to a known pattern before changing anything.
|
||||
|
||||
| Pattern | Likely Cause | Check |
|
||||
| --- | --- | --- |
|
||||
| Maximum tool calls / repeated same command | loop or no-exit observer path | inspect the last N tool calls for repetition |
|
||||
| Context overflow / degraded reasoning | unbounded notes, repeated plans, oversized logs | inspect recent context for duplication and low-signal bulk |
|
||||
| `ECONNREFUSED` / timeout | service unavailable or wrong port | verify service health, URL, and port assumptions |
|
||||
| `429` / quota exhaustion | retry storm or missing backoff | count repeated calls and inspect retry spacing |
|
||||
| file missing after write / stale diff | race, wrong cwd, or branch drift | re-check path, cwd, git status, and actual file existence |
|
||||
| tests still failing after “fix” | wrong hypothesis | isolate the exact failing test and re-derive the bug |
|
||||
|
||||
Diagnosis questions:
|
||||
- is this a logic failure, state failure, environment failure, or policy failure?
|
||||
- did the agent lose the real objective and start optimizing the wrong subtask?
|
||||
- is the failure deterministic or transient?
|
||||
- what is the smallest reversible action that would validate the diagnosis?
|
||||
|
||||
### Phase 3: Contained Recovery
|
||||
|
||||
Recover with the smallest action that changes the diagnosis surface.
|
||||
|
||||
Safe recovery actions:
|
||||
- stop repeated retries and restate the hypothesis
|
||||
- trim low-signal context and keep only the active goal, blockers, and evidence
|
||||
- re-check the actual filesystem / branch / process state
|
||||
- narrow the task to one failing command, one file, or one test
|
||||
- switch from speculative reasoning to direct observation
|
||||
- escalate to a human when the failure is high-risk or externally blocked
|
||||
|
||||
Do not claim unsupported auto-healing actions like “reset agent state” or “update harness config” unless you are actually doing them through real tools in the current environment.
|
||||
|
||||
Contained recovery checklist:
|
||||
|
||||
```markdown
|
||||
## Recovery Action
|
||||
- Diagnosis chosen:
|
||||
- Smallest action taken:
|
||||
- Why this is safe:
|
||||
- What evidence would prove the fix worked:
|
||||
```
|
||||
|
||||
### Phase 4: Introspection Report
|
||||
|
||||
End with a report that makes the recovery legible to the next agent or human.
|
||||
|
||||
```markdown
|
||||
## Agent Self-Debug Report
|
||||
- Session / task:
|
||||
- Failure:
|
||||
- Root cause:
|
||||
- Recovery action:
|
||||
- Result: success | partial | blocked
|
||||
- Token / time burn risk:
|
||||
- Follow-up needed:
|
||||
- Preventive change to encode later:
|
||||
```
|
||||
|
||||
## Recovery Heuristics
|
||||
|
||||
Prefer these interventions in order:
|
||||
|
||||
1. Restate the real objective in one sentence.
|
||||
2. Verify the world state instead of trusting memory.
|
||||
3. Shrink the failing scope.
|
||||
4. Run one discriminating check.
|
||||
5. Only then retry.
|
||||
|
||||
Bad pattern:
|
||||
- retrying the same action three times with slightly different wording
|
||||
|
||||
Good pattern:
|
||||
- capture failure
|
||||
- classify the pattern
|
||||
- run one direct check
|
||||
- change the plan only if the check supports it
|
||||
|
||||
## Integration with ECC
|
||||
|
||||
- Use `verification-loop` after recovery if code was changed.
|
||||
- Use `continuous-learning-v2` when the failure pattern is worth turning into an instinct or later skill.
|
||||
- Use `council` when the issue is not technical failure but decision ambiguity.
|
||||
- Use `workspace-surface-audit` if the failure came from conflicting local state or repo drift.
|
||||
|
||||
## Output Standard
|
||||
|
||||
When this skill is active, do not end with “I fixed it” alone.
|
||||
|
||||
Always provide:
|
||||
- the failure pattern
|
||||
- the root-cause hypothesis
|
||||
- the recovery action
|
||||
- the evidence that the situation is now better or still blocked
|
||||
@@ -1,7 +0,0 @@
|
||||
interface:
|
||||
display_name: "Agent Introspection Debugging"
|
||||
short_description: "Structured self-debugging for AI agent failures"
|
||||
brand_color: "#0EA5E9"
|
||||
default_prompt: "Use $agent-introspection-debugging to diagnose and recover from an AI agent failure."
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
@@ -1,214 +0,0 @@
|
||||
---
|
||||
name: agent-sort
|
||||
description: Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
|
||||
---
|
||||
|
||||
# Agent Sort
|
||||
|
||||
Use this skill when a repo needs a project-specific ECC surface instead of the default full install.
|
||||
|
||||
The goal is not to guess what "feels useful." The goal is to classify ECC components with evidence from the actual codebase.
|
||||
|
||||
## When to Use
|
||||
|
||||
- A project only needs a subset of ECC and full installs are too noisy
|
||||
- The repo stack is clear, but nobody wants to hand-curate skills one by one
|
||||
- A team wants a repeatable install decision backed by grep evidence instead of opinion
|
||||
- You need to separate always-loaded daily workflow surfaces from searchable library/reference surfaces
|
||||
- A repo has drifted into the wrong language, rule, or hook set and needs cleanup
|
||||
|
||||
## Non-Negotiable Rules
|
||||
|
||||
- Use the current repository as the source of truth, not generic preferences
|
||||
- Every DAILY decision must cite concrete repo evidence
|
||||
- LIBRARY does not mean "delete"; it means "keep accessible without loading by default"
|
||||
- Do not install hooks, rules, or scripts that the current repo cannot use
|
||||
- Prefer ECC-native surfaces; do not introduce a second install system
|
||||
|
||||
## Outputs
|
||||
|
||||
Produce these artifacts in order:
|
||||
|
||||
1. DAILY inventory
|
||||
2. LIBRARY inventory
|
||||
3. install plan
|
||||
4. verification report
|
||||
5. optional `skill-library` router if the project wants one
|
||||
|
||||
## Classification Model
|
||||
|
||||
Use two buckets only:
|
||||
|
||||
- `DAILY`
|
||||
- should load every session for this repo
|
||||
- strongly matched to the repo's language, framework, workflow, or operator surface
|
||||
- `LIBRARY`
|
||||
- useful to retain, but not worth loading by default
|
||||
- should remain reachable through search, router skill, or selective manual use
|
||||
|
||||
## Evidence Sources
|
||||
|
||||
Use repo-local evidence before making any classification:
|
||||
|
||||
- file extensions
|
||||
- package managers and lockfiles
|
||||
- framework configs
|
||||
- CI and hook configs
|
||||
- build/test scripts
|
||||
- imports and dependency manifests
|
||||
- repo docs that explicitly describe the stack
|
||||
|
||||
Useful commands include:
|
||||
|
||||
```bash
|
||||
rg --files
|
||||
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
|
||||
cat package.json
|
||||
cat pyproject.toml
|
||||
cat Cargo.toml
|
||||
cat pubspec.yaml
|
||||
cat go.mod
|
||||
```
|
||||
|
||||
## Parallel Review Passes
|
||||
|
||||
If parallel subagents are available, split the review into these passes:
|
||||
|
||||
1. Agents
|
||||
- classify `agents/*`
|
||||
2. Skills
|
||||
- classify `skills/*`
|
||||
3. Commands
|
||||
- classify `commands/*`
|
||||
4. Rules
|
||||
- classify `rules/*`
|
||||
5. Hooks and scripts
|
||||
- classify hook surfaces, MCP health checks, helper scripts, and OS compatibility
|
||||
6. Extras
|
||||
- classify contexts, examples, MCP configs, templates, and guidance docs
|
||||
|
||||
If subagents are not available, run the same passes sequentially.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
### 1. Read the repo
|
||||
|
||||
Establish the real stack before classifying anything:
|
||||
|
||||
- languages in use
|
||||
- frameworks in use
|
||||
- primary package manager
|
||||
- test stack
|
||||
- lint/format stack
|
||||
- deployment/runtime surface
|
||||
- operator integrations already present
|
||||
|
||||
### 2. Build the evidence table
|
||||
|
||||
For every candidate surface, record:
|
||||
|
||||
- component path
|
||||
- component type
|
||||
- proposed bucket
|
||||
- repo evidence
|
||||
- short justification
|
||||
|
||||
Use this format:
|
||||
|
||||
```text
|
||||
skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack
|
||||
skills/django-patterns | skill | LIBRARY | no .py files, no pyproject.toml | not active in this repo
|
||||
rules/typescript/* | rules | DAILY | package.json + tsconfig.json | active TS repo
|
||||
rules/python/* | rules | LIBRARY | zero Python source files | keep accessible only
|
||||
```
|
||||
|
||||
### 3. Decide DAILY vs LIBRARY
|
||||
|
||||
Promote to `DAILY` when:
|
||||
|
||||
- the repo clearly uses the matching stack
|
||||
- the component is general enough to help every session
|
||||
- the repo already depends on the corresponding runtime or workflow
|
||||
|
||||
Demote to `LIBRARY` when:
|
||||
|
||||
- the component is off-stack
|
||||
- the repo might need it later, but not every day
|
||||
- it adds context overhead without immediate relevance
|
||||
|
||||
### 4. Build the install plan
|
||||
|
||||
Translate the classification into action:
|
||||
|
||||
- DAILY skills -> install or keep in `.claude/skills/`
|
||||
- DAILY commands -> keep as explicit shims only if still useful
|
||||
- DAILY rules -> install only matching language sets
|
||||
- DAILY hooks/scripts -> keep only compatible ones
|
||||
- LIBRARY surfaces -> keep accessible through search or `skill-library`
|
||||
|
||||
If the repo already uses selective installs, update that plan instead of creating another system.
|
||||
|
||||
### 5. Create the optional library router
|
||||
|
||||
If the project wants a searchable library surface, create:
|
||||
|
||||
- `.claude/skills/skill-library/SKILL.md`
|
||||
|
||||
That router should contain:
|
||||
|
||||
- a short explanation of DAILY vs LIBRARY
|
||||
- grouped trigger keywords
|
||||
- where the library references live
|
||||
|
||||
Do not duplicate every skill body inside the router.
|
||||
|
||||
### 6. Verify the result
|
||||
|
||||
After the plan is applied, verify:
|
||||
|
||||
- every DAILY file exists where expected
|
||||
- stale language rules were not left active
|
||||
- incompatible hooks were not installed
|
||||
- the resulting install actually matches the repo stack
|
||||
|
||||
Return a compact report with:
|
||||
|
||||
- DAILY count
|
||||
- LIBRARY count
|
||||
- removed stale surfaces
|
||||
- open questions
|
||||
|
||||
## Handoffs
|
||||
|
||||
If the next step is interactive installation or repair, hand off to:
|
||||
|
||||
- `configure-ecc`
|
||||
|
||||
If the next step is overlap cleanup or catalog review, hand off to:
|
||||
|
||||
- `skill-stocktake`
|
||||
|
||||
If the next step is broader context trimming, hand off to:
|
||||
|
||||
- `strategic-compact`
|
||||
|
||||
## Output Format
|
||||
|
||||
Return the result in this order:
|
||||
|
||||
```text
|
||||
STACK
|
||||
- language/framework/runtime summary
|
||||
|
||||
DAILY
|
||||
- always-loaded items with evidence
|
||||
|
||||
LIBRARY
|
||||
- searchable/reference items with evidence
|
||||
|
||||
INSTALL PLAN
|
||||
- what should be installed, removed, or routed
|
||||
|
||||
VERIFICATION
|
||||
- checks run and remaining gaps
|
||||
```
|
||||
@@ -1,7 +0,0 @@
|
||||
interface:
|
||||
display_name: "Agent Sort"
|
||||
short_description: "Evidence-backed ECC install planning"
|
||||
brand_color: "#0EA5E9"
|
||||
default_prompt: "Use $agent-sort to build an evidence-backed ECC install plan."
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: api-design
|
||||
description: REST API design patterns including resource naming, status codes, pagination, filtering, error responses, versioning, and rate limiting for production APIs.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# API Design Patterns
|
||||
|
||||
@@ -2,6 +2,6 @@ interface:
|
||||
display_name: "API Design"
|
||||
short_description: "REST API design patterns and best practices"
|
||||
brand_color: "#F97316"
|
||||
default_prompt: "Use $api-design to design production REST API resources and responses."
|
||||
default_prompt: "Design REST API: resources, status codes, pagination"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: article-writing
|
||||
description: Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Article Writing
|
||||
@@ -22,23 +23,50 @@ 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 Handling
|
||||
## Voice Capture Workflow
|
||||
|
||||
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 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 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
|
||||
|
||||
@@ -73,6 +101,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 or the agreed `VOICE PROFILE`
|
||||
- the voice matches the supplied examples
|
||||
- every section adds something new
|
||||
- formatting matches the intended medium
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Article Writing"
|
||||
short_description: "Long-form content in a supplied voice"
|
||||
short_description: "Write long-form content in a supplied voice without sounding templated"
|
||||
brand_color: "#B45309"
|
||||
default_prompt: "Use $article-writing to draft polished long-form content in the supplied voice."
|
||||
default_prompt: "Draft a sharp long-form article from these notes and examples"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: backend-patterns
|
||||
description: Backend architecture patterns, API design, database optimization, and server-side best practices for Node.js, Express, and Next.js API routes.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Backend Development Patterns
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Backend Patterns"
|
||||
short_description: "API, database, and server-side patterns"
|
||||
short_description: "API design, database, and server-side patterns"
|
||||
brand_color: "#F59E0B"
|
||||
default_prompt: "Use $backend-patterns to apply backend architecture and API patterns."
|
||||
default_prompt: "Apply backend patterns: API design, repository, caching"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: brand-voice
|
||||
description: Build a source-derived writing style profile from real posts, essays, launch notes, docs, or site copy, then reuse that profile across content, outreach, and social workflows. Use when the user wants voice consistency without generic AI writing tropes.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Brand Voice
|
||||
|
||||
@@ -1,7 +0,0 @@
|
||||
interface:
|
||||
display_name: "Brand Voice"
|
||||
short_description: "Source-derived writing style profiles"
|
||||
brand_color: "#0EA5E9"
|
||||
default_prompt: "Use $brand-voice to derive and reuse a source-grounded writing style."
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: bun-runtime
|
||||
description: Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Bun Runtime
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Bun Runtime"
|
||||
short_description: "Bun runtime, package manager, and test runner"
|
||||
short_description: "Bun as runtime, package manager, bundler, and test runner"
|
||||
brand_color: "#FBF0DF"
|
||||
default_prompt: "Use $bun-runtime to choose and apply Bun runtime workflows."
|
||||
default_prompt: "Use Bun for scripts, install, or run"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
337
.agents/skills/claude-api/SKILL.md
Normal file
337
.agents/skills/claude-api/SKILL.md
Normal file
@@ -0,0 +1,337 @@
|
||||
---
|
||||
name: claude-api
|
||||
description: Anthropic Claude API patterns for Python and TypeScript. Covers Messages API, streaming, tool use, vision, extended thinking, batches, prompt caching, and Claude Agent SDK. Use when building applications with the Claude API or Anthropic SDKs.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Claude API
|
||||
|
||||
Build applications with the Anthropic Claude API and SDKs.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- Building applications that call the Claude API
|
||||
- Code imports `anthropic` (Python) or `@anthropic-ai/sdk` (TypeScript)
|
||||
- User asks about Claude API patterns, tool use, streaming, or vision
|
||||
- Implementing agent workflows with Claude Agent SDK
|
||||
- Optimizing API costs, token usage, or latency
|
||||
|
||||
## Model Selection
|
||||
|
||||
| Model | ID | Best For |
|
||||
|-------|-----|----------|
|
||||
| Opus 4.6 | `claude-opus-4-6` | Complex reasoning, architecture, research |
|
||||
| Sonnet 4.6 | `claude-sonnet-4-6` | Balanced coding, most development tasks |
|
||||
| Haiku 4.5 | `claude-haiku-4-5-20251001` | Fast responses, high-volume, cost-sensitive |
|
||||
|
||||
Default to Sonnet 4.6 unless the task requires deep reasoning (Opus) or speed/cost optimization (Haiku).
|
||||
|
||||
## Python SDK
|
||||
|
||||
### Installation
|
||||
|
||||
```bash
|
||||
pip install anthropic
|
||||
```
|
||||
|
||||
### Basic Message
|
||||
|
||||
```python
|
||||
import anthropic
|
||||
|
||||
client = anthropic.Anthropic() # reads ANTHROPIC_API_KEY from env
|
||||
|
||||
message = client.messages.create(
|
||||
model="claude-sonnet-4-6",
|
||||
max_tokens=1024,
|
||||
messages=[
|
||||
{"role": "user", "content": "Explain async/await in Python"}
|
||||
]
|
||||
)
|
||||
print(message.content[0].text)
|
||||
```
|
||||
|
||||
### Streaming
|
||||
|
||||
```python
|
||||
with client.messages.stream(
|
||||
model="claude-sonnet-4-6",
|
||||
max_tokens=1024,
|
||||
messages=[{"role": "user", "content": "Write a haiku about coding"}]
|
||||
) as stream:
|
||||
for text in stream.text_stream:
|
||||
print(text, end="", flush=True)
|
||||
```
|
||||
|
||||
### System Prompt
|
||||
|
||||
```python
|
||||
message = client.messages.create(
|
||||
model="claude-sonnet-4-6",
|
||||
max_tokens=1024,
|
||||
system="You are a senior Python developer. Be concise.",
|
||||
messages=[{"role": "user", "content": "Review this function"}]
|
||||
)
|
||||
```
|
||||
|
||||
## TypeScript SDK
|
||||
|
||||
### Installation
|
||||
|
||||
```bash
|
||||
npm install @anthropic-ai/sdk
|
||||
```
|
||||
|
||||
### Basic Message
|
||||
|
||||
```typescript
|
||||
import Anthropic from "@anthropic-ai/sdk";
|
||||
|
||||
const client = new Anthropic(); // reads ANTHROPIC_API_KEY from env
|
||||
|
||||
const message = await client.messages.create({
|
||||
model: "claude-sonnet-4-6",
|
||||
max_tokens: 1024,
|
||||
messages: [
|
||||
{ role: "user", content: "Explain async/await in TypeScript" }
|
||||
],
|
||||
});
|
||||
console.log(message.content[0].text);
|
||||
```
|
||||
|
||||
### Streaming
|
||||
|
||||
```typescript
|
||||
const stream = client.messages.stream({
|
||||
model: "claude-sonnet-4-6",
|
||||
max_tokens: 1024,
|
||||
messages: [{ role: "user", content: "Write a haiku" }],
|
||||
});
|
||||
|
||||
for await (const event of stream) {
|
||||
if (event.type === "content_block_delta" && event.delta.type === "text_delta") {
|
||||
process.stdout.write(event.delta.text);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Tool Use
|
||||
|
||||
Define tools and let Claude call them:
|
||||
|
||||
```python
|
||||
tools = [
|
||||
{
|
||||
"name": "get_weather",
|
||||
"description": "Get current weather for a location",
|
||||
"input_schema": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"location": {"type": "string", "description": "City name"},
|
||||
"unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
|
||||
},
|
||||
"required": ["location"]
|
||||
}
|
||||
}
|
||||
]
|
||||
|
||||
message = client.messages.create(
|
||||
model="claude-sonnet-4-6",
|
||||
max_tokens=1024,
|
||||
tools=tools,
|
||||
messages=[{"role": "user", "content": "What's the weather in SF?"}]
|
||||
)
|
||||
|
||||
# Handle tool use response
|
||||
for block in message.content:
|
||||
if block.type == "tool_use":
|
||||
# Execute the tool with block.input
|
||||
result = get_weather(**block.input)
|
||||
# Send result back
|
||||
follow_up = client.messages.create(
|
||||
model="claude-sonnet-4-6",
|
||||
max_tokens=1024,
|
||||
tools=tools,
|
||||
messages=[
|
||||
{"role": "user", "content": "What's the weather in SF?"},
|
||||
{"role": "assistant", "content": message.content},
|
||||
{"role": "user", "content": [
|
||||
{"type": "tool_result", "tool_use_id": block.id, "content": str(result)}
|
||||
]}
|
||||
]
|
||||
)
|
||||
```
|
||||
|
||||
## Vision
|
||||
|
||||
Send images for analysis:
|
||||
|
||||
```python
|
||||
import base64
|
||||
|
||||
with open("diagram.png", "rb") as f:
|
||||
image_data = base64.standard_b64encode(f.read()).decode("utf-8")
|
||||
|
||||
message = client.messages.create(
|
||||
model="claude-sonnet-4-6",
|
||||
max_tokens=1024,
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": image_data}},
|
||||
{"type": "text", "text": "Describe this diagram"}
|
||||
]
|
||||
}]
|
||||
)
|
||||
```
|
||||
|
||||
## Extended Thinking
|
||||
|
||||
For complex reasoning tasks:
|
||||
|
||||
```python
|
||||
message = client.messages.create(
|
||||
model="claude-sonnet-4-6",
|
||||
max_tokens=16000,
|
||||
thinking={
|
||||
"type": "enabled",
|
||||
"budget_tokens": 10000
|
||||
},
|
||||
messages=[{"role": "user", "content": "Solve this math problem step by step..."}]
|
||||
)
|
||||
|
||||
for block in message.content:
|
||||
if block.type == "thinking":
|
||||
print(f"Thinking: {block.thinking}")
|
||||
elif block.type == "text":
|
||||
print(f"Answer: {block.text}")
|
||||
```
|
||||
|
||||
## Prompt Caching
|
||||
|
||||
Cache large system prompts or context to reduce costs:
|
||||
|
||||
```python
|
||||
message = client.messages.create(
|
||||
model="claude-sonnet-4-6",
|
||||
max_tokens=1024,
|
||||
system=[
|
||||
{"type": "text", "text": large_system_prompt, "cache_control": {"type": "ephemeral"}}
|
||||
],
|
||||
messages=[{"role": "user", "content": "Question about the cached context"}]
|
||||
)
|
||||
# Check cache usage
|
||||
print(f"Cache read: {message.usage.cache_read_input_tokens}")
|
||||
print(f"Cache creation: {message.usage.cache_creation_input_tokens}")
|
||||
```
|
||||
|
||||
## Batches API
|
||||
|
||||
Process large volumes asynchronously at 50% cost reduction:
|
||||
|
||||
```python
|
||||
import time
|
||||
|
||||
batch = client.messages.batches.create(
|
||||
requests=[
|
||||
{
|
||||
"custom_id": f"request-{i}",
|
||||
"params": {
|
||||
"model": "claude-sonnet-4-6",
|
||||
"max_tokens": 1024,
|
||||
"messages": [{"role": "user", "content": prompt}]
|
||||
}
|
||||
}
|
||||
for i, prompt in enumerate(prompts)
|
||||
]
|
||||
)
|
||||
|
||||
# Poll for completion
|
||||
while True:
|
||||
status = client.messages.batches.retrieve(batch.id)
|
||||
if status.processing_status == "ended":
|
||||
break
|
||||
time.sleep(30)
|
||||
|
||||
# Get results
|
||||
for result in client.messages.batches.results(batch.id):
|
||||
print(result.result.message.content[0].text)
|
||||
```
|
||||
|
||||
## Claude Agent SDK
|
||||
|
||||
Build multi-step agents:
|
||||
|
||||
```python
|
||||
# Note: Agent SDK API surface may change — check official docs
|
||||
import anthropic
|
||||
|
||||
# Define tools as functions
|
||||
tools = [{
|
||||
"name": "search_codebase",
|
||||
"description": "Search the codebase for relevant code",
|
||||
"input_schema": {
|
||||
"type": "object",
|
||||
"properties": {"query": {"type": "string"}},
|
||||
"required": ["query"]
|
||||
}
|
||||
}]
|
||||
|
||||
# Run an agentic loop with tool use
|
||||
client = anthropic.Anthropic()
|
||||
messages = [{"role": "user", "content": "Review the auth module for security issues"}]
|
||||
|
||||
while True:
|
||||
response = client.messages.create(
|
||||
model="claude-sonnet-4-6",
|
||||
max_tokens=4096,
|
||||
tools=tools,
|
||||
messages=messages,
|
||||
)
|
||||
if response.stop_reason == "end_turn":
|
||||
break
|
||||
# Handle tool calls and continue the loop
|
||||
messages.append({"role": "assistant", "content": response.content})
|
||||
# ... execute tools and append tool_result messages
|
||||
```
|
||||
|
||||
## Cost Optimization
|
||||
|
||||
| Strategy | Savings | When to Use |
|
||||
|----------|---------|-------------|
|
||||
| Prompt caching | Up to 90% on cached tokens | Repeated system prompts or context |
|
||||
| Batches API | 50% | Non-time-sensitive bulk processing |
|
||||
| Haiku instead of Sonnet | ~75% | Simple tasks, classification, extraction |
|
||||
| Shorter max_tokens | Variable | When you know output will be short |
|
||||
| Streaming | None (same cost) | Better UX, same price |
|
||||
|
||||
## Error Handling
|
||||
|
||||
```python
|
||||
import time
|
||||
|
||||
from anthropic import APIError, RateLimitError, APIConnectionError
|
||||
|
||||
try:
|
||||
message = client.messages.create(...)
|
||||
except RateLimitError:
|
||||
# Back off and retry
|
||||
time.sleep(60)
|
||||
except APIConnectionError:
|
||||
# Network issue, retry with backoff
|
||||
pass
|
||||
except APIError as e:
|
||||
print(f"API error {e.status_code}: {e.message}")
|
||||
```
|
||||
|
||||
## Environment Setup
|
||||
|
||||
```bash
|
||||
# Required
|
||||
export ANTHROPIC_API_KEY="your-api-key-here"
|
||||
|
||||
# Optional: set default model
|
||||
export ANTHROPIC_MODEL="claude-sonnet-4-6"
|
||||
```
|
||||
|
||||
Never hardcode API keys. Always use environment variables.
|
||||
7
.agents/skills/claude-api/agents/openai.yaml
Normal file
7
.agents/skills/claude-api/agents/openai.yaml
Normal file
@@ -0,0 +1,7 @@
|
||||
interface:
|
||||
display_name: "Claude API"
|
||||
short_description: "Anthropic Claude API patterns and SDKs"
|
||||
brand_color: "#D97706"
|
||||
default_prompt: "Build applications with the Claude API using Messages, tool use, streaming, and Agent SDK"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
@@ -1,17 +1,12 @@
|
||||
---
|
||||
name: coding-standards
|
||||
description: Baseline cross-project coding conventions for naming, readability, immutability, and code-quality review. Use detailed frontend or backend skills for framework-specific patterns.
|
||||
description: Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Coding Standards & Best Practices
|
||||
|
||||
Baseline coding conventions applicable across projects.
|
||||
|
||||
This skill is the shared floor, not the detailed framework playbook.
|
||||
|
||||
- Use `frontend-patterns` for React, state, forms, rendering, and UI architecture.
|
||||
- Use `backend-patterns` or `api-design` for repository/service layers, endpoint design, validation, and server-specific concerns.
|
||||
- Use `rules/common/coding-style.md` when you need the shortest reusable rule layer instead of a full skill walkthrough.
|
||||
Universal coding standards applicable across all projects.
|
||||
|
||||
## When to Activate
|
||||
|
||||
@@ -22,19 +17,6 @@ This skill is the shared floor, not the detailed framework playbook.
|
||||
- Setting up linting, formatting, or type-checking rules
|
||||
- Onboarding new contributors to coding conventions
|
||||
|
||||
## Scope Boundaries
|
||||
|
||||
Activate this skill for:
|
||||
- descriptive naming
|
||||
- immutability defaults
|
||||
- readability, KISS, DRY, and YAGNI enforcement
|
||||
- error-handling expectations and code-smell review
|
||||
|
||||
Do not use this skill as the primary source for:
|
||||
- React composition, hooks, or rendering patterns
|
||||
- backend architecture, API design, or database layering
|
||||
- domain-specific framework guidance when a narrower ECC skill already exists
|
||||
|
||||
## Code Quality Principles
|
||||
|
||||
### 1. Readability First
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Coding Standards"
|
||||
short_description: "Cross-project coding conventions and review"
|
||||
short_description: "Universal coding standards and best practices"
|
||||
brand_color: "#3B82F6"
|
||||
default_prompt: "Use $coding-standards to review code against cross-project standards."
|
||||
default_prompt: "Apply standards: immutability, error handling, type safety"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: content-engine
|
||||
description: Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Content Engine
|
||||
@@ -37,28 +38,50 @@ 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 Handling
|
||||
## Voice Capture Workflow
|
||||
|
||||
`brand-voice` is the canonical voice layer.
|
||||
|
||||
Run it first when:
|
||||
Run `brand-voice` first when:
|
||||
|
||||
- there are multiple downstream outputs
|
||||
- the user explicitly cares about writing style
|
||||
- the content is launch, outreach, or reputation-sensitive
|
||||
|
||||
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.
|
||||
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
|
||||
|
||||
## 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
|
||||
- fake engagement padding that was not present in the source material
|
||||
- parenthetical jokes that were not present in the source voice
|
||||
|
||||
## Platform Adaptation Rules
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Content Engine"
|
||||
short_description: "Platform-native content systems and campaigns"
|
||||
short_description: "Turn one idea into platform-native social and content outputs"
|
||||
brand_color: "#DC2626"
|
||||
default_prompt: "Use $content-engine to turn source material into platform-native content."
|
||||
default_prompt: "Turn this source asset into strong multi-platform content"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: crosspost
|
||||
description: Multi-platform content distribution across X, LinkedIn, Threads, and Bluesky. Adapts content per platform using content-engine patterns. Never posts identical content cross-platform. Use when the user wants to distribute content across social platforms.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Crosspost
|
||||
@@ -38,8 +39,13 @@ 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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
### Step 3: Adapt by Platform Constraint
|
||||
|
||||
@@ -85,6 +91,7 @@ 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,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Crosspost"
|
||||
short_description: "Multi-platform social distribution"
|
||||
short_description: "Multi-platform content distribution with native adaptation"
|
||||
brand_color: "#EC4899"
|
||||
default_prompt: "Use $crosspost to adapt content for multiple social platforms."
|
||||
default_prompt: "Distribute content across X, LinkedIn, Threads, and Bluesky with platform-native adaptation"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: deep-research
|
||||
description: Multi-source deep research using firecrawl and exa MCPs. Searches the web, synthesizes findings, and delivers cited reports with source attribution. Use when the user wants thorough research on any topic with evidence and citations.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Deep Research
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Deep Research"
|
||||
short_description: "Multi-source cited research reports"
|
||||
short_description: "Multi-source deep research with firecrawl and exa MCPs"
|
||||
brand_color: "#6366F1"
|
||||
default_prompt: "Use $deep-research to produce a cited multi-source research report."
|
||||
default_prompt: "Research the given topic using firecrawl and exa, produce a cited report"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: dmux-workflows
|
||||
description: Multi-agent orchestration using dmux (tmux pane manager for AI agents). Patterns for parallel agent workflows across Claude Code, Codex, OpenCode, and other harnesses. Use when running multiple agent sessions in parallel or coordinating multi-agent development workflows.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# dmux Workflows
|
||||
|
||||
@@ -2,6 +2,6 @@ interface:
|
||||
display_name: "dmux Workflows"
|
||||
short_description: "Multi-agent orchestration with dmux"
|
||||
brand_color: "#14B8A6"
|
||||
default_prompt: "Use $dmux-workflows to orchestrate parallel agent sessions with dmux."
|
||||
default_prompt: "Orchestrate parallel agent sessions using dmux pane manager"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: documentation-lookup
|
||||
description: Use up-to-date library and framework docs via Context7 MCP instead of training data. Activates for setup questions, API references, code examples, or when the user names a framework (e.g. React, Next.js, Prisma).
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Documentation Lookup (Context7)
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Documentation Lookup"
|
||||
short_description: "Current library docs via Context7"
|
||||
short_description: "Fetch up-to-date library docs via Context7 MCP"
|
||||
brand_color: "#6366F1"
|
||||
default_prompt: "Use $documentation-lookup to fetch current library documentation via Context7."
|
||||
default_prompt: "Look up docs for a library or API"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: e2e-testing
|
||||
description: Playwright E2E testing patterns, Page Object Model, configuration, CI/CD integration, artifact management, and flaky test strategies.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# E2E Testing Patterns
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "E2E Testing"
|
||||
short_description: "Playwright E2E testing patterns"
|
||||
short_description: "Playwright end-to-end testing"
|
||||
brand_color: "#06B6D4"
|
||||
default_prompt: "Use $e2e-testing to design Playwright end-to-end test coverage."
|
||||
default_prompt: "Generate Playwright E2E tests with Page Object Model"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,7 +1,8 @@
|
||||
---
|
||||
name: eval-harness
|
||||
description: Formal evaluation framework for Claude Code sessions implementing eval-driven development (EDD) principles
|
||||
allowed-tools: Read, Write, Edit, Bash, Grep, Glob
|
||||
origin: ECC
|
||||
tools: Read, Write, Edit, Bash, Grep, Glob
|
||||
---
|
||||
|
||||
# Eval Harness Skill
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Eval Harness"
|
||||
short_description: "Eval-driven development harnesses"
|
||||
short_description: "Eval-driven development with pass/fail criteria"
|
||||
brand_color: "#EC4899"
|
||||
default_prompt: "Use $eval-harness to define eval-driven development checks."
|
||||
default_prompt: "Set up eval-driven development with pass/fail criteria"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: everything-claude-code
|
||||
name: everything-claude-code-conventions
|
||||
description: Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.
|
||||
---
|
||||
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
interface:
|
||||
display_name: "Everything Claude Code"
|
||||
short_description: "Repo workflows for everything-claude-code"
|
||||
brand_color: "#0EA5E9"
|
||||
default_prompt: "Use $everything-claude-code to follow this repository's conventions and workflows."
|
||||
short_description: "Repo-specific patterns and workflows for everything-claude-code"
|
||||
default_prompt: "Use the everything-claude-code repo skill to follow existing architecture, testing, and workflow conventions."
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
allow_implicit_invocation: true
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: exa-search
|
||||
description: Neural search via Exa MCP for web, code, and company research. Use when the user needs web search, code examples, company intel, people lookup, or AI-powered deep research with Exa's neural search engine.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Exa Search
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Exa Search"
|
||||
short_description: "Neural search via Exa MCP"
|
||||
short_description: "Neural search via Exa MCP for web, code, and companies"
|
||||
brand_color: "#8B5CF6"
|
||||
default_prompt: "Use $exa-search to search web, code, or company data through Exa."
|
||||
default_prompt: "Search using Exa MCP tools for web content, code, or company research"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: fal-ai-media
|
||||
description: Unified media generation via fal.ai MCP — image, video, and audio. Covers text-to-image (Nano Banana), text/image-to-video (Seedance, Kling, Veo 3), text-to-speech (CSM-1B), and video-to-audio (ThinkSound). Use when the user wants to generate images, videos, or audio with AI.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# fal.ai Media Generation
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "fal.ai Media"
|
||||
short_description: "AI media generation via fal.ai"
|
||||
short_description: "AI image, video, and audio generation via fal.ai"
|
||||
brand_color: "#F43F5E"
|
||||
default_prompt: "Use $fal-ai-media to generate image, video, or audio assets with fal.ai."
|
||||
default_prompt: "Generate images, videos, or audio using fal.ai models"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: frontend-patterns
|
||||
description: Frontend development patterns for React, Next.js, state management, performance optimization, and UI best practices.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Frontend Development Patterns
|
||||
@@ -17,12 +18,6 @@ Modern frontend patterns for React, Next.js, and performant user interfaces.
|
||||
- Handling client-side routing and navigation
|
||||
- Building accessible, responsive UI patterns
|
||||
|
||||
## Privacy and Data Boundaries
|
||||
|
||||
Frontend examples should use synthetic or domain-generic data. Do not collect, log, persist, or display credentials, access tokens, SSNs, health data, payment details, private emails, phone numbers, or other sensitive personal data unless the user explicitly requests a scoped implementation with appropriate validation, redaction, and access controls.
|
||||
|
||||
Avoid adding analytics, tracking pixels, third-party scripts, or external data sinks without explicit approval. When handling user data, prefer least-privilege APIs, client-side redaction before logging, and server-side validation for every boundary.
|
||||
|
||||
## Component Patterns
|
||||
|
||||
### Composition Over Inheritance
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Frontend Patterns"
|
||||
short_description: "React and Next.js frontend patterns"
|
||||
short_description: "React and Next.js patterns and best practices"
|
||||
brand_color: "#8B5CF6"
|
||||
default_prompt: "Use $frontend-patterns to apply React and Next.js frontend patterns."
|
||||
default_prompt: "Apply React/Next.js patterns and best practices"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: frontend-slides
|
||||
description: Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Frontend Slides
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Frontend Slides"
|
||||
short_description: "Animation-rich HTML presentation decks"
|
||||
short_description: "Create distinctive HTML slide decks and convert PPTX to web"
|
||||
brand_color: "#FF6B3D"
|
||||
default_prompt: "Use $frontend-slides to create an animation-rich HTML presentation deck."
|
||||
default_prompt: "Create a viewport-safe HTML presentation with strong visual direction"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: investor-materials
|
||||
description: Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Investor Materials
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Investor Materials"
|
||||
short_description: "Investor decks, memos, and financial materials"
|
||||
short_description: "Create decks, memos, and financial materials from one source of truth"
|
||||
brand_color: "#7C3AED"
|
||||
default_prompt: "Use $investor-materials to draft consistent investor-facing fundraising assets."
|
||||
default_prompt: "Draft investor materials that stay numerically consistent across assets"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: investor-outreach
|
||||
description: Draft cold emails, warm intro blurbs, follow-ups, update emails, and investor communications for fundraising. Use when the user wants outreach to angels, VCs, strategic investors, or accelerators and needs concise, personalized, investor-facing messaging.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Investor Outreach
|
||||
@@ -23,11 +24,6 @@ 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:
|
||||
@@ -35,6 +31,7 @@ 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,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Investor Outreach"
|
||||
short_description: "Personalized investor outreach and follow-ups"
|
||||
short_description: "Write concise, personalized outreach and follow-ups for fundraising"
|
||||
brand_color: "#059669"
|
||||
default_prompt: "Use $investor-outreach to write concise personalized investor outreach."
|
||||
default_prompt: "Draft a personalized investor outreach email with a clear low-friction ask"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: market-research
|
||||
description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Market Research
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Market Research"
|
||||
short_description: "Source-attributed market research"
|
||||
short_description: "Source-attributed market, competitor, and investor research"
|
||||
brand_color: "#2563EB"
|
||||
default_prompt: "Use $market-research to research markets with source-attributed findings."
|
||||
default_prompt: "Research this market and summarize the decision-relevant findings"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: mcp-server-patterns
|
||||
description: Build MCP servers with Node/TypeScript SDK — tools, resources, prompts, Zod validation, stdio vs Streamable HTTP. Use Context7 or official MCP docs for latest API.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# MCP Server Patterns
|
||||
|
||||
@@ -1,7 +0,0 @@
|
||||
interface:
|
||||
display_name: "MCP Server Patterns"
|
||||
short_description: "MCP server tools, resources, and prompts"
|
||||
brand_color: "#0EA5E9"
|
||||
default_prompt: "Use $mcp-server-patterns to build MCP tools, resources, and prompts."
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: nextjs-turbopack
|
||||
description: Next.js 16+ and Turbopack — incremental bundling, FS caching, dev speed, and when to use Turbopack vs webpack.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Next.js and Turbopack
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Next.js Turbopack"
|
||||
short_description: "Next.js and Turbopack workflow guidance"
|
||||
short_description: "Next.js 16+ and Turbopack dev bundler"
|
||||
brand_color: "#000000"
|
||||
default_prompt: "Use $nextjs-turbopack to work through Next.js and Turbopack decisions."
|
||||
default_prompt: "Next.js dev, Turbopack, or bundle optimization"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,140 +0,0 @@
|
||||
---
|
||||
name: product-capability
|
||||
description: Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.
|
||||
---
|
||||
|
||||
# Product Capability
|
||||
|
||||
This skill turns product intent into explicit engineering constraints.
|
||||
|
||||
Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"
|
||||
|
||||
## When to Use
|
||||
|
||||
- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
|
||||
- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
|
||||
- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
|
||||
- Senior engineers keep restating the same hidden assumptions during review
|
||||
- You need a reusable artifact that can survive across harnesses and sessions
|
||||
|
||||
## Canonical Artifact
|
||||
|
||||
If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.
|
||||
|
||||
If no capability manifest exists yet, create one using the template at:
|
||||
|
||||
- `docs/examples/product-capability-template.md`
|
||||
|
||||
The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.
|
||||
|
||||
## Non-Negotiable Rules
|
||||
|
||||
- Do not invent product truth. Mark unresolved questions explicitly.
|
||||
- Separate user-visible promises from implementation details.
|
||||
- Call out what is fixed policy, what is architecture preference, and what is still open.
|
||||
- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
|
||||
- Prefer one reusable capability artifact over scattered ad hoc notes.
|
||||
|
||||
## Inputs
|
||||
|
||||
Read only what is needed:
|
||||
|
||||
1. Product intent
|
||||
- issue, discussion, PRD, roadmap note, founder message
|
||||
2. Current architecture
|
||||
- relevant repo docs, contracts, schemas, routes, existing workflows
|
||||
3. Existing capability context
|
||||
- `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
|
||||
4. Delivery constraints
|
||||
- auth, billing, compliance, rollout, backwards compatibility, performance, review policy
|
||||
|
||||
## Core Workflow
|
||||
|
||||
### 1. Restate the capability
|
||||
|
||||
Compress the ask into one precise statement:
|
||||
|
||||
- who the user or operator is
|
||||
- what new capability exists after this ships
|
||||
- what outcome changes because of it
|
||||
|
||||
If this statement is weak, the implementation will drift.
|
||||
|
||||
### 2. Resolve capability constraints
|
||||
|
||||
Extract the constraints that must hold before implementation:
|
||||
|
||||
- business rules
|
||||
- scope boundaries
|
||||
- invariants
|
||||
- trust boundaries
|
||||
- data ownership
|
||||
- lifecycle transitions
|
||||
- rollout / migration requirements
|
||||
- failure and recovery expectations
|
||||
|
||||
These are the things that often live only in senior-engineer memory.
|
||||
|
||||
### 3. Define the implementation-facing contract
|
||||
|
||||
Produce an SRS-style capability plan with:
|
||||
|
||||
- capability summary
|
||||
- explicit non-goals
|
||||
- actors and surfaces
|
||||
- required states and transitions
|
||||
- interfaces / inputs / outputs
|
||||
- data model implications
|
||||
- security / billing / policy constraints
|
||||
- observability and operator requirements
|
||||
- open questions blocking implementation
|
||||
|
||||
### 4. Translate into execution
|
||||
|
||||
End with the exact handoff:
|
||||
|
||||
- ready for direct implementation
|
||||
- needs architecture review first
|
||||
- needs product clarification first
|
||||
|
||||
If useful, point to the next ECC-native lane:
|
||||
|
||||
- `project-flow-ops`
|
||||
- `workspace-surface-audit`
|
||||
- `api-connector-builder`
|
||||
- `dashboard-builder`
|
||||
- `tdd-workflow`
|
||||
- `verification-loop`
|
||||
|
||||
## Output Format
|
||||
|
||||
Return the result in this order:
|
||||
|
||||
```text
|
||||
CAPABILITY
|
||||
- one-paragraph restatement
|
||||
|
||||
CONSTRAINTS
|
||||
- fixed rules, invariants, and boundaries
|
||||
|
||||
IMPLEMENTATION CONTRACT
|
||||
- actors
|
||||
- surfaces
|
||||
- states and transitions
|
||||
- interface/data implications
|
||||
|
||||
NON-GOALS
|
||||
- what this lane explicitly does not own
|
||||
|
||||
OPEN QUESTIONS
|
||||
- blockers or product decisions still required
|
||||
|
||||
HANDOFF
|
||||
- what should happen next and which ECC lane should take it
|
||||
```
|
||||
|
||||
## Good Outcomes
|
||||
|
||||
- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
|
||||
- Engineering review has a durable artifact instead of relying on memory or Slack context.
|
||||
- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.
|
||||
@@ -1,7 +0,0 @@
|
||||
interface:
|
||||
display_name: "Product Capability"
|
||||
short_description: "Implementation-ready product capability plans"
|
||||
brand_color: "#0EA5E9"
|
||||
default_prompt: "Use $product-capability to turn product intent into an implementation plan."
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: security-review
|
||||
description: Use this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. Provides comprehensive security checklist and patterns.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Security Review Skill
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Security Review"
|
||||
short_description: "Security checklist and vulnerability review"
|
||||
short_description: "Comprehensive security checklist and vulnerability detection"
|
||||
brand_color: "#EF4444"
|
||||
default_prompt: "Use $security-review to review sensitive code with the security checklist."
|
||||
default_prompt: "Run security checklist: secrets, input validation, injection prevention"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: strategic-compact
|
||||
description: Suggests manual context compaction at logical intervals to preserve context through task phases rather than arbitrary auto-compaction.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Strategic Compact Skill
|
||||
|
||||
@@ -2,6 +2,6 @@ interface:
|
||||
display_name: "Strategic Compact"
|
||||
short_description: "Context management via strategic compaction"
|
||||
brand_color: "#14B8A6"
|
||||
default_prompt: "Use $strategic-compact to choose a useful context compaction boundary."
|
||||
default_prompt: "Suggest task boundary compaction for context management"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: tdd-workflow
|
||||
description: Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Test-Driven Development Workflow
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "TDD Workflow"
|
||||
short_description: "Test-driven development with coverage gates"
|
||||
short_description: "Test-driven development with 80%+ coverage"
|
||||
brand_color: "#22C55E"
|
||||
default_prompt: "Use $tdd-workflow to drive the change with tests before implementation."
|
||||
default_prompt: "Follow TDD: write tests first, implement, verify 80%+ coverage"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: verification-loop
|
||||
description: "A comprehensive verification system for Claude Code sessions."
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Verification Loop Skill
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Verification Loop"
|
||||
short_description: "Build, test, lint, and typecheck verification"
|
||||
short_description: "Build, test, lint, typecheck verification"
|
||||
brand_color: "#10B981"
|
||||
default_prompt: "Use $verification-loop to run build, test, lint, and typecheck verification."
|
||||
default_prompt: "Run verification: build, test, lint, typecheck, security"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: video-editing
|
||||
description: AI-assisted video editing workflows for cutting, structuring, and augmenting real footage. Covers the full pipeline from raw capture through FFmpeg, Remotion, ElevenLabs, fal.ai, and final polish in Descript or CapCut. Use when the user wants to edit video, cut footage, create vlogs, or build video content.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Video Editing
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "Video Editing"
|
||||
short_description: "AI-assisted editing for real footage"
|
||||
short_description: "AI-assisted video editing for real footage"
|
||||
brand_color: "#EF4444"
|
||||
default_prompt: "Use $video-editing to plan an AI-assisted edit for real footage."
|
||||
default_prompt: "Edit video using AI-assisted pipeline: organize, cut, compose, generate assets, polish"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: x-api
|
||||
description: X/Twitter API integration for posting tweets, threads, reading timelines, search, and analytics. Covers OAuth auth patterns, rate limits, and platform-native content posting. Use when the user wants to interact with X programmatically.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# X API
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
interface:
|
||||
display_name: "X API"
|
||||
short_description: "X API posting, timelines, and analytics"
|
||||
short_description: "X/Twitter API integration for posting, threads, and analytics"
|
||||
brand_color: "#000000"
|
||||
default_prompt: "Use $x-api to build X API posting, timeline, or analytics workflows."
|
||||
default_prompt: "Use X API to post tweets, threads, or retrieve timeline and search data"
|
||||
policy:
|
||||
allow_implicit_invocation: true
|
||||
|
||||
@@ -45,37 +45,60 @@ Example:
|
||||
|
||||
The following fields **must always be arrays**:
|
||||
|
||||
* `agents`
|
||||
* `commands`
|
||||
* `skills`
|
||||
* `hooks` (if present)
|
||||
|
||||
Even if there is only one entry, **strings are not accepted**.
|
||||
|
||||
### Invalid
|
||||
|
||||
```json
|
||||
{
|
||||
"agents": "./agents"
|
||||
}
|
||||
```
|
||||
|
||||
### Valid
|
||||
|
||||
```json
|
||||
{
|
||||
"agents": ["./agents/planner.md"]
|
||||
}
|
||||
```
|
||||
|
||||
This applies consistently across all component path fields.
|
||||
|
||||
---
|
||||
|
||||
## The `agents` Field: DO NOT ADD
|
||||
## Path Resolution Rules (Critical)
|
||||
|
||||
> WARNING: **CRITICAL:** Do NOT add an `"agents"` field to `plugin.json`. The Claude Code plugin validator rejects it entirely.
|
||||
### Agents MUST use explicit file paths
|
||||
|
||||
### Why This Matters
|
||||
The validator **does not accept directory paths for `agents`**.
|
||||
|
||||
The `agents` field is not part of the Claude Code plugin manifest schema. Any form of it -- string path, array of paths, or array of directories -- causes a validation error:
|
||||
Even the following will fail:
|
||||
|
||||
```
|
||||
agents: Invalid input
|
||||
```json
|
||||
{
|
||||
"agents": ["./agents/"]
|
||||
}
|
||||
```
|
||||
|
||||
Agent `.md` files under `agents/` are discovered automatically by convention (similar to hooks). They do not need to be declared in the manifest.
|
||||
Instead, you must enumerate agent files explicitly:
|
||||
|
||||
### History
|
||||
```json
|
||||
{
|
||||
"agents": [
|
||||
"./agents/planner.md",
|
||||
"./agents/architect.md",
|
||||
"./agents/code-reviewer.md"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Previously this repo listed agents explicitly in `plugin.json` as an array of file paths. This passed the repo's own schema but failed Claude Code's actual validator, which does not recognize the field. Removed in #1459.
|
||||
|
||||
---
|
||||
|
||||
## Path Resolution Rules
|
||||
This is the most common source of validation errors.
|
||||
|
||||
### Commands and Skills
|
||||
|
||||
@@ -132,37 +155,16 @@ The test `plugin.json does NOT have explicit hooks declaration` in `tests/hooks/
|
||||
|
||||
---
|
||||
|
||||
## The `mcpServers` Field: Keep the Empty Opt-Out
|
||||
|
||||
ECC keeps `.mcp.json` at the repository root for Codex plugin installs and manual MCP setup.
|
||||
Claude Code also auto-discovers plugin-root `.mcp.json` files by convention, which would bundle the same MCP servers into Claude plugin installs.
|
||||
|
||||
Keep this field in `.claude-plugin/plugin.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {}
|
||||
}
|
||||
```
|
||||
|
||||
This explicit empty object prevents Claude plugin installs from auto-loading ECC's root MCP definitions.
|
||||
Without the opt-out, strict OpenAI-compatible gateways can reject plugin MCP tool names such as `mcp__plugin_everything-claude-code_github__create_pull_request_review` because they exceed 64 characters.
|
||||
|
||||
Users who want the bundled MCP servers should configure them manually from `.mcp.json` or `mcp-configs/mcp-servers.json`.
|
||||
|
||||
---
|
||||
|
||||
## Known Anti-Patterns
|
||||
|
||||
These look correct but are rejected:
|
||||
|
||||
* String values instead of arrays
|
||||
* **Adding `"agents"` in any form** - not a recognized manifest field, causes `Invalid input`
|
||||
* Arrays of directories for `agents`
|
||||
* Missing `version`
|
||||
* Relying on inferred paths
|
||||
* Assuming marketplace behavior matches local validation
|
||||
* **Adding `"hooks": "./hooks/hooks.json"`** - auto-loaded by convention, causes duplicate error
|
||||
* Removing `"mcpServers": {}` - re-enables root `.mcp.json` auto-discovery for Claude plugin installs and can produce overlong MCP tool names
|
||||
|
||||
Avoid cleverness. Be explicit.
|
||||
|
||||
@@ -173,6 +175,10 @@ Avoid cleverness. Be explicit.
|
||||
```json
|
||||
{
|
||||
"version": "1.1.0",
|
||||
"agents": [
|
||||
"./agents/planner.md",
|
||||
"./agents/code-reviewer.md"
|
||||
],
|
||||
"commands": ["./commands/"],
|
||||
"skills": ["./skills/"]
|
||||
}
|
||||
@@ -180,7 +186,7 @@ Avoid cleverness. Be explicit.
|
||||
|
||||
This structure has been validated against the Claude plugin validator.
|
||||
|
||||
**Important:** Notice there is NO `"hooks"` field and NO `"agents"` field. Both are loaded automatically by convention. Adding either explicitly causes errors.
|
||||
**Important:** Notice there is NO `"hooks"` field. The `hooks/hooks.json` file is loaded automatically by convention. Adding it explicitly causes a duplicate error.
|
||||
|
||||
---
|
||||
|
||||
@@ -188,11 +194,10 @@ This structure has been validated against the Claude plugin validator.
|
||||
|
||||
Before submitting changes that touch `plugin.json`:
|
||||
|
||||
1. Ensure all component fields are arrays
|
||||
2. Include a `version`
|
||||
3. Do NOT add `agents` or `hooks` fields (both are auto-loaded by convention)
|
||||
4. Preserve `"mcpServers": {}` unless you are intentionally changing Claude plugin MCP bundling behavior
|
||||
5. Run:
|
||||
1. Use explicit file paths for agents
|
||||
2. Ensure all component fields are arrays
|
||||
3. Include a `version`
|
||||
4. Run:
|
||||
|
||||
```bash
|
||||
claude plugin validate .claude-plugin/plugin.json
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
### Plugin Manifest Gotchas
|
||||
|
||||
If you plan to edit `.claude-plugin/plugin.json`, be aware that the Claude plugin validator enforces several **undocumented but strict constraints** that can cause installs to fail with vague errors (for example, `agents: Invalid input`). In particular, component fields must be arrays, `agents` is not a supported manifest field and must not be included in plugin.json, and a `version` field is required for reliable validation and installation.
|
||||
If you plan to edit `.claude-plugin/plugin.json`, be aware that the Claude plugin validator enforces several **undocumented but strict constraints** that can cause installs to fail with vague errors (for example, `agents: Invalid input`). In particular, component fields must be arrays, `agents` must use explicit file paths rather than directories, and a `version` field is required for reliable validation and installation.
|
||||
|
||||
These constraints are not obvious from public examples and have caused repeated installation failures in the past. They are documented in detail in `.claude-plugin/PLUGIN_SCHEMA_NOTES.md`, which should be reviewed before making any changes to the plugin manifest.
|
||||
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
|
||||
"name": "everything-claude-code",
|
||||
"description": "Battle-tested Claude Code configurations from an Anthropic hackathon winner — agents, skills, hooks, rules, and legacy command shims evolved over 10+ months of intensive daily use",
|
||||
"owner": {
|
||||
"name": "Affaan Mustafa",
|
||||
"email": "me@affaanmustafa.com"
|
||||
@@ -11,13 +13,13 @@
|
||||
{
|
||||
"name": "everything-claude-code",
|
||||
"source": "./",
|
||||
"description": "The most comprehensive Claude Code plugin — 48 agents, 182 skills, 68 legacy command shims, selective install profiles, and production-ready hooks for TDD, security scanning, code review, and continuous learning",
|
||||
"version": "2.0.0-rc.1",
|
||||
"description": "The most comprehensive Claude Code plugin — 36 agents, 142 skills, 68 legacy command shims, and production-ready hooks for TDD, security scanning, code review, and continuous learning",
|
||||
"version": "1.9.0",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
"email": "me@affaanmustafa.com"
|
||||
},
|
||||
"homepage": "https://ecc.tools",
|
||||
"homepage": "https://github.com/affaan-m/everything-claude-code",
|
||||
"repository": "https://github.com/affaan-m/everything-claude-code",
|
||||
"license": "MIT",
|
||||
"keywords": [
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"name": "everything-claude-code",
|
||||
"version": "2.0.0-rc.1",
|
||||
"description": "Battle-tested Claude Code plugin for engineering teams — 48 agents, 182 skills, 68 legacy command shims, production-ready hooks, and selective install workflows evolved through continuous real-world use",
|
||||
"version": "1.9.0",
|
||||
"description": "Complete collection of battle-tested Claude Code configs from an Anthropic hackathon winner - agents, skills, hooks, rules, and legacy command shims evolved over 10+ months of intensive daily use",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
"url": "https://x.com/affaanmustafa"
|
||||
},
|
||||
"homepage": "https://ecc.tools",
|
||||
"homepage": "https://github.com/affaan-m/everything-claude-code",
|
||||
"repository": "https://github.com/affaan-m/everything-claude-code",
|
||||
"license": "MIT",
|
||||
"keywords": [
|
||||
@@ -22,7 +22,36 @@
|
||||
"automation",
|
||||
"best-practices"
|
||||
],
|
||||
"mcpServers": {},
|
||||
"agents": [
|
||||
"./agents/architect.md",
|
||||
"./agents/build-error-resolver.md",
|
||||
"./agents/chief-of-staff.md",
|
||||
"./agents/code-reviewer.md",
|
||||
"./agents/cpp-build-resolver.md",
|
||||
"./agents/cpp-reviewer.md",
|
||||
"./agents/database-reviewer.md",
|
||||
"./agents/doc-updater.md",
|
||||
"./agents/docs-lookup.md",
|
||||
"./agents/e2e-runner.md",
|
||||
"./agents/flutter-reviewer.md",
|
||||
"./agents/go-build-resolver.md",
|
||||
"./agents/go-reviewer.md",
|
||||
"./agents/harness-optimizer.md",
|
||||
"./agents/java-build-resolver.md",
|
||||
"./agents/java-reviewer.md",
|
||||
"./agents/kotlin-build-resolver.md",
|
||||
"./agents/kotlin-reviewer.md",
|
||||
"./agents/loop-operator.md",
|
||||
"./agents/planner.md",
|
||||
"./agents/python-reviewer.md",
|
||||
"./agents/pytorch-build-resolver.md",
|
||||
"./agents/refactor-cleaner.md",
|
||||
"./agents/rust-build-resolver.md",
|
||||
"./agents/rust-reviewer.md",
|
||||
"./agents/security-reviewer.md",
|
||||
"./agents/tdd-guide.md",
|
||||
"./agents/typescript-reviewer.md"
|
||||
],
|
||||
"skills": ["./skills/"],
|
||||
"commands": ["./commands/"]
|
||||
}
|
||||
|
||||
@@ -12,7 +12,7 @@ This directory contains the **Codex plugin manifest** for Everything Claude Code
|
||||
|
||||
## What This Provides
|
||||
|
||||
- **182 skills** from `./skills/` — reusable Codex workflows for TDD, security,
|
||||
- **142 skills** from `./skills/` — reusable Codex workflows for TDD, security,
|
||||
code review, architecture, and more
|
||||
- **6 MCP servers** — GitHub, Context7, Exa, Memory, Playwright, Sequential Thinking
|
||||
|
||||
@@ -30,9 +30,6 @@ codex plugin install ./
|
||||
Run this from the repository root so `./` points to the repo root and `.mcp.json` resolves correctly.
|
||||
```
|
||||
|
||||
The installed plugin registers under the short slug `ecc` so tool and command names
|
||||
stay below provider length limits.
|
||||
|
||||
## MCP Servers Included
|
||||
|
||||
| Server | Purpose |
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"version": "2.0.0-rc.1",
|
||||
"description": "Battle-tested Codex workflows — 182 shared ECC skills, production-ready MCP configs, and selective-install-aligned conventions for TDD, security scanning, code review, and autonomous development.",
|
||||
"name": "everything-claude-code",
|
||||
"version": "1.9.0",
|
||||
"description": "Battle-tested Codex workflows — 125 skills, production-ready MCP configs, and agent definitions for TDD, security scanning, code review, and autonomous development.",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
"email": "me@affaanmustafa.com",
|
||||
"url": "https://x.com/affaanmustafa"
|
||||
},
|
||||
"homepage": "https://ecc.tools",
|
||||
"homepage": "https://github.com/affaan-m/everything-claude-code",
|
||||
"repository": "https://github.com/affaan-m/everything-claude-code",
|
||||
"license": "MIT",
|
||||
"keywords": ["codex", "agents", "skills", "tdd", "code-review", "security", "workflow", "automation"],
|
||||
@@ -15,16 +15,16 @@
|
||||
"mcpServers": "./.mcp.json",
|
||||
"interface": {
|
||||
"displayName": "Everything Claude Code",
|
||||
"shortDescription": "182 battle-tested ECC skills plus MCP configs for TDD, security, code review, and autonomous development.",
|
||||
"longDescription": "Everything Claude Code (ECC) is a community-maintained collection of Codex-ready skills and MCP configs evolved over 10+ months of intensive daily use. It covers TDD workflows, security scanning, code review, architecture decisions, operator workflows, and more — all in one installable plugin.",
|
||||
"shortDescription": "125 battle-tested skills for TDD, security, code review, and autonomous development.",
|
||||
"longDescription": "Everything Claude Code (ECC) is a community-maintained collection of Codex skills and MCP configs evolved over 10+ months of intensive daily use. It covers TDD workflows, security scanning, code review, architecture decisions, and more — all in one installable plugin.",
|
||||
"developerName": "Affaan Mustafa",
|
||||
"category": "Productivity",
|
||||
"capabilities": ["Read", "Write"],
|
||||
"websiteURL": "https://ecc.tools",
|
||||
"websiteURL": "https://github.com/affaan-m/everything-claude-code",
|
||||
"defaultPrompt": [
|
||||
"Use the tdd-workflow skill to write tests before implementation.",
|
||||
"Use the security-review skill to scan for OWASP Top 10 vulnerabilities.",
|
||||
"Use the verification-loop skill to verify correctness before shipping changes."
|
||||
"Use the code-review skill to review this PR for correctness and security."
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -60,12 +60,6 @@ The sync script (`scripts/sync-ecc-to-codex.sh`) uses a Node-based TOML parser t
|
||||
- **`--update-mcp`** — explicitly replaces all ECC-managed servers with the latest recommended config (safely removes subtables like `[mcp_servers.supabase.env]`).
|
||||
- **User config is always preserved** — custom servers, args, env vars, and credentials outside ECC-managed sections are never touched.
|
||||
|
||||
## External Action Boundaries
|
||||
|
||||
Treat networked tools as read-only by default. Search, inspect, and draft freely within the user's requested scope, but require explicit user approval before posting, publishing, pushing, merging, opening paid jobs, dispatching remote agents, changing third-party resources, or modifying credentials.
|
||||
|
||||
When approval is ambiguous, produce a local plan or draft artifact instead of taking the external action. Preserve user config and private state unless the user specifically asks for a scoped change.
|
||||
|
||||
## Multi-Agent Support
|
||||
|
||||
Codex now supports multi-agent workflows behind the experimental `features.multi_agent` flag.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
{
|
||||
"version": 1,
|
||||
"hooks": {
|
||||
"sessionStart": [
|
||||
{
|
||||
@@ -38,7 +37,7 @@
|
||||
{
|
||||
"command": "node .cursor/hooks/after-file-edit.js",
|
||||
"event": "afterFileEdit",
|
||||
"description": "Auto-format, TypeScript check, console.log warning, and frontend design-quality reminder"
|
||||
"description": "Auto-format, TypeScript check, console.log warning"
|
||||
}
|
||||
],
|
||||
"beforeMCPExecution": [
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
#!/usr/bin/env node
|
||||
const { hookEnabled, readStdin, runExistingHook, transformToClaude } = require('./adapter');
|
||||
const { readStdin, runExistingHook, transformToClaude } = require('./adapter');
|
||||
readStdin().then(raw => {
|
||||
try {
|
||||
const input = JSON.parse(raw);
|
||||
@@ -11,9 +11,6 @@ readStdin().then(raw => {
|
||||
// Accumulate edited paths for batch format+typecheck at stop time
|
||||
runExistingHook('post-edit-accumulator.js', claudeStr);
|
||||
runExistingHook('post-edit-console-warn.js', claudeStr);
|
||||
if (hookEnabled('post:edit:design-quality-check', ['standard', 'strict'])) {
|
||||
runExistingHook('design-quality-check.js', claudeStr);
|
||||
}
|
||||
} catch {}
|
||||
process.stdout.write(raw);
|
||||
}).catch(() => process.exit(0));
|
||||
|
||||
30
.github/workflows/ci.yml
vendored
30
.github/workflows/ci.yml
vendored
@@ -2,8 +2,7 @@ name: CI
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main, 'release/**']
|
||||
tags: ['v*']
|
||||
branches: [main]
|
||||
pull_request:
|
||||
branches: [main]
|
||||
|
||||
@@ -44,18 +43,10 @@ jobs:
|
||||
|
||||
# Package manager setup
|
||||
- name: Setup pnpm
|
||||
if: matrix.pm == 'pnpm' && matrix.node != '18.x'
|
||||
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
|
||||
if: matrix.pm == 'pnpm'
|
||||
uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4
|
||||
with:
|
||||
# Keep an explicit pnpm major because this repo's packageManager is Yarn.
|
||||
version: 10
|
||||
|
||||
- name: Setup pnpm (via Corepack)
|
||||
if: matrix.pm == 'pnpm' && matrix.node == '18.x'
|
||||
shell: bash
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare pnpm@9 --activate
|
||||
version: latest
|
||||
|
||||
- name: Setup Yarn (via Corepack)
|
||||
if: matrix.pm == 'yarn'
|
||||
@@ -88,8 +79,6 @@ jobs:
|
||||
if: matrix.pm == 'pnpm'
|
||||
id: pnpm-cache-dir
|
||||
shell: bash
|
||||
env:
|
||||
COREPACK_ENABLE_STRICT: '0'
|
||||
run: echo "dir=$(pnpm store path)" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Cache pnpm
|
||||
@@ -141,10 +130,7 @@ jobs:
|
||||
run: |
|
||||
case "${{ matrix.pm }}" in
|
||||
npm) npm ci ;;
|
||||
# pnpm v10 can fail CI on ignored native build scripts
|
||||
# (for example msgpackr-extract) even though this repo is Yarn-native
|
||||
# and pnpm is only exercised here as a compatibility lane.
|
||||
pnpm) pnpm install --config.strict-dep-builds=false --no-frozen-lockfile ;;
|
||||
pnpm) pnpm install --no-frozen-lockfile ;;
|
||||
# Yarn Berry (v4+) removed --ignore-engines; engine checking is no longer a core feature
|
||||
yarn) yarn install ;;
|
||||
bun) bun install ;;
|
||||
@@ -160,7 +146,7 @@ jobs:
|
||||
# Upload test artifacts on failure
|
||||
- name: Upload test artifacts
|
||||
if: failure()
|
||||
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
|
||||
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
|
||||
with:
|
||||
name: test-results-${{ matrix.os }}-node${{ matrix.node }}-${{ matrix.pm }}
|
||||
path: |
|
||||
@@ -204,10 +190,6 @@ jobs:
|
||||
run: node scripts/ci/validate-install-manifests.js
|
||||
continue-on-error: false
|
||||
|
||||
- name: Validate workflow security
|
||||
run: node scripts/ci/validate-workflow-security.js
|
||||
continue-on-error: false
|
||||
|
||||
- name: Validate rules
|
||||
run: node scripts/ci/validate-rules.js
|
||||
continue-on-error: false
|
||||
|
||||
2
.github/workflows/maintenance.yml
vendored
2
.github/workflows/maintenance.yml
vendored
@@ -43,7 +43,7 @@ jobs:
|
||||
name: Stale Issues/PRs
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/stale@b5d41d4e1d5dceea10e7104786b73624c18a190f # v10.2.0
|
||||
- uses: actions/stale@5bef64f19d7facfb25b37b414482c7164d639639 # v9
|
||||
with:
|
||||
stale-issue-message: 'This issue is stale due to inactivity.'
|
||||
stale-pr-message: 'This PR is stale due to inactivity.'
|
||||
|
||||
23
.github/workflows/monthly-metrics.yml
vendored
23
.github/workflows/monthly-metrics.yml
vendored
@@ -15,7 +15,7 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Update monthly metrics issue
|
||||
uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
|
||||
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
|
||||
with:
|
||||
script: |
|
||||
const owner = context.repo.owner;
|
||||
@@ -30,10 +30,6 @@ jobs:
|
||||
return match ? Number(match[1]) : null;
|
||||
}
|
||||
|
||||
function escapeRegex(value) {
|
||||
return value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
|
||||
}
|
||||
|
||||
function fmt(value) {
|
||||
if (value === null || value === undefined) return "n/a";
|
||||
return Number(value).toLocaleString("en-US");
|
||||
@@ -171,18 +167,15 @@ jobs:
|
||||
}
|
||||
|
||||
const currentBody = issue.body || "";
|
||||
const rowPattern = new RegExp(`^\\| ${escapeRegex(monthKey)} \\|.*$`, "m");
|
||||
|
||||
let body;
|
||||
if (rowPattern.test(currentBody)) {
|
||||
body = currentBody.replace(rowPattern, row);
|
||||
console.log(`Refreshed issue #${issue.number} snapshot row for ${monthKey}`);
|
||||
} else {
|
||||
body = currentBody.includes("| Month (UTC) |")
|
||||
? `${currentBody.trimEnd()}\n${row}\n`
|
||||
: `${intro}\n${row}\n`;
|
||||
if (currentBody.includes(`| ${monthKey} |`)) {
|
||||
console.log(`Issue #${issue.number} already has snapshot row for ${monthKey}`);
|
||||
return;
|
||||
}
|
||||
|
||||
const body = currentBody.includes("| Month (UTC) |")
|
||||
? `${currentBody.trimEnd()}\n${row}\n`
|
||||
: `${intro}\n${row}\n`;
|
||||
|
||||
await github.rest.issues.update({
|
||||
owner,
|
||||
repo,
|
||||
|
||||
53
.github/workflows/release.yml
vendored
53
.github/workflows/release.yml
vendored
@@ -6,7 +6,6 @@ on:
|
||||
|
||||
permissions:
|
||||
contents: write
|
||||
id-token: write
|
||||
|
||||
jobs:
|
||||
release:
|
||||
@@ -19,55 +18,27 @@ jobs:
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f # v6.3.0
|
||||
with:
|
||||
node-version: '20.x'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Verify OpenCode package payload
|
||||
run: node tests/scripts/build-opencode.test.js
|
||||
|
||||
- name: Validate version tag
|
||||
run: |
|
||||
if ! [[ "${REF_NAME}" =~ ^v[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z.-]+)?$ ]]; then
|
||||
echo "Invalid version tag format. Expected vX.Y.Z or vX.Y.Z-prerelease"
|
||||
if ! [[ "${REF_NAME}" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
|
||||
echo "Invalid version tag format. Expected vX.Y.Z"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
env:
|
||||
REF_NAME: ${{ github.ref_name }}
|
||||
- name: Verify package version matches tag
|
||||
- name: Verify plugin.json version matches tag
|
||||
env:
|
||||
TAG_NAME: ${{ github.ref_name }}
|
||||
run: |
|
||||
TAG_VERSION="${TAG_NAME#v}"
|
||||
PACKAGE_VERSION=$(node -p "require('./package.json').version")
|
||||
if [ "$TAG_VERSION" != "$PACKAGE_VERSION" ]; then
|
||||
echo "::error::Tag version ($TAG_VERSION) does not match package.json version ($PACKAGE_VERSION)"
|
||||
PLUGIN_VERSION=$(grep -oE '"version": *"[^"]*"' .claude-plugin/plugin.json | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
|
||||
if [ "$TAG_VERSION" != "$PLUGIN_VERSION" ]; then
|
||||
echo "::error::Tag version ($TAG_VERSION) does not match plugin.json version ($PLUGIN_VERSION)"
|
||||
echo "Run: ./scripts/release.sh $TAG_VERSION"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Verify release metadata stays in sync
|
||||
run: node tests/plugin-manifest.test.js
|
||||
|
||||
- name: Check npm publish state
|
||||
id: npm_publish_state
|
||||
run: |
|
||||
PACKAGE_NAME=$(node -p "require('./package.json').name")
|
||||
PACKAGE_VERSION=$(node -p "require('./package.json').version")
|
||||
NPM_DIST_TAG=$(node -p "require('./package.json').version.includes('-') ? 'next' : 'latest'")
|
||||
if npm view "${PACKAGE_NAME}@${PACKAGE_VERSION}" version >/dev/null 2>&1; then
|
||||
echo "already_published=true" >> "$GITHUB_OUTPUT"
|
||||
else
|
||||
echo "already_published=false" >> "$GITHUB_OUTPUT"
|
||||
fi
|
||||
echo "dist_tag=${NPM_DIST_TAG}" >> "$GITHUB_OUTPUT"
|
||||
|
||||
- name: Generate release highlights
|
||||
id: highlights
|
||||
env:
|
||||
@@ -88,21 +59,11 @@ jobs:
|
||||
- Improved release-note generation and changelog hygiene
|
||||
|
||||
### Notes
|
||||
- npm package: \`ecc-universal\`
|
||||
- Claude marketplace/plugin identifier: \`everything-claude-code@everything-claude-code\`
|
||||
- For migration tips and compatibility notes, see README and CHANGELOG.
|
||||
EOF
|
||||
|
||||
- name: Create GitHub Release
|
||||
uses: softprops/action-gh-release@b4309332981a82ec1c5618f44dd2e27cc8bfbfda # v3.0.0
|
||||
uses: softprops/action-gh-release@153bb8e04406b158c6c84fc1615b65b24149a1fe # v2
|
||||
with:
|
||||
body_path: release_body.md
|
||||
generate_release_notes: true
|
||||
prerelease: ${{ contains(github.ref_name, '-') }}
|
||||
make_latest: ${{ contains(github.ref_name, '-') && 'false' || 'true' }}
|
||||
|
||||
- name: Publish npm package
|
||||
if: steps.npm_publish_state.outputs.already_published != 'true'
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
|
||||
run: npm publish --access public --provenance --tag "${{ steps.npm_publish_state.outputs.dist_tag }}"
|
||||
|
||||
74
.github/workflows/reusable-release.yml
vendored
74
.github/workflows/reusable-release.yml
vendored
@@ -12,24 +12,9 @@ on:
|
||||
required: false
|
||||
type: boolean
|
||||
default: true
|
||||
secrets:
|
||||
NPM_TOKEN:
|
||||
required: false
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
tag:
|
||||
description: 'Version tag to release or republish (e.g., v2.0.0-rc.1)'
|
||||
required: true
|
||||
type: string
|
||||
generate-notes:
|
||||
description: 'Auto-generate release notes'
|
||||
required: false
|
||||
type: boolean
|
||||
default: true
|
||||
|
||||
permissions:
|
||||
contents: write
|
||||
id-token: write
|
||||
|
||||
jobs:
|
||||
release:
|
||||
@@ -41,57 +26,16 @@ jobs:
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
with:
|
||||
fetch-depth: 0
|
||||
ref: ${{ inputs.tag }}
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@53b83947a5a98c8d113130e565377fae1a50d02f # v6.3.0
|
||||
with:
|
||||
node-version: '20.x'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Verify OpenCode package payload
|
||||
run: node tests/scripts/build-opencode.test.js
|
||||
|
||||
- name: Validate version tag
|
||||
env:
|
||||
INPUT_TAG: ${{ inputs.tag }}
|
||||
run: |
|
||||
if ! [[ "$INPUT_TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z.-]+)?$ ]]; then
|
||||
echo "Invalid version tag format. Expected vX.Y.Z or vX.Y.Z-prerelease"
|
||||
if ! [[ "$INPUT_TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
|
||||
echo "Invalid version tag format. Expected vX.Y.Z"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Verify package version matches tag
|
||||
env:
|
||||
INPUT_TAG: ${{ inputs.tag }}
|
||||
run: |
|
||||
TAG_VERSION="${INPUT_TAG#v}"
|
||||
PACKAGE_VERSION=$(node -p "require('./package.json').version")
|
||||
if [ "$TAG_VERSION" != "$PACKAGE_VERSION" ]; then
|
||||
echo "::error::Tag version ($TAG_VERSION) does not match package.json version ($PACKAGE_VERSION)"
|
||||
echo "Run: ./scripts/release.sh $TAG_VERSION"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Verify release metadata stays in sync
|
||||
run: node tests/plugin-manifest.test.js
|
||||
|
||||
- name: Check npm publish state
|
||||
id: npm_publish_state
|
||||
run: |
|
||||
PACKAGE_NAME=$(node -p "require('./package.json').name")
|
||||
PACKAGE_VERSION=$(node -p "require('./package.json').version")
|
||||
NPM_DIST_TAG=$(node -p "require('./package.json').version.includes('-') ? 'next' : 'latest'")
|
||||
if npm view "${PACKAGE_NAME}@${PACKAGE_VERSION}" version >/dev/null 2>&1; then
|
||||
echo "already_published=true" >> "$GITHUB_OUTPUT"
|
||||
else
|
||||
echo "already_published=false" >> "$GITHUB_OUTPUT"
|
||||
fi
|
||||
echo "dist_tag=${NPM_DIST_TAG}" >> "$GITHUB_OUTPUT"
|
||||
|
||||
- name: Generate release highlights
|
||||
env:
|
||||
TAG_NAME: ${{ inputs.tag }}
|
||||
@@ -104,23 +48,11 @@ jobs:
|
||||
- Harness reliability and cross-platform compatibility
|
||||
- Eval-driven quality improvements
|
||||
- Better workflow and operator ergonomics
|
||||
|
||||
### Package Notes
|
||||
- npm package: \`ecc-universal\`
|
||||
- Claude marketplace/plugin identifier: \`everything-claude-code@everything-claude-code\`
|
||||
EOF
|
||||
|
||||
- name: Create GitHub Release
|
||||
uses: softprops/action-gh-release@b4309332981a82ec1c5618f44dd2e27cc8bfbfda # v3.0.0
|
||||
uses: softprops/action-gh-release@153bb8e04406b158c6c84fc1615b65b24149a1fe # v2
|
||||
with:
|
||||
tag_name: ${{ inputs.tag }}
|
||||
body_path: release_body.md
|
||||
generate_release_notes: ${{ inputs.generate-notes }}
|
||||
prerelease: ${{ contains(inputs.tag, '-') }}
|
||||
make_latest: ${{ contains(inputs.tag, '-') && 'false' || 'true' }}
|
||||
|
||||
- name: Publish npm package
|
||||
if: steps.npm_publish_state.outputs.already_published != 'true'
|
||||
env:
|
||||
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
|
||||
run: npm publish --access public --provenance --tag "${{ steps.npm_publish_state.outputs.dist_tag }}"
|
||||
|
||||
23
.github/workflows/reusable-test.yml
vendored
23
.github/workflows/reusable-test.yml
vendored
@@ -35,18 +35,10 @@ jobs:
|
||||
node-version: ${{ inputs.node-version }}
|
||||
|
||||
- name: Setup pnpm
|
||||
if: inputs.package-manager == 'pnpm' && inputs.node-version != '18.x'
|
||||
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
|
||||
if: inputs.package-manager == 'pnpm'
|
||||
uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4
|
||||
with:
|
||||
# Keep an explicit pnpm major because this repo's packageManager is Yarn.
|
||||
version: 10
|
||||
|
||||
- name: Setup pnpm (via Corepack)
|
||||
if: inputs.package-manager == 'pnpm' && inputs.node-version == '18.x'
|
||||
shell: bash
|
||||
run: |
|
||||
corepack enable
|
||||
corepack prepare pnpm@9 --activate
|
||||
version: latest
|
||||
|
||||
- name: Setup Yarn (via Corepack)
|
||||
if: inputs.package-manager == 'yarn'
|
||||
@@ -78,8 +70,6 @@ jobs:
|
||||
if: inputs.package-manager == 'pnpm'
|
||||
id: pnpm-cache-dir
|
||||
shell: bash
|
||||
env:
|
||||
COREPACK_ENABLE_STRICT: '0'
|
||||
run: echo "dir=$(pnpm store path)" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Cache pnpm
|
||||
@@ -130,10 +120,7 @@ jobs:
|
||||
run: |
|
||||
case "${{ inputs.package-manager }}" in
|
||||
npm) npm ci ;;
|
||||
# pnpm v10 can fail CI on ignored native build scripts
|
||||
# (for example msgpackr-extract) even though this repo is Yarn-native
|
||||
# and pnpm is only exercised here as a compatibility lane.
|
||||
pnpm) pnpm install --config.strict-dep-builds=false --no-frozen-lockfile ;;
|
||||
pnpm) pnpm install --no-frozen-lockfile ;;
|
||||
# Yarn Berry (v4+) removed --ignore-engines; engine checking is no longer a core feature
|
||||
yarn) yarn install ;;
|
||||
bun) bun install ;;
|
||||
@@ -147,7 +134,7 @@ jobs:
|
||||
|
||||
- name: Upload test artifacts
|
||||
if: failure()
|
||||
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
|
||||
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
|
||||
with:
|
||||
name: test-results-${{ inputs.os }}-node${{ inputs.node-version }}-${{ inputs.package-manager }}
|
||||
path: |
|
||||
|
||||
3
.github/workflows/reusable-validate.yml
vendored
3
.github/workflows/reusable-validate.yml
vendored
@@ -42,9 +42,6 @@ jobs:
|
||||
- name: Validate install manifests
|
||||
run: node scripts/ci/validate-install-manifests.js
|
||||
|
||||
- name: Validate workflow security
|
||||
run: node scripts/ci/validate-workflow-security.js
|
||||
|
||||
- name: Validate rules
|
||||
run: node scripts/ci/validate-rules.js
|
||||
|
||||
|
||||
@@ -21,12 +21,6 @@ Use this skill when:
|
||||
- The user asks "add X functionality" and you're about to write code
|
||||
- Before creating a new utility, helper, or abstraction
|
||||
|
||||
## Scope and Approval Rules
|
||||
|
||||
Default to read-only research: inspect the repo, package metadata, docs, and public examples before recommending a dependency or integration. Do not install packages, configure MCP servers, publish artifacts, open PRs, or make external write actions from this skill unless the user has explicitly approved that action in the current task.
|
||||
|
||||
When a candidate requires credentials, paid services, network writes, or project-wide config changes, return a recommendation and approval checkpoint instead of applying it directly.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
@@ -51,9 +45,9 @@ When a candidate requires credentials, paid services, network writes, or project
|
||||
│ │ as-is │ │ /Wrap │ │ Custom │ │
|
||||
│ └─────────┘ └──────────┘ └─────────┘ │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ 5. APPROVAL CHECKPOINT / IMPLEMENT │
|
||||
│ Recommend package / MCP / custom code │
|
||||
│ Apply only after explicit approval │
|
||||
│ 5. IMPLEMENT │
|
||||
│ Install package / Configure MCP / │
|
||||
│ Write minimal custom code │
|
||||
└─────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
@@ -61,10 +55,10 @@ When a candidate requires credentials, paid services, network writes, or project
|
||||
|
||||
| Signal | Action |
|
||||
|--------|--------|
|
||||
| Exact match, well-maintained, MIT/Apache | **Adopt** — recommend the package and request approval before install or config changes |
|
||||
| Partial match, good foundation | **Extend** — recommend the package plus a thin wrapper, then wait for approval before applying |
|
||||
| Multiple weak matches | **Compose** — propose 2-3 small packages and the integration plan before installing anything |
|
||||
| Nothing suitable found | **Build** — explain why custom code is warranted, then implement only within the approved task scope |
|
||||
| Exact match, well-maintained, MIT/Apache | **Adopt** — install and use directly |
|
||||
| Partial match, good foundation | **Extend** — install + write thin wrapper |
|
||||
| Multiple weak matches | **Compose** — combine 2-3 small packages |
|
||||
| Nothing suitable found | **Build** — write custom, but informed by research |
|
||||
|
||||
## How to Use
|
||||
|
||||
@@ -141,8 +135,8 @@ Combine for progressive discovery:
|
||||
Need: Check markdown files for broken links
|
||||
Search: npm "markdown dead link checker"
|
||||
Found: textlint-rule-no-dead-link (score: 9/10)
|
||||
Action: ADOPT — recommend `textlint-rule-no-dead-link` and ask before installing it
|
||||
Result: Zero custom code if approved, battle-tested solution
|
||||
Action: ADOPT — npm install textlint-rule-no-dead-link
|
||||
Result: Zero custom code, battle-tested solution
|
||||
```
|
||||
|
||||
### Example 2: "Add HTTP client wrapper"
|
||||
@@ -150,8 +144,8 @@ Result: Zero custom code if approved, battle-tested solution
|
||||
Need: Resilient HTTP client with retries and timeout handling
|
||||
Search: npm "http client retry", PyPI "httpx retry"
|
||||
Found: got (Node) with retry plugin, httpx (Python) with built-in retry
|
||||
Action: ADOPT — recommend `got`/`httpx` directly with retry config and ask before changing dependencies
|
||||
Result: Zero custom code if approved, production-proven libraries
|
||||
Action: ADOPT — use got/httpx directly with retry config
|
||||
Result: Zero custom code, production-proven libraries
|
||||
```
|
||||
|
||||
### Example 3: "Add config file linter"
|
||||
@@ -159,8 +153,8 @@ Result: Zero custom code if approved, production-proven libraries
|
||||
Need: Validate project config files against a schema
|
||||
Search: npm "config linter schema", "json schema validator cli"
|
||||
Found: ajv-cli (score: 8/10)
|
||||
Action: ADOPT + EXTEND — recommend `ajv-cli` plus a project-specific schema, then wait for approval before install/write
|
||||
Result: 1 package + 1 schema file if approved, no custom validation logic
|
||||
Action: ADOPT + EXTEND — install ajv-cli, write project-specific schema
|
||||
Result: 1 package + 1 schema file, no custom validation logic
|
||||
```
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
@@ -1,2 +0,0 @@
|
||||
node_modules
|
||||
bun.lock
|
||||
@@ -184,7 +184,7 @@ Create a detailed implementation plan for: {input}
|
||||
```markdown
|
||||
---
|
||||
description: Create implementation plan
|
||||
agent: everything-claude-code:planner
|
||||
agent: planner
|
||||
---
|
||||
|
||||
Create a detailed implementation plan for: $ARGUMENTS
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Fix build and TypeScript errors with minimal changes
|
||||
agent: everything-claude-code:build-error-resolver
|
||||
agent: build-error-resolver
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Save verification state and progress checkpoint
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Checkpoint Command
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Review code for quality, security, and maintainability
|
||||
agent: everything-claude-code:code-reviewer
|
||||
agent: code-reviewer
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Generate and run E2E tests with Playwright
|
||||
agent: everything-claude-code:e2e-runner
|
||||
agent: e2e-runner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Run evaluation against acceptance criteria
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Eval Command
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Analyze instincts and suggest or generate evolved structures
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Evolve Command
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Fix Go build and vet errors
|
||||
agent: everything-claude-code:go-build-resolver
|
||||
agent: go-build-resolver
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Go code review for idiomatic patterns
|
||||
agent: everything-claude-code:go-reviewer
|
||||
agent: go-reviewer
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Go TDD workflow with table-driven tests
|
||||
agent: everything-claude-code:tdd-guide
|
||||
agent: tdd-guide
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Export instincts for sharing
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Instinct Export Command
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Import instincts from external sources
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Instinct Import Command
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Show learned instincts (project + global) with confidence
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Instinct Status Command
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Extract patterns and learnings from current session
|
||||
agent: everything-claude-code:build
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Learn Command
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Orchestrate multiple agents for complex tasks
|
||||
agent: everything-claude-code:planner
|
||||
agent: planner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user