mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-06 09:13:31 +08:00
feat: add connector and dashboard builder skills
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — Agent Instructions
|
||||
|
||||
This is a **production-ready AI coding plugin** providing 39 specialized agents, 175 skills, 72 commands, and automated hook workflows for software development.
|
||||
This is a **production-ready AI coding plugin** providing 39 specialized agents, 177 skills, 72 commands, and automated hook workflows for software development.
|
||||
|
||||
**Version:** 1.10.0
|
||||
|
||||
@@ -146,7 +146,7 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
|
||||
|
||||
```
|
||||
agents/ — 39 specialized subagents
|
||||
skills/ — 175 workflow skills and domain knowledge
|
||||
skills/ — 177 workflow skills and domain knowledge
|
||||
commands/ — 72 slash commands
|
||||
hooks/ — Trigger-based automations
|
||||
rules/ — Always-follow guidelines (common + per-language)
|
||||
|
||||
@@ -236,7 +236,7 @@ For manual install instructions see the README in the `rules/` folder. When copy
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**That's it!** You now have access to 39 agents, 175 skills, and 72 legacy command shims.
|
||||
**That's it!** You now have access to 39 agents, 177 skills, and 72 legacy command shims.
|
||||
|
||||
### Multi-model commands require additional setup
|
||||
|
||||
@@ -1154,7 +1154,7 @@ The configuration is automatically detected from `.opencode/opencode.json`.
|
||||
|---------|-------------|----------|--------|
|
||||
| Agents | PASS: 39 agents | PASS: 12 agents | **Claude Code leads** |
|
||||
| Commands | PASS: 72 commands | PASS: 31 commands | **Claude Code leads** |
|
||||
| Skills | PASS: 175 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Skills | PASS: 177 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Hooks | PASS: 8 event types | PASS: 11 events | **OpenCode has more!** |
|
||||
| Rules | PASS: 29 rules | PASS: 13 instructions | **Claude Code leads** |
|
||||
| MCP Servers | PASS: 14 servers | PASS: Full | **Full parity** |
|
||||
@@ -1263,7 +1263,7 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **Agents** | 39 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
|
||||
| **Commands** | 72 | Shared | Instruction-based | 31 |
|
||||
| **Skills** | 175 | Shared | 10 (native format) | 37 |
|
||||
| **Skills** | 177 | Shared | 10 (native format) | 37 |
|
||||
| **Hook Events** | 8 types | 15 types | None yet | 11 types |
|
||||
| **Hook Scripts** | 20+ scripts | 16 scripts (DRY adapter) | N/A | Plugin hooks |
|
||||
| **Rules** | 34 (common + lang) | 34 (YAML frontmatter) | Instruction-based | 13 instructions |
|
||||
|
||||
@@ -106,7 +106,7 @@ cp -r everything-claude-code/rules/perl ~/.claude/rules/
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**完成!** 你现在可以使用 39 个代理、175 个技能和 72 个命令。
|
||||
**完成!** 你现在可以使用 39 个代理、177 个技能和 72 个命令。
|
||||
|
||||
### multi-* 命令需要额外配置
|
||||
|
||||
|
||||
@@ -93,7 +93,7 @@ Keep this file detailed for only the current sprint, blockers, and next actions.
|
||||
- 2026-04-05: Fixed the `main` npm CI break after the latest direct ports. `package-lock.json` had drifted behind `package.json` on the `globals` devDependency (`^17.1.0` vs `^17.4.0`), which caused all npm-based GitHub Actions jobs to fail at `npm ci`. Refreshed the lockfile only, verified `npm ci --ignore-scripts`, and kept the mixed-lock workspace otherwise untouched.
|
||||
- 2026-04-05: Direct-ported the useful discoverability part of `#1221` without duplicating a second healthcare compliance system. Added `skills/hipaa-compliance/SKILL.md` as a thin HIPAA-specific entrypoint that points into the canonical `healthcare-phi-compliance` / `healthcare-reviewer` lane, and wired both healthcare privacy skills into the `security` install module for selective installs.
|
||||
- 2026-04-05: Direct-ported the audited blockchain/web3 security lane from `#1222` into `main` as four self-contained skills: `defi-amm-security`, `evm-token-decimals`, `llm-trading-agent-security`, and `nodejs-keccak256`. These are now part of the `security` install module instead of living as an unmerged fork PR.
|
||||
- 2026-04-05: Salvaged the only clearly non-overlapping piece of `#1203` as `skills/security-bounty-hunter/SKILL.md`, then kept the rest of that PR out. `api-connector-builder` duplicated existing connector/pattern-mining workflows and `dashboard-builder` was too generic and under-specified to land as a canonical ECC skill.
|
||||
- 2026-04-05: Finished the useful salvage pass from `#1203` directly on `main`. `skills/security-bounty-hunter`, `skills/api-connector-builder`, and `skills/dashboard-builder` are now in-tree as ECC-native rewrites instead of the thinner original community drafts. The original PR should be treated as superseded rather than merged.
|
||||
- 2026-04-02: `ECC-Tools/main` shipped `9566637` (`fix: prefer commit lookup over git ref resolution`). The PR-analysis fire is now fixed in the app repo by preferring explicit commit resolution before `git.getRef`, with regression coverage for pull refs and plain branch refs. Mirrored public tracking issue `#1184` in this repo was closed as resolved upstream.
|
||||
- 2026-04-02: Direct-ported the clean native-support core of `#1043` into `main`: `agents/csharp-reviewer.md`, `skills/dotnet-patterns/SKILL.md`, and `skills/csharp-testing/SKILL.md`. This fills the gap between existing C# rule/docs mentions and actual shipped C# review/testing guidance.
|
||||
- 2026-04-02: Direct-ported the clean native-support core of `#1055` into `main`: `agents/dart-build-resolver.md`, `commands/flutter-build.md`, `commands/flutter-review.md`, `commands/flutter-test.md`, `rules/dart/*`, and `skills/dart-flutter-patterns/SKILL.md`. The skill paths were wired into the current `framework-language` module instead of replaying the older PR's separate `flutter-dart` module layout.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — 智能体指令
|
||||
|
||||
这是一个**生产就绪的 AI 编码插件**,提供 39 个专业代理、175 项技能、72 条命令以及自动化钩子工作流,用于软件开发。
|
||||
这是一个**生产就绪的 AI 编码插件**,提供 39 个专业代理、177 项技能、72 条命令以及自动化钩子工作流,用于软件开发。
|
||||
|
||||
**版本:** 1.10.0
|
||||
|
||||
@@ -147,7 +147,7 @@
|
||||
|
||||
```
|
||||
agents/ — 39 个专业子代理
|
||||
skills/ — 175 个工作流技能和领域知识
|
||||
skills/ — 177 个工作流技能和领域知识
|
||||
commands/ — 72 个斜杠命令
|
||||
hooks/ — 基于触发的自动化
|
||||
rules/ — 始终遵循的指导方针(通用 + 每种语言)
|
||||
|
||||
@@ -209,7 +209,7 @@ npx ecc-install typescript
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**搞定!** 你现在可以使用 39 个智能体、175 项技能和 72 个命令了。
|
||||
**搞定!** 你现在可以使用 39 个智能体、177 项技能和 72 个命令了。
|
||||
|
||||
***
|
||||
|
||||
@@ -1096,7 +1096,7 @@ opencode
|
||||
|---------|-------------|----------|--------|
|
||||
| 智能体 | PASS: 39 个 | PASS: 12 个 | **Claude Code 领先** |
|
||||
| 命令 | PASS: 72 个 | PASS: 31 个 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 175 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 177 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多!** |
|
||||
| 规则 | PASS: 29 条 | PASS: 13 条指令 | **Claude Code 领先** |
|
||||
| MCP 服务器 | PASS: 14 个 | PASS: 完整 | **完全对等** |
|
||||
@@ -1208,7 +1208,7 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **智能体** | 39 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
|
||||
| **命令** | 72 | 共享 | 基于指令 | 31 |
|
||||
| **技能** | 175 | 共享 | 10 (原生格式) | 37 |
|
||||
| **技能** | 177 | 共享 | 10 (原生格式) | 37 |
|
||||
| **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
|
||||
| **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
|
||||
| **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |
|
||||
|
||||
@@ -325,8 +325,10 @@
|
||||
"description": "Connected-app operator workflows for setup audits, billing operations, program tracking, Google Workspace, and network optimization.",
|
||||
"paths": [
|
||||
"skills/automation-audit-ops",
|
||||
"skills/api-connector-builder",
|
||||
"skills/connections-optimizer",
|
||||
"skills/customer-billing-ops",
|
||||
"skills/dashboard-builder",
|
||||
"skills/ecc-tools-cost-audit",
|
||||
"skills/email-ops",
|
||||
"skills/finance-billing-ops",
|
||||
|
||||
121
skills/api-connector-builder/SKILL.md
Normal file
121
skills/api-connector-builder/SKILL.md
Normal file
@@ -0,0 +1,121 @@
|
||||
---
|
||||
name: api-connector-builder
|
||||
description: Build a new API connector or provider by matching the target repo's existing integration pattern exactly. Use when adding one more integration without inventing a second architecture.
|
||||
origin: ECC direct-port adaptation
|
||||
version: "1.0.0"
|
||||
---
|
||||
|
||||
# API Connector Builder
|
||||
|
||||
Use this when the job is to add a repo-native integration surface, not just a generic HTTP client.
|
||||
|
||||
The point is to match the host repository's pattern:
|
||||
|
||||
- connector layout
|
||||
- config schema
|
||||
- auth model
|
||||
- error handling
|
||||
- test style
|
||||
- registration/discovery wiring
|
||||
|
||||
## When to Use
|
||||
|
||||
- "Build a Jira connector for this project"
|
||||
- "Add a Slack provider following the existing pattern"
|
||||
- "Create a new integration for this API"
|
||||
- "Build a plugin that matches the repo's connector style"
|
||||
|
||||
## Guardrails
|
||||
|
||||
- do not invent a new integration architecture when the repo already has one
|
||||
- do not start from vendor docs alone; start from existing in-repo connectors first
|
||||
- do not stop at transport code if the repo expects registry wiring, tests, and docs
|
||||
- do not cargo-cult old connectors if the repo has a newer current pattern
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Learn the house style
|
||||
|
||||
Inspect at least 2 existing connectors/providers and map:
|
||||
|
||||
- file layout
|
||||
- abstraction boundaries
|
||||
- config model
|
||||
- retry / pagination conventions
|
||||
- registry hooks
|
||||
- test fixtures and naming
|
||||
|
||||
### 2. Narrow the target integration
|
||||
|
||||
Define only the surface the repo actually needs:
|
||||
|
||||
- auth flow
|
||||
- key entities
|
||||
- core read/write operations
|
||||
- pagination and rate limits
|
||||
- webhook or polling model
|
||||
|
||||
### 3. Build in repo-native layers
|
||||
|
||||
Typical slices:
|
||||
|
||||
- config/schema
|
||||
- client/transport
|
||||
- mapping layer
|
||||
- connector/provider entrypoint
|
||||
- registration
|
||||
- tests
|
||||
|
||||
### 4. Validate against the source pattern
|
||||
|
||||
The new connector should look obvious in the codebase, not imported from a different ecosystem.
|
||||
|
||||
## Reference Shapes
|
||||
|
||||
### Provider-style
|
||||
|
||||
```text
|
||||
providers/
|
||||
existing_provider/
|
||||
__init__.py
|
||||
provider.py
|
||||
config.py
|
||||
```
|
||||
|
||||
### Connector-style
|
||||
|
||||
```text
|
||||
integrations/
|
||||
existing/
|
||||
client.py
|
||||
models.py
|
||||
connector.py
|
||||
```
|
||||
|
||||
### TypeScript plugin-style
|
||||
|
||||
```text
|
||||
src/integrations/
|
||||
existing/
|
||||
index.ts
|
||||
client.ts
|
||||
types.ts
|
||||
test.ts
|
||||
```
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
- [ ] matches an existing in-repo integration pattern
|
||||
- [ ] config validation exists
|
||||
- [ ] auth and error handling are explicit
|
||||
- [ ] pagination/retry behavior follows repo norms
|
||||
- [ ] registry/discovery wiring is complete
|
||||
- [ ] tests mirror the host repo's style
|
||||
- [ ] docs/examples are updated if expected by the repo
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `backend-patterns`
|
||||
- `mcp-server-patterns`
|
||||
- `github-ops`
|
||||
|
||||
109
skills/dashboard-builder/SKILL.md
Normal file
109
skills/dashboard-builder/SKILL.md
Normal file
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: dashboard-builder
|
||||
description: Build monitoring dashboards that answer real operator questions for Grafana, SigNoz, and similar platforms. Use when turning metrics into a working dashboard instead of a vanity board.
|
||||
origin: ECC direct-port adaptation
|
||||
version: "1.0.0"
|
||||
---
|
||||
|
||||
# Dashboard Builder
|
||||
|
||||
Use this when the task is to build a dashboard people can operate from.
|
||||
|
||||
The goal is not "show every metric." The goal is to answer:
|
||||
|
||||
- is it healthy?
|
||||
- where is the bottleneck?
|
||||
- what changed?
|
||||
- what action should someone take?
|
||||
|
||||
## When to Use
|
||||
|
||||
- "Build a Kafka monitoring dashboard"
|
||||
- "Create a Grafana dashboard for Elasticsearch"
|
||||
- "Make a SigNoz dashboard for this service"
|
||||
- "Turn this metrics list into a real operational dashboard"
|
||||
|
||||
## Guardrails
|
||||
|
||||
- do not start from visual layout; start from operator questions
|
||||
- do not include every available metric just because it exists
|
||||
- do not mix health, throughput, and resource panels without structure
|
||||
- do not ship panels without titles, units, and sane thresholds
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Define the operating questions
|
||||
|
||||
Organize around:
|
||||
|
||||
- health / availability
|
||||
- latency / performance
|
||||
- throughput / volume
|
||||
- saturation / resources
|
||||
- service-specific risk
|
||||
|
||||
### 2. Study the target platform schema
|
||||
|
||||
Inspect existing dashboards first:
|
||||
|
||||
- JSON structure
|
||||
- query language
|
||||
- variables
|
||||
- threshold styling
|
||||
- section layout
|
||||
|
||||
### 3. Build the minimum useful board
|
||||
|
||||
Recommended structure:
|
||||
|
||||
1. overview
|
||||
2. performance
|
||||
3. resources
|
||||
4. service-specific section
|
||||
|
||||
### 4. Cut vanity panels
|
||||
|
||||
Every panel should answer a real question. If it does not, remove it.
|
||||
|
||||
## Example Panel Sets
|
||||
|
||||
### Elasticsearch
|
||||
|
||||
- cluster health
|
||||
- shard allocation
|
||||
- search latency
|
||||
- indexing rate
|
||||
- JVM heap / GC
|
||||
|
||||
### Kafka
|
||||
|
||||
- broker count
|
||||
- under-replicated partitions
|
||||
- messages in / out
|
||||
- consumer lag
|
||||
- disk and network pressure
|
||||
|
||||
### API gateway / ingress
|
||||
|
||||
- request rate
|
||||
- p50 / p95 / p99 latency
|
||||
- error rate
|
||||
- upstream health
|
||||
- active connections
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
- [ ] valid dashboard JSON
|
||||
- [ ] clear section grouping
|
||||
- [ ] titles and units are present
|
||||
- [ ] thresholds/status colors are meaningful
|
||||
- [ ] variables exist for common filters
|
||||
- [ ] default time range and refresh are sensible
|
||||
- [ ] no vanity panels with no operator value
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `research-ops`
|
||||
- `backend-patterns`
|
||||
- `terminal-ops`
|
||||
|
||||
Reference in New Issue
Block a user