mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-12 07:37:24 +08:00
feat: salvage production audit skill (#1732)
This commit is contained in:
@@ -11,7 +11,7 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"source": "./",
|
||||
"description": "The most comprehensive Claude Code plugin — 53 agents, 198 skills, 69 legacy command shims, selective install profiles, and production-ready hooks for TDD, security scanning, code review, and continuous learning",
|
||||
"description": "The most comprehensive Claude Code plugin — 53 agents, 199 skills, 69 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",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"version": "2.0.0-rc.1",
|
||||
"description": "Battle-tested Claude Code plugin for engineering teams — 53 agents, 198 skills, 69 legacy command shims, production-ready hooks, and selective install workflows evolved through continuous real-world use",
|
||||
"description": "Battle-tested Claude Code plugin for engineering teams — 53 agents, 199 skills, 69 legacy command shims, production-ready hooks, and selective install workflows evolved through continuous real-world use",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
"url": "https://x.com/affaanmustafa"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — Agent Instructions
|
||||
|
||||
This is a **production-ready AI coding plugin** providing 53 specialized agents, 198 skills, 69 commands, and automated hook workflows for software development.
|
||||
This is a **production-ready AI coding plugin** providing 53 specialized agents, 199 skills, 69 commands, and automated hook workflows for software development.
|
||||
|
||||
**Version:** 2.0.0-rc.1
|
||||
|
||||
@@ -146,7 +146,7 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
|
||||
|
||||
```
|
||||
agents/ — 53 specialized subagents
|
||||
skills/ — 198 workflow skills and domain knowledge
|
||||
skills/ — 199 workflow skills and domain knowledge
|
||||
commands/ — 69 slash commands
|
||||
hooks/ — Trigger-based automations
|
||||
rules/ — Always-follow guidelines (common + per-language)
|
||||
|
||||
@@ -350,7 +350,7 @@ If you stacked methods, clean up in this order:
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**That's it!** You now have access to 53 agents, 198 skills, and 69 legacy command shims.
|
||||
**That's it!** You now have access to 53 agents, 199 skills, and 69 legacy command shims.
|
||||
|
||||
### Dashboard GUI
|
||||
|
||||
@@ -1338,7 +1338,7 @@ The configuration is automatically detected from `.opencode/opencode.json`.
|
||||
|---------|-------------|----------|--------|
|
||||
| Agents | PASS: 53 agents | PASS: 12 agents | **Claude Code leads** |
|
||||
| Commands | PASS: 69 commands | PASS: 31 commands | **Claude Code leads** |
|
||||
| Skills | PASS: 198 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Skills | PASS: 199 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** |
|
||||
@@ -1443,7 +1443,7 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **Agents** | 53 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
|
||||
| **Commands** | 69 | Shared | Instruction-based | 31 |
|
||||
| **Skills** | 198 | Shared | 10 (native format) | 37 |
|
||||
| **Skills** | 199 | 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 |
|
||||
|
||||
@@ -160,7 +160,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**完成!** 你现在可以使用 53 个代理、198 个技能和 69 个命令。
|
||||
**完成!** 你现在可以使用 53 个代理、199 个技能和 69 个命令。
|
||||
|
||||
### multi-* 命令需要额外配置
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — 智能体指令
|
||||
|
||||
这是一个**生产就绪的 AI 编码插件**,提供 53 个专业代理、198 项技能、69 条命令以及自动化钩子工作流,用于软件开发。
|
||||
这是一个**生产就绪的 AI 编码插件**,提供 53 个专业代理、199 项技能、69 条命令以及自动化钩子工作流,用于软件开发。
|
||||
|
||||
**版本:** 2.0.0-rc.1
|
||||
|
||||
@@ -147,7 +147,7 @@
|
||||
|
||||
```
|
||||
agents/ — 53 个专业子代理
|
||||
skills/ — 198 个工作流技能和领域知识
|
||||
skills/ — 199 个工作流技能和领域知识
|
||||
commands/ — 69 个斜杠命令
|
||||
hooks/ — 基于触发的自动化
|
||||
rules/ — 始终遵循的指导方针(通用 + 每种语言)
|
||||
|
||||
@@ -224,7 +224,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**搞定!** 你现在可以使用 53 个智能体、198 项技能和 69 个命令了。
|
||||
**搞定!** 你现在可以使用 53 个智能体、199 项技能和 69 个命令了。
|
||||
|
||||
***
|
||||
|
||||
@@ -1134,7 +1134,7 @@ opencode
|
||||
|---------|-------------|----------|--------|
|
||||
| 智能体 | PASS: 53 个 | PASS: 12 个 | **Claude Code 领先** |
|
||||
| 命令 | PASS: 69 个 | PASS: 31 个 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 198 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 199 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多!** |
|
||||
| 规则 | PASS: 29 条 | PASS: 13 条指令 | **Claude Code 领先** |
|
||||
| MCP 服务器 | PASS: 14 个 | PASS: 完整 | **完全对等** |
|
||||
@@ -1242,7 +1242,7 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **智能体** | 53 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
|
||||
| **命令** | 69 | 共享 | 基于指令 | 31 |
|
||||
| **技能** | 198 | 共享 | 10 (原生格式) | 37 |
|
||||
| **技能** | 199 | 共享 | 10 (原生格式) | 37 |
|
||||
| **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
|
||||
| **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
|
||||
| **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |
|
||||
|
||||
@@ -214,6 +214,7 @@
|
||||
"skills/hookify-rules",
|
||||
"skills/iterative-retrieval",
|
||||
"skills/plankton-code-quality",
|
||||
"skills/production-audit",
|
||||
"skills/skill-stocktake",
|
||||
"skills/strategic-compact",
|
||||
"skills/tdd-workflow",
|
||||
|
||||
@@ -200,6 +200,7 @@
|
||||
"skills/plankton-code-quality/",
|
||||
"skills/postgres-patterns/",
|
||||
"skills/product-capability/",
|
||||
"skills/production-audit/",
|
||||
"skills/production-scheduling/",
|
||||
"skills/project-flow-ops/",
|
||||
"skills/prompt-optimizer/",
|
||||
|
||||
206
skills/production-audit/SKILL.md
Normal file
206
skills/production-audit/SKILL.md
Normal file
@@ -0,0 +1,206 @@
|
||||
---
|
||||
name: production-audit
|
||||
description: Local-evidence production readiness audit for shipped apps, pre-launch reviews, post-merge checks, and "what breaks in prod?" questions without sending repo data to an external audit service.
|
||||
origin: community
|
||||
---
|
||||
|
||||
# Production Audit
|
||||
|
||||
Use this skill when the user asks whether an application is ready to ship, what
|
||||
could break in production, or what must be fixed before a launch. This is a
|
||||
maintainer-safe rewrite of the stale community production-audit idea: it keeps
|
||||
the useful production-readiness lens and removes unpinned external execution and
|
||||
third-party data sharing.
|
||||
|
||||
## When to Use
|
||||
|
||||
- The user asks "is this production-ready", "what would break in prod", "what
|
||||
did we miss", "audit this repo", or "ready to ship?"
|
||||
- A feature was merged and needs a pre-deploy or post-merge risk pass.
|
||||
- A public launch, demo, customer rollout, or investor walkthrough is close.
|
||||
- CI is green but the user wants production risk, not only test status.
|
||||
- A deployed URL, release branch, PR, or current checkout is available for
|
||||
evidence gathering.
|
||||
|
||||
## When Not to Use
|
||||
|
||||
- During active implementation when the right lens is line-level secure coding;
|
||||
use `security-review` first.
|
||||
- For pure libraries, templates, docs-only repos, or scaffolds unless the user
|
||||
wants packaging/release readiness rather than application readiness.
|
||||
- When the user asks for a formal compliance audit. This skill is engineering
|
||||
triage, not legal, financial, medical, or regulatory certification.
|
||||
- When the only available evidence is a product idea with no repo, deployment,
|
||||
CI, or runtime surface.
|
||||
|
||||
## How It Works
|
||||
|
||||
Build the audit from local and user-authorized evidence. Do not run unpinned
|
||||
remote code, upload repository contents to third-party services, or call
|
||||
external scanners unless the user explicitly approves that specific tool and
|
||||
data flow.
|
||||
|
||||
Use this order:
|
||||
|
||||
1. Establish the release surface.
|
||||
2. Read recent changes and current branch state.
|
||||
3. Inspect runtime, auth, data, payment, background-job, AI, and deployment
|
||||
boundaries that actually exist in the repo.
|
||||
4. Check CI, tests, migrations, environment documentation, and rollback path.
|
||||
5. Produce a short ship/block recommendation with specific fixes.
|
||||
|
||||
## Evidence Checklist
|
||||
|
||||
Start with cheap, local signals:
|
||||
|
||||
```text
|
||||
git status --short --branch
|
||||
git log --oneline --decorate -20
|
||||
git diff --stat origin/main...HEAD
|
||||
```
|
||||
|
||||
Then inspect the project-specific surface:
|
||||
|
||||
- Package scripts, CI workflows, release scripts, Docker files, and deployment
|
||||
manifests.
|
||||
- API routes, webhooks, auth middleware, background workers, cron jobs, and
|
||||
database migrations.
|
||||
- Environment variable documentation and startup checks.
|
||||
- Observability hooks, error reporting, logs, health checks, and dashboards.
|
||||
- Rollback, seed, migration, and backfill instructions.
|
||||
- E2E coverage for the user paths that matter most.
|
||||
|
||||
If a deployed URL is in scope, use browser or HTTP checks only against that URL
|
||||
and avoid credentialed actions unless the user supplies a safe test account.
|
||||
|
||||
## Risk Lenses
|
||||
|
||||
### Security And Auth
|
||||
|
||||
- Are public routes, API routes, and admin routes clearly separated?
|
||||
- Are auth and authorization enforced server-side?
|
||||
- Are secrets kept out of client bundles, logs, example output, and checked-in
|
||||
files?
|
||||
- Are rate limits, CSRF protections, CORS policy, and upload validation present
|
||||
where the app needs them?
|
||||
- Does the AI or agent surface defend against prompt injection, tool abuse, and
|
||||
untrusted content crossing into privileged actions?
|
||||
|
||||
### Data Integrity
|
||||
|
||||
- Do migrations run forward cleanly and have a rollback or recovery plan?
|
||||
- Are destructive migrations, backfills, and data imports staged safely?
|
||||
- Do database policies, grants, and service-role boundaries match the app's
|
||||
tenancy model?
|
||||
- Are retries idempotent for writes, jobs, and webhook handlers?
|
||||
|
||||
### Payments And Webhooks
|
||||
|
||||
- Are webhook signatures verified before parsing trusted payload fields?
|
||||
- Is each payment, subscription, or fulfillment webhook idempotent?
|
||||
- Are replay, duplicate delivery, and out-of-order delivery handled?
|
||||
- Are test-mode and live-mode credentials separated?
|
||||
|
||||
### Operations
|
||||
|
||||
- Can the app start from a clean checkout using documented commands?
|
||||
- Are required environment variables named, validated, and fail-fast?
|
||||
- Is there a health check that proves dependencies are reachable?
|
||||
- Are deploy, rollback, and incident-owner paths documented?
|
||||
- Are logs useful without leaking secrets or personal data?
|
||||
|
||||
### User Experience
|
||||
|
||||
- Are the launch-critical paths covered on desktop and mobile?
|
||||
- Are forms usable on mobile without input zoom, layout overlap, or blocked
|
||||
submission states?
|
||||
- Do loading, empty, error, and permission-denied states tell the user what
|
||||
happened?
|
||||
- Is there a support or recovery path when a critical operation fails?
|
||||
|
||||
## Scoring
|
||||
|
||||
Use scores to force prioritization, not to imply mathematical certainty.
|
||||
|
||||
| Band | Score | Meaning |
|
||||
| --- | --- | --- |
|
||||
| Blocked | 0-49 | Do not ship until the top risks are fixed |
|
||||
| Risky | 50-69 | Ship only behind a small rollout or internal beta |
|
||||
| Launchable With Caveats | 70-84 | Ship if owners accept the listed risks |
|
||||
| Strong | 85-100 | No obvious launch blockers from available evidence |
|
||||
|
||||
Cap the score at `69` if any of these are true:
|
||||
|
||||
- Authentication or authorization is missing on sensitive data.
|
||||
- Payment or fulfillment webhooks are not idempotent.
|
||||
- Required migrations cannot be run safely.
|
||||
- Secrets are exposed in client bundles, logs, or committed files.
|
||||
- There is no rollback path for a high-impact release.
|
||||
|
||||
Cap the score at `84` if CI is not green or the launch-critical path was not
|
||||
tested end to end.
|
||||
|
||||
## Output Format
|
||||
|
||||
Lead with one sentence:
|
||||
|
||||
```text
|
||||
Production audit: 76/100, launchable with caveats, with webhook idempotency and rollback docs as the two risks to fix before public launch.
|
||||
```
|
||||
|
||||
Then list:
|
||||
|
||||
- `Blockers`: must-fix items before deploy.
|
||||
- `High-value fixes`: next fixes if the user wants to improve the score.
|
||||
- `Evidence checked`: files, commands, CI, deployed URL, or PRs inspected.
|
||||
- `Evidence missing`: what would change confidence if provided.
|
||||
- `Next action`: one concrete fix or verification step.
|
||||
|
||||
Keep strengths short. The user asked for readiness, so the useful answer is the
|
||||
remaining risk and the next action.
|
||||
|
||||
## Example
|
||||
|
||||
User:
|
||||
|
||||
```text
|
||||
is this ready to ship?
|
||||
```
|
||||
|
||||
Response:
|
||||
|
||||
```text
|
||||
Production audit: 68/100, risky, because Stripe webhooks are verified but not idempotent and there is no rollback note for the pending migration.
|
||||
|
||||
Blockers:
|
||||
- Add idempotency for `checkout.session.completed` before fulfilling orders.
|
||||
- Write and test the rollback path for `20260511_add_billing_state.sql`.
|
||||
|
||||
High-value fixes:
|
||||
- Add a health check that verifies database and payment-provider reachability.
|
||||
- Add one E2E path for upgrade, webhook fulfillment, and billing-page refresh.
|
||||
|
||||
Evidence checked:
|
||||
- `api/stripe/webhook.ts`
|
||||
- `db/migrations/20260511_add_billing_state.sql`
|
||||
- GitHub Actions run for the release branch
|
||||
|
||||
Next action: Want me to patch webhook idempotency first?
|
||||
```
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- Running `npx <package>@latest` or a remote scanner as the default audit path.
|
||||
- Uploading source, secrets, customer data, or private topology to an external
|
||||
audit service without explicit approval.
|
||||
- Producing a score without naming the evidence checked.
|
||||
- Treating green CI as production readiness.
|
||||
- Ending with a generic "let me know what you want to do."
|
||||
|
||||
## See Also
|
||||
|
||||
- Skill: `security-review`
|
||||
- Skill: `deployment-patterns`
|
||||
- Skill: `e2e-testing`
|
||||
- Skill: `tdd-workflow`
|
||||
- Skill: `verification-loop`
|
||||
Reference in New Issue
Block a user