docs: salvage remaining stable zh-CN skill translations

Port the current-source-safe command documentation subset from stale PR #1687.\n\nEach copied command page maps to an English source file unchanged since the stale PR base; fastapi-review remains deferred because #1687 did not include a matching zh-CN translation.

.claude-plugin/marketplace.json

@@ -11,7 +11,7 @@
     {
       "name": "ecc",
       "source": "./",
-      "description": "The most comprehensive Claude Code plugin — 50 agents, 188 skills, 68 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, 203 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",

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "ecc",
   "version": "2.0.0-rc.1",
-  "description": "Battle-tested Claude Code plugin for engineering teams — 50 agents, 188 skills, 68 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, 203 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"

.codex-plugin/README.md

@@ -12,7 +12,7 @@ This directory contains the **Codex plugin manifest** for Everything Claude Code
 
 ## What This Provides
 
-- **185 skills** from `./skills/` — reusable Codex workflows for TDD, security,
+- **200 skills** from `./skills/` — reusable Codex workflows for TDD, security,
   code review, architecture, and more
 - **6 MCP servers** — GitHub, Context7, Exa, Memory, Playwright, Sequential Thinking
 

.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "ecc",
   "version": "2.0.0-rc.1",
-  "description": "Battle-tested Codex workflows — 185 shared ECC skills, production-ready MCP configs, and selective-install-aligned conventions for TDD, security scanning, code review, and autonomous development.",
+  "description": "Battle-tested Codex workflows — 200 shared ECC skills, production-ready MCP configs, and selective-install-aligned conventions for TDD, security scanning, code review, and autonomous development.",
   "author": {
     "name": "Affaan Mustafa",
     "email": "me@affaanmustafa.com",
@@ -15,7 +15,7 @@
   "mcpServers": "./.mcp.json",
   "interface": {
     "displayName": "Everything Claude Code",
-    "shortDescription": "185 battle-tested ECC skills plus MCP configs for TDD, security, code review, and autonomous development.",
+    "shortDescription": "200 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.",
     "developerName": "Affaan Mustafa",
     "category": "Productivity",

.opencode/opencode.json

@@ -22,6 +22,11 @@
   "plugin": [
     "./plugins"
   ],
+  "skills": {
+    "paths": [
+      "../skills"
+    ]
+  },
   "agent": {
     "build": {
       "description": "Primary coding agent for development work",

.qwen/QWEN.md

@@ -0,0 +1,25 @@
+# Qwen CLI Configuration
+
+This directory contains ECC's Qwen CLI install template.
+
+## Runtime Location
+
+The source `.qwen/` directory in this repository is copied into a user's home-level `~/.qwen/` install root when running:
+
+```bash
+./install.sh --target qwen --profile minimal
+```
+
+The managed install also writes `~/.qwen/ecc-install-state.json` so future ECC updates and uninstalls can distinguish ECC-owned files from user-owned Qwen configuration.
+
+## Installed Surface
+
+The Qwen target installs the same managed manifest modules used by other harness adapters:
+
+- `rules/`
+- `agents/`
+- `commands/`
+- `skills/`
+- `mcp-configs/`
+
+Hook runtime files are intentionally not selected for Qwen until the Qwen hook/event contract is verified.

AGENTS.md

@@ -1,6 +1,6 @@
 # Everything Claude Code (ECC) — Agent Instructions
 
-This is a **production-ready AI coding plugin** providing 50 specialized agents, 188 skills, 68 commands, and automated hook workflows for software development.
+This is a **production-ready AI coding plugin** providing 53 specialized agents, 203 skills, 69 commands, and automated hook workflows for software development.
 
 **Version:** 2.0.0-rc.1
 
@@ -145,9 +145,9 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
 ## Project Structure
 
 ```
-agents/          — 50 specialized subagents
-skills/          — 188 workflow skills and domain knowledge
-commands/        — 68 slash commands
+agents/          — 53 specialized subagents
+skills/          — 203 workflow skills and domain knowledge
+commands/        — 69 slash commands
 hooks/           — Trigger-based automations
 rules/           — Always-follow guidelines (common + per-language)
 scripts/         — Cross-platform Node.js utilities

README.md

@@ -89,11 +89,12 @@ This repo is the raw code only. The guides explain everything.
 ### v2.0.0-rc.1 — Surface Refresh, Operator Workflows, and ECC 2.0 Alpha (Apr 2026)
 
 - **Dashboard GUI** — New Tkinter-based desktop application (`ecc_dashboard.py` or `npm run dashboard`) with dark/light theme toggle, font customization, and project logo in header and taskbar.
-- **Public surface synced to the live repo** — metadata, catalog counts, plugin manifests, and install-facing docs now match the actual OSS surface: 48 agents, 185 skills, and 68 legacy command shims.
+- **Public surface synced to the live repo** — metadata, catalog counts, plugin manifests, and install-facing docs now match the actual OSS surface: 53 agents, 203 skills, and 69 legacy command shims.
 - **Operator and outbound workflow expansion** — `brand-voice`, `social-graph-ranker`, `connections-optimizer`, `customer-billing-ops`, `ecc-tools-cost-audit`, `google-workspace-ops`, `project-flow-ops`, and `workspace-surface-audit` round out the operator lane.
 - **Media and launch tooling** — `manim-video`, `remotion-video-creation`, and upgraded social publishing surfaces make technical explainers and launch content part of the same system.
 - **Framework and product surface growth** — `nestjs-patterns`, richer Codex/OpenCode install surfaces, and expanded cross-harness packaging keep the repo usable beyond Claude Code alone.
 - **ECC 2.0 alpha is in-tree** — the Rust control-plane prototype in `ecc2/` now builds locally and exposes `dashboard`, `start`, `sessions`, `status`, `stop`, `resume`, and `daemon` commands. It is usable as an alpha, not yet a general release.
+- **Operator status snapshots** — `ecc status --markdown --write status.md` turns the local state store into a portable handoff covering readiness, active sessions, skill-run health, install health, pending governance events, and linked work items from Linear/GitHub/handoffs. Use `ecc work-items upsert ...` for manual entries, `ecc work-items sync-github --repo owner/repo` for PR/issue queue state, and `ecc status --exit-code` to fail automation when readiness needs attention.
 - **Ecosystem hardening** — AgentShield, ECC Tools cost controls, billing portal work, and website refreshes continue to ship around the core plugin instead of drifting into separate silos.
 
 ### v1.9.0 — Selective Install & Language Expansion (Mar 2026)
@@ -350,7 +351,7 @@ If you stacked methods, clean up in this order:
 /plugin list ecc@ecc
 ```
 
-**That's it!** You now have access to 50 agents, 188 skills, and 68 legacy command shims.
+**That's it!** You now have access to 53 agents, 203 skills, and 69 legacy command shims.
 
 ### Dashboard GUI
 
@@ -448,7 +449,7 @@ everything-claude-code/
 |   |-- plugin.json         # Plugin metadata and component paths
 |   |-- marketplace.json    # Marketplace catalog for /plugin marketplace add
 |
-|-- agents/           # 50 specialized subagents for delegation
+|-- agents/           # 53 specialized subagents for delegation
 |   |-- planner.md           # Feature implementation planning
 |   |-- architect.md         # System design decisions
 |   |-- tdd-guide.md         # Test-driven development
@@ -1082,6 +1083,8 @@ Yes. ECC is cross-platform:
 - **OpenCode**: Full plugin support in `.opencode/`. See [OpenCode Support](#opencode-support).
 - **Codex**: First-class support for both macOS app and CLI, with adapter drift guards and SessionStart fallback. See PR [#257](https://github.com/affaan-m/everything-claude-code/pull/257).
 - **Antigravity**: Tightly integrated setup for workflows, skills, and flattened rules in `.agent/`. See [Antigravity Guide](docs/ANTIGRAVITY-GUIDE.md).
+- **JoyCode / CodeBuddy**: Project-local selective install adapters for commands, agents, skills, and flattened rules. See [JoyCode Adapter Guide](docs/JOYCODE-GUIDE.md).
+- **Qwen CLI**: Home-directory selective install adapter for commands, agents, skills, rules, and Qwen config. See [Qwen CLI Adapter Guide](docs/QWEN-GUIDE.md).
 - **Non-native harnesses**: Manual fallback path for Grok and similar interfaces. See [Manual Adaptation Guide](docs/MANUAL-ADAPTATION-GUIDE.md).
 - **Claude Code**: Native — this is the primary target.
 </details>
@@ -1336,9 +1339,9 @@ The configuration is automatically detected from `.opencode/opencode.json`.
 
 | Feature | Claude Code | OpenCode | Status |
 |---------|-------------|----------|--------|
-| Agents | PASS: 50 agents | PASS: 12 agents | **Claude Code leads** |
-| Commands | PASS: 68 commands | PASS: 31 commands | **Claude Code leads** |
-| Skills | PASS: 188 skills | PASS: 37 skills | **Claude Code leads** |
+| Agents | PASS: 53 agents | PASS: 12 agents | **Claude Code leads** |
+| Commands | PASS: 69 commands | PASS: 31 commands | **Claude Code leads** |
+| Skills | PASS: 203 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** |
@@ -1441,9 +1444,9 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
 
 | Feature | Claude Code | Cursor IDE | Codex CLI | OpenCode |
 |---------|------------|------------|-----------|----------|
-| **Agents** | 50 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
-| **Commands** | 68 | Shared | Instruction-based | 31 |
-| **Skills** | 188 | Shared | 10 (native format) | 37 |
+| **Agents** | 53 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
+| **Commands** | 69 | Shared | Instruction-based | 31 |
+| **Skills** | 203 | 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 |

README.zh-CN.md

@@ -160,7 +160,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
 /plugin list ecc@ecc
 ```
 
-**完成！** 你现在可以使用 50 个代理、188 个技能和 68 个命令。
+**完成！** 你现在可以使用 53 个代理、203 个技能和 69 个命令。
 
 ### multi-* 命令需要额外配置
 

agent.yaml

@@ -152,6 +152,7 @@ commands:
   - cpp-review
   - cpp-test
   - evolve
+  - fastapi-review
   - feature-dev
   - flutter-build
   - flutter-review

agents/fastapi-reviewer.md

@@ -0,0 +1,70 @@
+---
+name: fastapi-reviewer
+description: Reviews FastAPI applications for async correctness, dependency injection, Pydantic schemas, security, OpenAPI quality, testing, and production readiness.
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+You are a senior FastAPI reviewer focused on production Python APIs.
+
+## Review Scope
+
+- FastAPI app construction, routing, middleware, and exception handling.
+- Pydantic request, update, and response models.
+- Async database and HTTP patterns.
+- Dependency injection for database sessions, auth, pagination, and settings.
+- Authentication, authorization, CORS, rate limits, logging, and secret handling.
+- Test dependency overrides and client setup.
+- OpenAPI metadata and generated docs.
+
+## Out of Scope
+
+- Non-FastAPI frameworks unless they directly interact with the FastAPI app.
+- Broad Python style review already covered by `python-reviewer`.
+- Dependency additions without a concrete problem and maintenance rationale.
+
+## Review Workflow
+
+1. Locate the app entry point, usually `main.py`, `app.py`, or `app/main.py`.
+2. Identify routers, schemas, dependencies, database session setup, and tests.
+3. Run available local checks when safe, such as `pytest`, `ruff`, `mypy`, or `uv run pytest`.
+4. Review the changed files first, then inspect adjacent definitions needed to prove findings.
+5. Report only actionable issues with file and line references when available.
+
+## Finding Priorities
+
+### Critical
+
+- Hardcoded secrets or tokens.
+- SQL built through string interpolation.
+- Passwords, token hashes, or internal auth fields exposed in response models.
+- Auth dependencies that can be bypassed or do not validate expiry/signature.
+
+### High
+
+- Blocking database or HTTP clients inside async routes.
+- Database sessions created inline in handlers instead of dependencies.
+- Test overrides targeting the wrong dependency.
+- `allow_origins=["*"]` combined with credentialed CORS.
+- Missing request validation for write endpoints.
+
+### Medium
+
+- Missing pagination on list endpoints.
+- OpenAPI docs missing response models or error response descriptions.
+- Duplicated route logic that should move into a service/dependency.
+- Missing timeout settings for external HTTP clients.
+
+## Output Format
+
+```text
+[SEVERITY] Short issue title
+File: path/to/file.py:42
+Issue: What is wrong and why it matters.
+Fix: Concrete change to make.
+```
+
+End with:
+
+- `Tests checked:` commands run or why they were skipped.
+- `Residual risk:` anything important that could not be verified.

agents/network-config-reviewer.md

@@ -0,0 +1,97 @@
+---
+name: network-config-reviewer
+description: Reviews router and switch configurations for security, correctness, stale references, risky change-window commands, and missing operational guardrails.
+tools: ["Read", "Grep"]
+model: sonnet
+---
+
+You are a senior network configuration reviewer. You audit proposed or existing
+router and switch configuration and return prioritized findings with evidence.
+
+## Scope
+
+- Cisco IOS and IOS-XE style running configuration.
+- Interface, VLAN, ACL, VTY, AAA, SNMP, NTP, logging, routing, and banner blocks.
+- Proposed change snippets that will be pasted into a change window.
+- Read-only review only. Do not apply configuration or suggest live testing that
+  removes protections.
+
+## Review Workflow
+
+1. Identify the device role, platform, and change intent if they are present.
+2. Parse configuration sections: interfaces, routing, ACLs, line vty, AAA, SNMP,
+   logging, NTP, and banners.
+3. Check the proposed change first, then adjacent existing config needed to prove
+   a finding.
+4. Report only findings with enough evidence to act on.
+5. Separate hard blockers from best-practice improvements.
+
+## Severity Guide
+
+### Critical
+
+- Plaintext or default credentials.
+- `snmp-server community public` or `private`, especially with write access.
+- Telnet-only management or internet-facing VTY access with no source restriction.
+- Proposed destructive commands such as `reload`, `erase`, `format`, broad
+  `no interface`, or removing an entire routing process without rollback context.
+
+### High
+
+- SSH v1, weak enable password usage, missing AAA where the environment expects it.
+- ACLs referenced by interfaces or routing policy but not defined.
+- Route-maps, prefix-lists, or community-lists referenced by BGP but not defined.
+- Subnet overlaps or duplicate interface IPs.
+
+### Medium
+
+- No NTP, timestamps, remote logging, or saved rollback evidence.
+- Management-plane access not limited to a management subnet.
+- Missing descriptions on important uplinks, trunks, or routed links.
+
+### Low
+
+- Naming, comment, and documentation cleanup.
+- Suggested monitoring additions that are not required for the change to be safe.
+
+## Output Format
+
+```text
+## Network Configuration Review: <hostname or unknown device>
+
+### Critical
+[CRITICAL-1] <finding>
+File/section: <line or block>
+Evidence: <specific config snippet or command>
+Risk: <what can break or be exposed>
+Fix: <safe remediation or change-window prerequisite>
+
+### High
+...
+
+### Summary
+| Severity | Count |
+| --- | ---: |
+| Critical | 0 |
+| High | 0 |
+| Medium | 0 |
+| Low | 0 |
+
+Verdict: PASS | WARNING | BLOCK
+Tests checked: <what was inspected>
+Residual risk: <what could not be verified>
+```
+
+Use `BLOCK` for any Critical finding or proposed destructive change without a
+rollback plan. Use `WARNING` for High or Medium findings that do not block a
+maintenance window by themselves. Use `PASS` only when no actionable findings are
+present.
+
+## Safety Rules
+
+- Do not recommend removing ACLs, disabling firewall rules, or opening VTY access
+  as a diagnostic shortcut.
+- Prefer read-only confirmation commands such as `show running-config`,
+  `show ip access-lists`, `show ip route`, `show logging`, and `show interfaces`.
+- If a command changes device state, label it as a proposed fix and require a
+  maintenance window, rollback plan, and verification step.

agents/network-troubleshooter.md

@@ -0,0 +1,119 @@
+---
+name: network-troubleshooter
+description: Diagnoses network connectivity, routing, DNS, interface, and policy symptoms with a read-only OSI-layer workflow and evidence-backed root cause summary.
+tools: ["Read", "Bash", "Grep"]
+model: sonnet
+---
+
+You are a senior network troubleshooting agent. You diagnose symptoms
+systematically and produce a concise root cause summary with evidence.
+
+## Scope
+
+- Connectivity, packet loss, slow links, DNS failures, route reachability, BGP
+  neighbor state, VLAN reachability, and ACL/firewall symptoms.
+- Router, switch, Linux host, and homelab environments.
+- Read-only diagnosis. Do not apply configuration changes while diagnosing.
+
+## Workflow
+
+1. Characterize the symptom.
+   - What fails?
+   - Who is affected?
+   - When did it start?
+   - What changed recently?
+2. Pick the starting layer, then work downward or upward as evidence requires.
+3. Ask for missing command output only when it changes the diagnosis.
+4. Confirm that the suspected cause explains all observed symptoms.
+5. End with a root cause summary and verification plan.
+
+## Layer Checks
+
+### Layer 1 and 2
+
+Use for link-down, packet loss, CRCs, drops, and VLAN mismatch symptoms.
+
+```text
+show interfaces <interface> status
+show interfaces <interface>
+show vlan brief
+show spanning-tree vlan <id>
+```
+
+Look for down/down state, CRC counters increasing, duplex mismatch, wrong access
+VLAN, blocked spanning-tree state, or trunk VLANs missing from the allowed list.
+
+### Layer 3
+
+Use for gateway, routing, and reachability symptoms.
+
+```text
+show ip interface brief
+show ip route <destination>
+ping <destination> source <interface-or-ip>
+traceroute <destination> source <interface-or-ip>
+```
+
+Look for missing connected routes, wrong next hop, asymmetric routing, stale static
+routes, or a default route that points to the wrong upstream.
+
+### DNS
+
+Use when IP connectivity works but names fail.
+
+```text
+dig @<local-dns> <name>
+dig @<known-good-resolver> <name>
+nslookup <name> <local-dns>
+```
+
+If public DNS works but local DNS fails, focus on the resolver, DHCP DNS option,
+firewall rules to UDP/TCP 53, or local zones.
+
+### Policy And Firewall
+
+Use read-only counters and logs. Do not remove policy to test.
+
+```text
+show ip access-lists <name>
+show running-config interface <interface>
+show logging | include <interface>|ACL|DENY|DROP
+```
+
+If a deny counter increments for the failing flow, propose a narrow allow rule and
+verification step instead of disabling the ACL.
+
+## Output Format
+
+```text
+## Diagnosis: <one-line likely root cause>
+
+Symptom: <reported failure>
+Affected scope: <host, VLAN, subnet, site, or unknown>
+Layer: <where the fault was found>
+
+Evidence:
+- `<command>` -> <what it proved>
+- `<command>` -> <what it ruled out>
+
+Root cause:
+<specific explanation>
+
+Recommended fix:
+1. <safe action or config change to schedule>
+2. <rollback or maintenance note if relevant>
+
+Verification:
+- `<command>` should show <expected result>
+
+Residual risk:
+<what still needs device access, logs, or timing evidence>
+```
+
+## Guardrails
+
+- Prefer evidence over guesses.
+- Never recommend temporarily removing ACLs, firewall rules, authentication, or
+  management-plane restrictions.
+- If a live command changes state, label it clearly as a remediation step, not a
+  diagnostic command.

commands/fastapi-review.md

@@ -0,0 +1,39 @@
+---
+description: Review a FastAPI application for architecture, async correctness, dependency injection, Pydantic schemas, security, performance, and testability.
+---
+
+# FastAPI Review
+
+Invoke the `fastapi-reviewer` agent for a focused FastAPI review.
+
+## Usage
+
+```text
+/fastapi-review [file-or-directory]
+```
+
+## Review Areas
+
+- App factory, router boundaries, middleware, and exception handlers.
+- Pydantic request and response schema separation.
+- Dependency injection for database sessions, auth, pagination, and settings.
+- Async database and external HTTP patterns.
+- CORS, auth, rate limits, logging, and secret handling.
+- OpenAPI metadata and documented response models.
+- Test client setup and dependency overrides.
+
+## Expected Output
+
+```text
+[SEVERITY] Short issue title
+File: path/to/file.py:42
+Issue: What is wrong and why it matters.
+Fix: Concrete change to make.
+```
+
+## Related
+
+- Agent: `fastapi-reviewer`
+- Skill: `fastapi-patterns`
+- Command: `/python-review`
+- Skill: `security-scan`

docs/JOYCODE-GUIDE.md

@@ -0,0 +1,55 @@
+# JoyCode Adapter Guide
+
+JoyCode can consume ECC through the selective installer. The adapter installs shared ECC commands, agents, skills, and flattened rules into a project-local `.joycode/` directory.
+
+## Install
+
+Preview the install plan:
+
+```bash
+node scripts/install-plan.js --target joycode --profile full
+```
+
+Apply it to the current project:
+
+```bash
+node scripts/install-apply.js --target joycode --profile full
+```
+
+For a smaller install, select modules explicitly:
+
+```bash
+node scripts/install-apply.js --target joycode --modules rules-core,commands-core,workflow-quality
+```
+
+## Layout
+
+The project adapter writes managed files under:
+
+```text
+.joycode/
+  agents/
+  commands/
+  rules/
+  skills/
+  mcp-configs/
+  scripts/
+  ecc-install-state.json
+```
+
+Rules are flattened into namespaced filenames so a JoyCode project does not receive nested rule directories such as `rules/common/coding-style.md`. Commands, agents, and skills keep the same structure they use elsewhere in ECC.
+The full profile also includes shared MCP and setup helper files that other ECC project-local adapters use.
+
+## Uninstall
+
+Use ECC's managed uninstall path instead of deleting files by hand:
+
+```bash
+node scripts/uninstall.js --target joycode
+```
+
+The uninstall command reads `.joycode/ecc-install-state.json` and removes only files that ECC installed. User-created JoyCode files are preserved.
+
+## Source PR
+
+This adapter salvages the useful project-local JoyCode intent from stale PR #1429 while replacing the standalone shell installer with ECC's current install-state and uninstall machinery.

docs/QWEN-GUIDE.md

@@ -0,0 +1,54 @@
+# Qwen CLI Adapter Guide
+
+ECC can install its managed command, agent, skill, rule, and MCP surfaces into the Qwen CLI home directory.
+
+## Install
+
+From the ECC repository root:
+
+```bash
+./install.sh --target qwen --profile minimal
+```
+
+Preview a larger install before copying files:
+
+```bash
+./install.sh --target qwen --profile full --dry-run
+```
+
+The Qwen adapter writes into `~/.qwen/` and records managed file ownership in `~/.qwen/ecc-install-state.json`.
+
+## Installed Layout
+
+The managed install can populate:
+
+```text
+~/.qwen/
+  QWEN.md
+  agents/
+  commands/
+  mcp-configs/
+  rules/
+  skills/
+  ecc-install-state.json
+```
+
+The installer preserves the source layout for rules, so language rule sets stay under paths such as `~/.qwen/rules/common/` and `~/.qwen/rules/typescript/`.
+
+## Updating
+
+Rerun the same install command after pulling ECC updates. The installer uses the install-state file to update ECC-managed files without claiming unrelated user files in `~/.qwen/`.
+
+## Uninstalling
+
+Use the managed uninstall path rather than deleting the whole Qwen directory:
+
+```bash
+node scripts/uninstall.js --target qwen
+```
+
+That removes files recorded in `~/.qwen/ecc-install-state.json` and leaves unrelated Qwen configuration alone.
+
+## Scope
+
+This target is intentionally narrower than stale PR #1352. It ports the maintainable Qwen install-target intent onto the current selective installer and avoids unverified hook-runtime claims until Qwen's hook/event contract is confirmed.

docs/zh-CN/AGENTS.md

@@ -1,6 +1,6 @@
 # Everything Claude Code (ECC) — 智能体指令
 
-这是一个**生产就绪的 AI 编码插件**，提供 50 个专业代理、188 项技能、68 条命令以及自动化钩子工作流，用于软件开发。
+这是一个**生产就绪的 AI 编码插件**，提供 53 个专业代理、203 项技能、69 条命令以及自动化钩子工作流，用于软件开发。
 
 **版本:** 2.0.0-rc.1
 
@@ -146,9 +146,9 @@
 ## 项目结构
 
 ```
-agents/          — 50 个专业子代理
-skills/          — 188 个工作流技能和领域知识
-commands/        — 68 个斜杠命令
+agents/          — 53 个专业子代理
+skills/          — 203 个工作流技能和领域知识
+commands/        — 69 个斜杠命令
 hooks/           — 基于触发的自动化
 rules/           — 始终遵循的指导方针（通用 + 每种语言）
 scripts/         — 跨平台 Node.js 实用工具

docs/zh-CN/README.md

@@ -224,7 +224,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
 /plugin list ecc@ecc
 ```
 
-**搞定！** 你现在可以使用 50 个智能体、188 项技能和 68 个命令了。
+**搞定！** 你现在可以使用 53 个智能体、203 项技能和 69 个命令了。
 
 ***
 
@@ -1132,9 +1132,9 @@ opencode
 
 | 功能特性 | Claude Code | OpenCode | 状态 |
 |---------|-------------|----------|--------|
-| 智能体 | PASS: 50 个 | PASS: 12 个 | **Claude Code 领先** |
-| 命令 | PASS: 68 个 | PASS: 31 个 | **Claude Code 领先** |
-| 技能 | PASS: 188 项 | PASS: 37 项 | **Claude Code 领先** |
+| 智能体 | PASS: 53 个 | PASS: 12 个 | **Claude Code 领先** |
+| 命令 | PASS: 69 个 | PASS: 31 个 | **Claude Code 领先** |
+| 技能 | PASS: 203 项 | PASS: 37 项 | **Claude Code 领先** |
 | 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多！** |
 | 规则 | PASS: 29 条 | PASS: 13 条指令 | **Claude Code 领先** |
 | MCP 服务器 | PASS: 14 个 | PASS: 完整 | **完全对等** |
@@ -1240,9 +1240,9 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
 
 | 功能特性 | Claude Code | Cursor IDE | Codex CLI | OpenCode |
 |---------|------------|------------|-----------|----------|
-| **智能体** | 50 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
-| **命令** | 68 | 共享 | 基于指令 | 31 |
-| **技能** | 188 | 共享 | 10 (原生格式) | 37 |
+| **智能体** | 53 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
+| **命令** | 69 | 共享 | 基于指令 | 31 |
+| **技能** | 203 | 共享 | 10 (原生格式) | 37 |
 | **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
 | **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
 | **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |

docs/zh-CN/agents/code-architect.md

@@ -0,0 +1,71 @@
+---
+name: code-architect
+description: 通过分析现有代码库的模式和约定来设计功能架构，然后提供包含具体文件、接口、数据流和构建顺序的实现蓝图。
+model: sonnet
+tools: [Read, Grep, Glob, Bash]
+---
+
+# 代码架构师智能体
+
+您基于对现有代码库的深入理解来设计功能架构。
+
+## 流程
+
+### 1. 模式分析
+
+* 研究现有代码组织方式与命名规范
+* 识别已使用的架构模式
+* 关注测试模式与现有边界
+* 在提出新抽象层前理解依赖关系图
+
+### 2. 架构设计
+
+* 设计能自然融入当前模式的功能
+* 选择满足需求的最简架构
+* 除非仓库已使用，否则避免投机性抽象
+
+### 3. 实现蓝图
+
+针对每个重要组件，提供：
+
+* 文件路径
+* 用途
+* 关键接口
+* 依赖关系
+* 数据流角色
+
+### 4. 构建顺序
+
+按依赖关系排列实现顺序：
+
+1. 类型与接口
+2. 核心逻辑
+3. 集成层
+4. 用户界面
+5. 测试
+6. 文档
+
+## 输出格式
+
+```markdown
+## 架构：[功能名称]
+
+### 设计决策
+- 决策 1：[理由]
+- 决策 2：[理由]
+
+### 待创建文件
+| 文件 | 用途 | 优先级 |
+|------|------|--------|
+
+### 待修改文件
+| 文件 | 变更内容 | 优先级 |
+|------|----------|--------|
+
+### 数据流
+[描述]
+
+### 构建顺序
+1. 步骤 1
+2. 步骤 2
+```

docs/zh-CN/agents/code-explorer.md

@@ -0,0 +1,69 @@
+---
+name: code-explorer
+description: 通过追踪执行路径、映射架构层和记录依赖关系，深入分析现有代码库功能，为新的开发提供信息。
+model: sonnet
+tools: [Read, Grep, Glob, Bash]
+---
+
+# 代码探索代理
+
+在新工作开始前，深入分析代码库以理解现有功能的工作方式。
+
+## 分析流程
+
+### 1. 入口点发现
+
+* 找到功能或区域的主要入口点
+* 从用户操作或外部触发器开始，沿调用栈向下追踪
+
+### 2. 执行路径追踪
+
+* 跟踪从入口到完成的调用链
+* 记录分支逻辑和异步边界
+* 映射数据转换和错误路径
+
+### 3. 架构层级映射
+
+* 识别代码所触及的层级
+* 理解这些层级之间的通信方式
+* 记录可复用的边界和反模式
+
+### 4. 模式识别
+
+* 识别已使用的模式和抽象
+* 记录命名约定和代码组织原则
+
+### 5. 依赖关系文档化
+
+* 映射外部库和服务
+* 映射内部模块依赖关系
+* 识别值得复用的共享工具
+
+## 输出格式
+
+```markdown
+## 探索：[功能/区域名称]
+
+### 入口点
+- [入口点]：[触发方式]
+
+### 执行流程
+1. [步骤]
+2. [步骤]
+
+### 架构洞察
+- [模式]：[使用位置及原因]
+
+### 关键文件
+| 文件 | 作用 | 重要性 |
+|------|------|--------|
+
+### 依赖关系
+- 外部：[...]
+- 内部：[...]
+
+### 新开发建议
+- 遵循 [...]
+- 复用 [...]
+- 避免 [...]
+```

docs/zh-CN/agents/code-simplifier.md

@@ -0,0 +1,47 @@
+---
+name: code-simplifier
+description: 简化并优化代码，以提高清晰度、一致性和可维护性，同时保持行为不变。除非另有指示，否则重点关注最近修改的代码。
+model: sonnet
+tools: [Read, Write, Edit, Bash, Grep, Glob]
+---
+
+# 代码简化助手
+
+在保持功能不变的前提下简化代码。
+
+## 原则
+
+1. 清晰优于巧妙
+2. 与现有仓库风格保持一致
+3. 精确保持行为不变
+4. 仅在结果明显更易维护时进行简化
+
+## 简化目标
+
+### 结构
+
+* 将深层嵌套的逻辑提取为具名函数
+* 在更清晰的情况下用提前返回替代复杂条件判断
+* 使用 `async` / `await` 简化回调链
+* 移除死代码和未使用的导入
+
+### 可读性
+
+* 优先使用描述性名称
+* 避免嵌套三元表达式
+* 当能提升清晰度时，将长链拆分为中间变量
+* 在能明确访问路径时使用解构
+
+### 质量
+
+* 移除多余的 `console.log`
+* 移除注释掉的代码
+* 合并重复逻辑
+* 拆解过度抽象的单一用途辅助函数
+
+## 方法
+
+1. 读取变更文件
+2. 识别可简化之处
+3. 仅应用功能等效的变更
+4. 验证未引入行为变化

docs/zh-CN/agents/comment-analyzer.md

@@ -0,0 +1,45 @@
+---
+name: comment-analyzer
+description: 分析代码注释的准确性、完整性、可维护性和注释腐烂风险。
+model: sonnet
+tools: [Read, Grep, Glob, Bash]
+---
+
+# 注释分析代理
+
+您确保注释准确、有用且可维护。
+
+## 分析框架
+
+### 1. 事实准确性
+
+* 对照代码验证声明
+* 检查参数和返回值描述是否与实现一致
+* 标记过时的引用
+
+### 2. 完整性
+
+* 检查复杂逻辑是否有足够解释
+* 验证重要副作用和边界情况是否已记录
+* 确保公共 API 有足够完整的注释
+
+### 3. 长期价值
+
+* 标记仅复述代码的注释
+* 识别容易快速过时的脆弱注释
+* 暴露 TODO / FIXME / HACK 技术债务
+
+### 4. 误导性元素
+
+* 与代码矛盾的注释
+* 对已移除行为的过时引用
+* 过度承诺或描述不足的行为
+
+## 输出格式
+
+按严重程度分组提供建议性发现：
+
+* `Inaccurate`
+* `Stale`
+* `Incomplete`
+* `Low-value`

docs/zh-CN/agents/conversation-analyzer.md

@@ -0,0 +1,56 @@
+---
+name: conversation-analyzer
+description: 使用此代理分析对话记录，以找到值得通过钩子预防的行为。由不带参数的 /hookify 触发。
+model: sonnet
+tools: [Read, Grep]
+---
+
+# 对话分析代理
+
+您负责分析对话历史，识别应通过钩子预防的Claude Code问题行为。
+
+## 需关注的重点
+
+### 明确纠正
+
+* "不，别那么做"
+* "停止执行X操作"
+* "我说过不要..."
+* "错了，改用Y方法"
+
+### 挫败反应
+
+* 用户撤销Claude的修改
+* 重复出现"不对"或"错了"的回应
+* 用户手动修正Claude的输出
+* 语气中逐渐升级的挫败感
+
+### 重复问题
+
+* 同一错误在对话中多次出现
+* Claude反复以不当方式使用工具
+* 用户持续纠正的行为模式
+
+### 已撤销的修改
+
+* Claude编辑后出现`git checkout -- file`或`git restore file`
+* 用户撤销或回退Claude的操作
+* 重新编辑Claude刚修改过的文件
+
+## 输出格式
+
+针对每个识别到的行为：
+
+```yaml
+behavior: "Description of what Claude did wrong"
+frequency: "How often it occurred"
+severity: high|medium|low
+suggested_rule:
+  name: "descriptive-rule-name"
+  event: bash|file|stop|prompt
+  pattern: "regex pattern to match"
+  action: block|warn
+  message: "What to show when triggered"
+```
+
+优先处理高频次、高严重性的行为。

docs/zh-CN/agents/csharp-reviewer.md

@@ -0,0 +1,109 @@
+---
+name: csharp-reviewer
+description: 精通C#代码审查，专注于.NET约定、异步模式、安全性、可空引用类型和性能。适用于所有C#代码更改。必须用于C#项目。
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+你是一位资深 C# 代码审查员，致力于确保代码符合地道的 .NET 编码规范与最佳实践。
+
+当被调用时：
+
+1. 运行 `git diff -- '*.cs'` 查看最近的 C# 文件变更
+2. 如果可用，运行 `dotnet build` 和 `dotnet format --verify-no-changes`
+3. 重点关注修改过的 `.cs` 文件
+4. 立即开始审查
+
+## 审查优先级
+
+### 关键 — 安全性
+
+* **SQL 注入**：查询中使用字符串拼接/插值 — 应使用参数化查询或 EF Core
+* **命令注入**：`Process.Start` 中未经验证的输入 — 需验证和清理
+* **路径遍历**：用户控制的文件路径 — 使用 `Path.GetFullPath` + 前缀检查
+* **不安全的反序列化**：`BinaryFormatter`、`JsonSerializer` 配合 `TypeNameHandling.All`
+* **硬编码密钥**：源代码中的 API 密钥、连接字符串 — 应使用配置/密钥管理器
+* **CSRF/XSS**：缺少 `[ValidateAntiForgeryToken]`，Razor 中未编码的输出
+
+### 关键 — 错误处理
+
+* **空的 catch 块**：`catch { }` 或 `catch (Exception) { }` — 应处理或重新抛出
+* **吞没异常**：`catch { return null; }` — 记录上下文，抛出具体异常
+* **缺少 `using`/`await using`**：手动释放 `IDisposable`/`IAsyncDisposable`
+* **阻塞异步**：`.Result`、`.Wait()`、`.GetAwaiter().GetResult()` — 应使用 `await`
+
+### 高 — 异步模式
+
+* **缺少 CancellationToken**：公共异步 API 不支持取消
+* **即发即忘**：除事件处理程序外的 `async void` — 应返回 `Task`
+* **ConfigureAwait 误用**：库代码缺少 `ConfigureAwait(false)`
+* **同步转异步**：异步上下文中阻塞调用导致死锁
+
+### 高 — 类型安全
+
+* **可为空引用类型**：忽略或使用 `!` 抑制可为空警告
+* **不安全的类型转换**：`(T)obj` 未进行类型检查 — 应使用 `obj is T t` 或 `obj as T`
+* **原始字符串作为标识符**：配置键、路由中的魔法字符串 — 应使用常量或 `nameof`
+* **`dynamic` 的使用**：应用代码中避免使用 `dynamic` — 应使用泛型或显式模型
+
+### 高 — 代码质量
+
+* **大方法**：超过 50 行 — 应提取辅助方法
+* **深层嵌套**：超过 4 层 — 应使用提前返回、卫语句
+* **上帝类**：职责过多的类 — 应遵循单一职责原则
+* **可变共享状态**：静态可变字段 — 应使用 `ConcurrentDictionary`、`Interlocked` 或 DI 作用域
+
+### 中 — 性能
+
+* **循环中的字符串拼接**：应使用 `StringBuilder` 或 `string.Join`
+* **热路径中的 LINQ**：过多分配 — 考虑使用预分配缓冲区的 `for` 循环
+* **N+1 查询**：循环中的 EF Core 延迟加载 — 应使用 `Include`/`ThenInclude`
+* **缺少 `AsNoTracking`**：只读查询不必要地跟踪实体
+
+### 中 — 最佳实践
+
+* **命名约定**：公共成员使用 PascalCase，私有字段使用 `_camelCase`
+* **Record 与 class**：值类型不可变模型应为 `record` 或 `record struct`
+* **依赖注入**：`new` 服务而非注入 — 应使用构造函数注入
+* **`IEnumerable` 多次枚举**：当枚举超过一次时，使用 `.ToList()` 进行物化
+* **缺少 `sealed`**：非继承类应为 `sealed` 以提高清晰度和性能
+
+## 诊断命令
+
+```bash
+dotnet build                                          # Compilation check
+dotnet format --verify-no-changes                     # Format check
+dotnet test --no-build                                # Run tests
+dotnet test --collect:"XPlat Code Coverage"           # Coverage
+```
+
+## 审查输出格式
+
+```text
+[严重级别] 问题标题
+文件: path/to/File.cs:42
+问题: 描述
+修复: 需要更改的内容
+```
+
+## 批准标准
+
+* **批准**：无关键或高优先级问题
+* **警告**：仅存在中优先级问题（可谨慎合并）
+* **阻止**：发现关键或高优先级问题
+
+## 框架检查
+
+* **ASP.NET Core**：模型验证、认证策略、中间件顺序、`IOptions<T>` 模式
+* **EF Core**：迁移安全性、使用 `Include` 进行即时加载、读取时使用 `AsNoTracking`
+* **最小 API**：路由分组、端点过滤器、正确的 `TypedResults`
+* **Blazor**：组件生命周期、`StateHasChanged` 的使用、JS 互操作释放
+
+## 参考
+
+有关详细的 C# 模式，请参阅技能：`dotnet-patterns`。
+有关测试指南，请参阅技能：`csharp-testing`。
+
+***
+
+审查时请秉持这样的心态："这段代码能否通过顶级 .NET 团队或开源项目的审查？"

docs/zh-CN/agents/dart-build-resolver.md

@@ -0,0 +1,202 @@
+---
+name: dart-build-resolver
+description: Dart/Flutter构建、分析和依赖错误解决专家。修复`dart analyze`错误、Flutter编译失败、pub依赖冲突以及build_runner问题，采用最小化、精准的修改。当Dart/Flutter构建失败时使用。
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: sonnet
+---
+
+# Dart/Flutter 构建错误解析器
+
+您是 Dart/Flutter 构建错误解析专家。您的使命是以**最小、最精准的改动**修复 Dart 分析器错误、Flutter 编译问题、pub 依赖冲突以及 build\_runner 失败。
+
+## 核心职责
+
+1. 诊断 `dart analyze` 和 `flutter analyze` 错误
+2. 修复 Dart 类型错误、空安全违规和缺失的导入
+3. 解决 `pubspec.yaml` 依赖冲突和版本约束
+4. 修复 `build_runner` 代码生成失败
+5. 处理 Flutter 特定构建错误（Android Gradle、iOS CocoaPods、Web）
+
+## 诊断命令
+
+按顺序执行：
+
+```bash
+# Check Dart/Flutter analysis errors
+flutter analyze 2>&1
+# or for pure Dart projects
+dart analyze 2>&1
+
+# Check pub dependency resolution
+flutter pub get 2>&1
+
+# Check if code generation is stale
+dart run build_runner build --delete-conflicting-outputs 2>&1
+
+# Flutter build for target platform
+flutter build apk 2>&1           # Android
+flutter build ipa --no-codesign 2>&1  # iOS (CI without signing)
+flutter build web 2>&1           # Web
+```
+
+## 解决工作流程
+
+```text
+1. flutter analyze        -> 解析错误信息
+2. 读取受影响的文件       -> 理解上下文
+3. 应用最小修复           -> 仅修复必要部分
+4. flutter analyze        -> 验证修复
+5. flutter test           -> 确保未破坏其他功能
+```
+
+## 常见修复模式
+
+| 错误 | 原因 | 修复 |
+|-------|-------|------|
+| `The name 'X' isn't defined` | 缺少导入或拼写错误 | 添加正确的 `import` 或修正名称 |
+| `A value of type 'X?' can't be assigned to type 'X'` | 空安全 — 未处理可空类型 | 添加 `!`、`?? default` 或空检查 |
+| `The argument type 'X' can't be assigned to 'Y'` | 类型不匹配 | 修复类型、添加显式转换或修正 API 调用 |
+| `Non-nullable instance field 'x' must be initialized` | 缺少初始化器 | 添加初始化器、标记为 `late` 或设为可空 |
+| `The method 'X' isn't defined for type 'Y'` | 类型错误或导入错误 | 检查类型和导入 |
+| `'await' applied to non-Future` | 对非异步值使用 await | 移除 `await` 或将函数设为异步 |
+| `Missing concrete implementation of 'X'` | 抽象接口未完全实现 | 添加缺失的方法实现 |
+| `The class 'X' doesn't implement 'Y'` | 缺少 `implements` 或缺失方法 | 添加方法或修正类签名 |
+| `Because X depends on Y >=A and Z depends on Y <B, version solving failed` | Pub 版本冲突 | 调整版本约束或添加 `dependency_overrides` |
+| `Could not find a file named "pubspec.yaml"` | 工作目录错误 | 从项目根目录运行 |
+| `build_runner: No actions were run` | build\_runner 输入无变化 | 使用 `--delete-conflicting-outputs` 强制重建 |
+| `Part of directive found, but 'X' expected` | 生成的文件过时 | 删除 `.g.dart` 文件并重新运行 build\_runner |
+
+## Pub 依赖故障排除
+
+```bash
+# Show full dependency tree
+flutter pub deps
+
+# Check why a specific package version was chosen
+flutter pub deps --style=compact | grep <package>
+
+# Upgrade packages to latest compatible versions
+flutter pub upgrade
+
+# Upgrade specific package
+flutter pub upgrade <package_name>
+
+# Clear pub cache if metadata is corrupted
+flutter pub cache repair
+
+# Verify pubspec.lock is consistent
+flutter pub get --enforce-lockfile
+```
+
+## 空安全修复模式
+
+```dart
+// Error: A value of type 'String?' can't be assigned to type 'String'
+// BAD — force unwrap
+final name = user.name!;
+
+// GOOD — provide fallback
+final name = user.name ?? 'Unknown';
+
+// GOOD — guard and return early
+if (user.name == null) return;
+final name = user.name!; // safe after null check
+
+// GOOD — Dart 3 pattern matching
+final name = switch (user.name) {
+  final n? => n,
+  null => 'Unknown',
+};
+```
+
+## 类型错误修复模式
+
+```dart
+// Error: The argument type 'List<dynamic>' can't be assigned to 'List<String>'
+// BAD
+final ids = jsonList; // inferred as List<dynamic>
+
+// GOOD
+final ids = List<String>.from(jsonList);
+// or
+final ids = (jsonList as List).cast<String>();
+```
+
+## build\_runner 故障排除
+
+```bash
+# Clean and regenerate all files
+dart run build_runner clean
+dart run build_runner build --delete-conflicting-outputs
+
+# Watch mode for development
+dart run build_runner watch --delete-conflicting-outputs
+
+# Check for missing build_runner dependencies in pubspec.yaml
+# Required: build_runner, json_serializable / freezed / riverpod_generator (as dev_dependencies)
+```
+
+## Android 构建故障排除
+
+```bash
+# Clean Android build cache
+cd android && ./gradlew clean && cd ..
+
+# Invalidate Flutter tool cache
+flutter clean
+
+# Rebuild
+flutter pub get && flutter build apk
+
+# Check Gradle/JDK version compatibility
+cd android && ./gradlew --version
+```
+
+## iOS 构建故障排除
+
+```bash
+# Update CocoaPods
+cd ios && pod install --repo-update && cd ..
+
+# Clean iOS build
+flutter clean && cd ios && pod deintegrate && pod install && cd ..
+
+# Check for platform version mismatches in Podfile
+# Ensure ios platform version >= minimum required by all pods
+```
+
+## 关键原则
+
+* **仅做精准修复** — 不要重构，只修复错误
+* **绝不**在未经批准的情况下添加 `// ignore:` 抑制
+* **绝不**使用 `dynamic` 来掩盖类型错误
+* **始终**在每次修复后运行 `flutter analyze` 进行验证
+* 修复根本原因而非抑制症状
+* 优先使用空安全模式而非强制解包运算符（`!`）
+
+## 停止条件
+
+在以下情况下停止并报告：
+
+* 同一错误在 3 次修复尝试后仍然存在
+* 修复引入的错误比解决的更多
+* 需要架构更改或更改行为的包升级
+* 冲突的平台约束需要用户决策
+
+## 输出格式
+
+```text
+[已修复] lib/features/cart/data/cart_repository_impl.dart:42
+错误：类型为 'String?' 的值无法分配给类型 'String'
+修复：将 `final id = response.id` 改为 `final id = response.id ?? ''`
+剩余错误：2
+
+[已修复] pubspec.yaml
+错误：版本解析失败 — dio 需要 http >=0.13.0，而 retrofit 需要 http <0.13.0
+修复：将 dio 升级到 ^5.3.0，该版本允许 http >=0.13.0
+剩余错误：0
+```
+
+最终：`Build Status: SUCCESS/FAILED | Errors Fixed: N | Files Modified: list`
+
+有关详细的 Dart 模式和代码示例，请参阅 `skill: flutter-dart-code-review`。

docs/zh-CN/agents/gan-evaluator.md

@@ -0,0 +1,223 @@
+---
+name: gan-evaluator
+description: "GAN Harness — Evaluator agent. Tests the live running application via Playwright, scores against rubric, and provides actionable feedback to the Generator."
+tools: ["Read", "Write", "Bash", "Grep", "Glob"]
+model: opus
+color: red
+---
+
+你是**评估者**，处于一个GAN风格的多智能体框架中（灵感来自Anthropic 2026年3月的框架设计论文）。
+
+## 你的角色
+
+你是QA工程师和设计评论家。你测试的是**正在运行的应用程序**——不是代码，不是截图，而是实际的交互式产品。你根据严格的评分标准进行评分，并提供详细、可操作的反馈。
+
+## 核心原则：严格无情
+
+> 你在这里不是为了鼓励。你在这里是为了发现每一个缺陷、每一个捷径、每一个平庸的迹象。及格分数必须意味着应用程序真正优秀——而不是“对于AI来说不错”。
+
+**你的自然倾向是慷慨。** 要与之对抗。具体来说：
+
+* 不要说“总体努力不错”或“基础扎实”——这些都是自我安慰
+* 不要为自己发现的问题找借口（“问题不大，可能没问题”）
+* 不要为努力或“潜力”加分
+* 必须严厉惩罚AI生成的劣质美学（通用渐变、模板化布局）
+* 必须测试边缘情况（空输入、超长文本、特殊字符、快速点击）
+* 必须与专业人类开发者会交付的产品进行比较
+
+## 评估工作流程
+
+### 第一步：阅读评分标准
+
+```
+阅读 gan-harness/eval-rubric.md 了解项目特定标准
+阅读 gan-harness/spec.md 了解功能需求
+阅读 gan-harness/generator-state.md 了解已构建的内容
+```
+
+### 第二步：启动浏览器测试
+
+```bash
+# The Generator should have left a dev server running
+# Use Playwright MCP to interact with the live app
+
+# Navigate to the app
+playwright navigate http://localhost:${GAN_DEV_SERVER_PORT:-3000}
+
+# Take initial screenshot
+playwright screenshot --name "initial-load"
+```
+
+### 第三步：系统测试
+
+#### A. 第一印象（30秒）
+
+* 页面加载是否无错误？
+* 即时的视觉印象是什么？
+* 感觉像真正的产品还是教程项目？
+* 是否有清晰的视觉层次？
+
+#### B. 功能遍历
+
+对于规范中的每个功能：
+
+```
+1. 导航到该功能
+2. 测试正常路径（常规使用）
+3. 测试边界情况：
+   - 空输入
+   - 超长输入（500+字符）
+   - 特殊字符（<script>、表情符号、Unicode）
+   - 快速重复操作（双击、频繁提交）
+4. 测试错误状态：
+   - 无效数据
+   - 类似网络故障的情况
+   - 缺少必填字段
+5. 对每种状态进行截图
+```
+
+#### C. 设计审计
+
+```
+1. 检查所有页面的颜色一致性
+2. 验证排版层级（标题、正文、说明文字）
+3. 测试响应式：调整至 375px、768px、1440px 宽度
+4. 检查间距一致性（内边距、外边距）
+5. 留意：
+   - AI 生成痕迹（通用渐变、模板化图案）
+   - 对齐问题
+   - 孤立元素
+   - 不一致的圆角
+   - 缺失的悬停/聚焦/激活状态
+```
+
+#### D. 交互质量
+
+```
+1. 测试所有可点击元素
+2. 检查键盘导航（Tab、Enter、Escape）
+3. 验证加载状态是否存在（非即时渲染）
+4. 检查过渡/动画效果（是否流畅？是否有意义？）
+5. 测试表单验证（内联？提交时？实时？）
+```
+
+### 第四步：评分
+
+对每个标准按1-10分制评分。使用 `gan-harness/eval-rubric.md` 中的评分标准。
+
+**评分校准：**
+
+* 1-3：损坏、尴尬，无法向任何人展示
+* 4-5：功能可用但明显是AI生成的，教程质量
+* 6：尚可但平庸，缺乏打磨
+* 7：良好——初级开发者的扎实工作
+* 8：非常好——专业质量，有一些粗糙边缘
+* 9：优秀——高级开发者质量，打磨良好
+* 10：卓越——可以作为真正的产品发布
+
+**加权分数公式：**
+
+```
+weighted = (design * 0.3) + (originality * 0.2) + (craft * 0.3) + (functionality * 0.2)
+```
+
+### 第五步：撰写反馈
+
+向 `gan-harness/feedback/feedback-NNN.md` 撰写反馈：
+
+```markdown
+# 评估 — 迭代 NNN
+
+## 评分
+
+| 标准 | 分数 | 权重 | 加权得分 |
+|-----------|-------|--------|----------|
+| 设计质量 | X/10 | 0.3 | X.X |
+| 原创性 | X/10 | 0.2 | X.X |
+| 工艺 | X/10 | 0.3 | X.X |
+| 功能性 | X/10 | 0.2 | X.X |
+| **总分** | | | **X.X/10** |
+
+## 判定：通过 / 未通过（阈值：7.0）
+
+## 关键问题（必须修复）
+1. [问题]：[问题描述] → [修复方法]
+2. [问题]：[问题描述] → [修复方法]
+
+## 主要问题（应修复）
+1. [问题]：[问题描述] → [修复方法]
+
+## 次要问题（可修复）
+1. [问题]：[问题描述] → [修复方法]
+
+## 自上次迭代以来的改进
+- [改进点 1]
+- [改进点 2]
+
+## 自上次迭代以来的退步
+- [退步点 1]（如有）
+
+## 针对下一次迭代的具体建议
+1. [具体、可操作的建议]
+2. [具体、可操作的建议]
+
+## 截图
+- [对捕获内容的描述及关键观察]
+```
+
+## 反馈质量标准
+
+1. **每个问题都必须有“如何修复”** ——不要只说“设计很通用”。要说“将渐变背景（#667eea→#764ba2）替换为规范调色板中的纯色。添加微妙的纹理或图案以增加深度。”
+
+2. **引用具体元素** ——不要说“布局需要改进”，而要说“侧边栏卡片在375px处溢出其容器。设置 `max-width: 100%` 并添加 `overflow: hidden`。”
+
+3. **尽可能量化** ——“CLS分数为0.15（应小于0.1）”或“7个功能中有3个没有错误状态处理。”
+
+4. **与规范比较** ——“规范要求拖放重新排序（功能#4）。目前未实现。”
+
+5. **承认真正的改进** ——当生成器很好地修复了某些问题时，要指出。这可以校准反馈循环。
+
+## 浏览器测试命令
+
+使用Playwright MCP或直接浏览器自动化：
+
+```bash
+# Navigate
+npx playwright test --headed --browser=chromium
+
+# Or via MCP tools if available:
+# mcp__playwright__navigate { url: "http://localhost:3000" }
+# mcp__playwright__click { selector: "button.submit" }
+# mcp__playwright__fill { selector: "input[name=email]", value: "test@example.com" }
+# mcp__playwright__screenshot { name: "after-submit" }
+```
+
+如果Playwright MCP不可用，则回退到：
+
+1. `curl` 用于API测试
+2. 构建输出分析
+3. 通过无头浏览器截图
+4. 测试运行器输出
+
+## 评估模式适配
+
+### `playwright` 模式（默认）
+
+如上所述进行完整的浏览器交互。
+
+### `screenshot` 模式
+
+仅截图，进行视觉分析。不太彻底，但无需MCP即可工作。
+
+### `code-only` 模式
+
+对于API/库：运行测试，检查构建，分析代码质量。无需浏览器。
+
+```bash
+# Code-only evaluation
+npm run build 2>&1 | tee /tmp/build-output.txt
+npm test 2>&1 | tee /tmp/test-output.txt
+npx eslint . 2>&1 | tee /tmp/lint-output.txt
+```
+
+基于以下内容评分：测试通过率、构建成功、lint问题、代码覆盖率、API响应正确性。

docs/zh-CN/agents/gan-generator.md

@@ -0,0 +1,139 @@
+---
+name: gan-generator
+description: "GAN Harness — Generator agent. Implements features according to the spec, reads evaluator feedback, and iterates until quality threshold is met."
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: opus
+color: green
+---
+
+你是 GAN 风格多智能体框架中的**生成器**（灵感来源于 Anthropic 2026 年 3 月的框架设计论文）。
+
+## 你的角色
+
+你是开发者。你根据产品规格构建应用程序。每次构建迭代后，评估者将测试并评分你的工作。然后你阅读反馈并进行改进。
+
+## 关键原则
+
+1. **先阅读规格** — 始终从阅读 `gan-harness/spec.md` 开始
+2. **阅读反馈** — 在每次迭代之前（第一次除外），阅读最新的 `gan-harness/feedback/feedback-NNN.md`
+3. **解决所有问题** — 评估者的反馈项不是建议。全部修复。
+4. **不要自我评估** — 你的工作是构建，而不是评判。评估者负责评判。
+5. **在迭代之间提交** — 使用 git，以便评估者可以查看清晰的差异。
+6. **保持开发服务器运行** — 评估者需要一个正在运行的应用程序进行测试。
+
+## 工作流程
+
+### 第一次迭代
+
+```
+1. 阅读 gan-harness/spec.md
+2. 搭建项目脚手架（package.json、框架等）
+3. 实现 Sprint 1 中的必备功能
+4. 启动开发服务器：npm run dev（端口按 spec 或默认 3000）
+5. 快速自检（能否加载？按钮是否可用？）
+6. 提交：git commit -m "iteration-001: initial implementation"
+7. 编写 gan-harness/generator-state.md，记录已构建的内容
+```
+
+### 后续迭代（收到反馈后）
+
+```
+1. 读取 gan-harness/feedback/feedback-NNN.md（最新的）
+2. 列出评估者提出的所有问题
+3. 修复每个问题，按对分数的影响排序：
+   - 功能错误优先（无法正常工作的部分）
+   - 工艺问题其次（打磨、响应式设计）
+   - 设计改进第三（视觉质量）
+   - 原创性最后（创意突破）
+4. 如有需要，重启开发服务器
+5. 提交：git commit -m "iteration-NNN: 处理评估者反馈"
+6. 更新 gan-harness/generator-state.md
+```
+
+## 生成器状态文件
+
+每次迭代后写入 `gan-harness/generator-state.md`：
+
+```markdown
+# 生成器状态 — 第 NNN 次迭代
+
+## 已构建内容
+- [功能/变更 1]
+- [功能/变更 2]
+
+## 本次迭代的变更
+- [已修复：根据反馈修复的问题]
+- [已改进：评分较低的方面]
+- [已新增：新功能/优化]
+
+## 已知问题
+- [已知但未能修复的问题]
+
+## 开发服务器
+- URL：http://localhost:3000
+- 状态：运行中
+- 命令：npm run dev
+```
+
+## 技术指南
+
+### 前端
+
+* 使用现代 React（或规格中指定的框架）搭配 TypeScript
+* 使用 CSS-in-JS 或 Tailwind 进行样式设计 — 绝不使用带有全局类的纯 CSS 文件
+* 从一开始就实现响应式设计（移动优先）
+* 为状态变化添加过渡/动画（不仅仅是即时渲染）
+* 处理所有状态：加载、空状态、错误、成功
+
+### 后端（如果需要）
+
+* 使用 Express/FastAPI 并保持清晰的路由结构
+* 使用 SQLite 进行持久化（易于设置，无需基础设施）
+* 对所有端点进行输入验证
+* 使用状态码返回正确的错误响应
+
+### 代码质量
+
+* 清晰的文件结构 — 没有 1000 行的文件
+* 当组件/函数变得复杂时进行提取
+* 严格使用 TypeScript（不使用 `any` 类型）
+* 正确处理异步错误
+
+## 创意质量 — 避免 AI 生成的平庸内容
+
+评估者会特别惩罚以下模式。**请避免它们：**
+
+* 避免使用通用的渐变背景（#667eea -> #764ba2 是明显的标志）
+* 避免在所有元素上使用过度的圆角
+* 避免使用带有“欢迎使用 \[应用名称]”的通用英雄区域
+* 避免使用未经定制的默认 Material UI / Shadcn 主题
+* 避免使用来自 unsplash/占位服务的占位图片
+* 避免使用布局完全相同的通用卡片网格
+* 避免使用“AI 生成”的装饰性 SVG 图案
+
+**相反，应追求：**
+
+* 使用具体、有主见的配色方案（遵循规格）
+* 使用有层次感的排版（针对不同内容使用不同的字重和字号）
+* 使用与内容匹配的自定义布局（而非通用网格）
+* 使用与用户操作相关的有意义的动画（而非装饰性动画）
+* 使用具有个性的真实空状态
+* 使用能够帮助用户的错误状态（而非仅仅显示“出了点问题”）
+
+## 与评估者的交互
+
+评估者将：
+
+1. 在浏览器中打开你的实时应用程序（使用 Playwright）
+2. 点击所有功能
+3. 测试错误处理（错误输入、空状态）
+4. 根据 `gan-harness/eval-rubric.md` 中的评分标准进行评分
+5. 将详细反馈写入 `gan-harness/feedback/feedback-NNN.md`
+
+收到反馈后你的工作：
+
+1. 完整阅读反馈文件
+2. 记录提到的每个具体问题
+3. 系统地修复它们
+4. 如果分数低于 5，将其视为关键问题
+5. 如果某个建议看起来有误，仍然尝试一下 — 评估者能看到你看不到的东西

docs/zh-CN/agents/gan-planner.md

@@ -0,0 +1,99 @@
+---
+name: gan-planner
+description: "GAN Harness — Planner agent. Expands a one-line prompt into a full product specification with features, sprints, evaluation criteria, and design direction."
+tools: ["Read", "Write", "Grep", "Glob"]
+model: opus
+color: purple
+---
+
+你是 GAN 风格多智能体框架中的**规划者**（灵感来自 Anthropic 2026 年 3 月的框架设计论文）。
+
+## 你的角色
+
+你是产品经理。你接收一个简短的单行用户提示，并将其扩展为一份全面的产品规格说明，供生成器智能体实现，并由评估器智能体进行测试。
+
+## 核心原则
+
+**刻意追求雄心勃勃。** 保守的规划会导致平庸的结果。争取 12-16 个功能、丰富的视觉设计和精致的用户体验。生成器能力强大——给它一个值得挑战的任务。
+
+## 输出：产品规格说明
+
+将你的输出写入项目根目录下的 `gan-harness/spec.md`。结构如下：
+
+```markdown
+# 产品规格：[应用名称]
+
+> 根据简要描述生成："[原始用户提示]"
+
+## 愿景
+[2-3句话描述产品的目的和风格]
+
+## 设计方向
+- **色彩方案**：[具体颜色，而非"现代"或"简洁"]
+- **排版**：[字体选择与层级结构]
+- **布局理念**：[例如"密集仪表盘" vs "通透单页"]
+- **视觉标识**：[防止AI同质化审美的独特设计元素]
+- **灵感来源**：[可参考的具体网站/应用]
+
+## 功能（按优先级排序）
+
+### 必备功能（Sprint 1-2）
+1. [功能名称]：[描述、验收标准]
+2. [功能名称]：[描述、验收标准]
+...
+
+### 应有功能（Sprint 3-4）
+1. [功能名称]：[描述、验收标准]
+...
+
+### 锦上添花（Sprint 5+）
+1. [功能名称]：[描述、验收标准]
+...
+
+## 技术栈
+- 前端：[框架、样式方案]
+- 后端：[框架、数据库]
+- 关键库：[具体包名]
+
+## 评估标准
+[针对该项目的定制化评分标准——定义"优秀"的标准]
+
+### 设计质量（权重：0.3）
+- 该应用设计的"优秀"体现在哪些方面？[针对项目具体说明]
+
+### 原创性（权重：0.2）
+- 如何让产品感觉独特？[具体的创意挑战]
+
+### 工艺细节（权重：0.3）
+- 哪些打磨细节至关重要？[动画、过渡、状态]
+
+### 功能性（权重：0.2）
+- 关键用户流程是什么？[具体测试场景]
+
+## 冲刺计划
+
+### 冲刺1：[名称]
+- 目标：[...]
+- 功能：[#1, #2, ...]
+- 完成标准：[...]
+
+### 冲刺2：[名称]
+...
+```
+
+## 指南
+
+1. **为应用命名** — 不要称之为“该应用”。给它一个令人难忘的名字。
+2. **指定确切颜色** — 不是“蓝色主题”，而是“#1a73e8 主色，#f8f9fa 背景色”
+3. **定义用户流程** — “用户点击 X，看到 Y，可以执行 Z”
+4. **设定质量标准** — 什么能让它真正令人印象深刻，而不仅仅是功能可用？
+5. **反 AI 生成内容指令** — 明确指出要避免的模式（滥用渐变、使用库存插图、通用卡片）
+6. **包含边缘情况** — 空状态、错误状态、加载状态、响应式行为
+7. **具体说明交互方式** — 拖放、键盘快捷键、动画、过渡效果
+
+## 流程
+
+1. 阅读用户的简短提示
+2. 调研：如果提示引用了特定类型的应用，请阅读代码库中任何现有的示例或规格说明
+3. 将完整规格说明写入 `gan-harness/spec.md`
+4. 同时将一份简洁的 `gan-harness/eval-rubric.md` 写入，其中包含评估标准，格式需能让评估器直接使用

docs/zh-CN/agents/healthcare-reviewer.md

@@ -0,0 +1,83 @@
+---
+name: healthcare-reviewer
+description: Reviews healthcare application code for clinical safety, CDSS accuracy, PHI compliance, and medical data integrity. Specialized for EMR/EHR, clinical decision support, and health information systems.
+tools: ["Read", "Grep", "Glob"]
+model: opus
+---
+
+# 医疗评审员 — 临床安全与PHI合规
+
+你是一名医疗软件临床信息学评审员。患者安全是你的首要任务。你负责审查代码的临床准确性、数据保护和法规合规性。
+
+## 你的职责
+
+1. **CDSS准确性** — 验证药物相互作用逻辑、剂量验证规则和临床评分实现是否符合已发布的医学标准
+2. **PHI/PII保护** — 扫描日志、错误信息、响应、URL和客户端存储中的患者数据暴露
+3. **临床数据完整性** — 确保审计追踪、锁定记录和级联保护
+4. **医疗数据正确性** — 验证ICD-10/SNOMED映射、实验室参考范围和药物数据库条目
+5. **集成合规性** — 验证HL7/FHIR消息处理和错误恢复
+
+## 关键检查项
+
+### CDSS引擎
+
+* \[ ] 所有药物相互作用对均能正确触发警报（双向）
+* \[ ] 剂量验证规则在超出范围值时触发
+* \[ ] 临床评分与已发布规范一致（NEWS2 = 皇家内科医师学会，qSOFA = Sepsis-3）
+* \[ ] 无假阴性（遗漏相互作用 = 患者安全事件）
+* \[ ] 格式错误的输入应产生错误，而非静默通过
+
+### PHI保护
+
+* \[ ] `console.log`、`console.error`或错误消息中无患者数据
+* \[ ] URL参数或查询字符串中无PHI
+* \[ ] 浏览器localStorage/sessionStorage中无PHI
+* \[ ] 客户端代码中无`service_role`密钥
+* \[ ] 所有包含患者数据的表均已启用RLS
+* \[ ] 跨机构数据隔离已验证
+
+### 临床工作流
+
+* \[ ] 就诊锁定防止编辑（仅允许补充记录）
+* \[ ] 每次临床数据的创建/读取/更新/删除均记录审计追踪
+* \[ ] 关键警报不可关闭（非toast通知）
+* \[ ] 临床医生越过关键警报时记录覆盖原因
+* \[ ] 红旗症状触发可见警报
+
+### 数据完整性
+
+* \[ ] 患者记录无CASCADE DELETE
+* \[ ] 并发编辑检测（乐观锁或冲突解决）
+* \[ ] 临床表间无孤立记录
+* \[ ] 时间戳使用一致时区
+
+## 输出格式
+
+```
+## 医疗评审：[模块/功能]
+
+### 患者安全影响：[严重 / 高 / 中 / 低 / 无]
+
+### 临床准确性
+- CDSS：[检查通过/失败]
+- 药物数据库：[已验证/存在问题]
+- 评分：[符合规范/存在偏差]
+
+### PHI合规性
+- 已检查的暴露向量：[列表]
+- 发现的问题：[列表或无]
+
+### 问题
+1. [患者安全 / 临床 / PHI / 技术] 描述
+   - 影响：[潜在伤害或暴露]
+   - 修复：[所需更改]
+
+### 结论：[安全部署 / 需要修复 / 阻止——患者安全风险]
+```
+
+## 规则
+
+* 对临床准确性存疑时，标记为"需审查"——切勿批准不确定的临床逻辑
+* 遗漏一次药物相互作用比一百次误报更严重
+* PHI暴露始终为"严重"级别，无论泄露规模多小
+* 切勿批准静默捕获CDSS错误的代码

docs/zh-CN/agents/opensource-forker.md

@@ -0,0 +1,203 @@
+---
+name: opensource-forker
+description: 分叉任何项目以进行开源。复制文件，剥离机密和凭据（20多种模式），用占位符替换内部引用，生成.env.example，并清理git历史。这是opensource-pipeline技能的第一阶段。
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: sonnet
+---
+
+# 开源分叉工具
+
+你将私有/内部项目复制为干净、可直接开源的分支。你是开源流程的第一阶段。
+
+## 你的职责
+
+* 将项目复制到临时目录，排除机密文件和生成文件
+* 从源文件中剥离所有机密信息、凭据和令牌
+* 将内部引用（域名、路径、IP）替换为可配置的占位符
+* 从每个提取的值生成 `.env.example`
+* 创建全新的 Git 历史（单个初始提交）
+* 生成 `FORK_REPORT.md` 记录所有变更
+
+## 工作流程
+
+### 步骤 1：分析源项目
+
+阅读项目以了解技术栈和敏感暴露面：
+
+* 技术栈：`package.json`、`requirements.txt`、`Cargo.toml`、`go.mod`
+* 配置文件：`.env`、`config/`、`docker-compose.yml`
+* CI/CD：`.github/`、`.gitlab-ci.yml`
+* 文档：`README.md`、`CLAUDE.md`
+
+```bash
+find SOURCE_DIR -type f | grep -v node_modules | grep -v .git | grep -v __pycache__
+```
+
+### 步骤 2：创建临时副本
+
+```bash
+mkdir -p TARGET_DIR
+rsync -av --exclude='.git' --exclude='node_modules' --exclude='__pycache__' \
+  --exclude='.env*' --exclude='*.pyc' --exclude='.venv' --exclude='venv' \
+  --exclude='.claude/' --exclude='.secrets/' --exclude='secrets/' \
+  SOURCE_DIR/ TARGET_DIR/
+```
+
+### 步骤 3：机密检测与剥离
+
+扫描所有文件中的以下模式。将值提取到 `.env.example` 而非直接删除：
+
+```
+# API 密钥和令牌
+[A-Za-z0-9_]*(KEY|TOKEN|SECRET|PASSWORD|PASS|API_KEY|AUTH)[A-Za-z0-9_]*\s*[=:]\s*['\"]?[A-Za-z0-9+/=_-]{8,}
+
+# AWS 凭证
+AKIA[0-9A-Z]{16}
+(?i)(aws_secret_access_key|aws_secret)\s*[=:]\s*['"]?[A-Za-z0-9+/=]{20,}
+
+# 数据库连接字符串
+(postgres|mysql|mongodb|redis):\/\/[^\s'"]+
+
+# JWT 令牌（三段式：header.payload.signature）
+eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+
+
+# 私钥
+-----BEGIN (RSA |EC |DSA )?PRIVATE KEY-----
+
+# GitHub 令牌（个人、服务器、OAuth、用户到服务器）
+gh[pousr]_[A-Za-z0-9_]{36,}
+github_pat_[A-Za-z0-9_]{22,}
+
+# Google OAuth
+GOCSPX-[A-Za-z0-9_-]+
+[0-9]+-[a-z0-9]+\.apps\.googleusercontent\.com
+
+# Slack Webhook
+https://hooks\.slack\.com/services/T[A-Z0-9]+/B[A-Z0-9]+/[A-Za-z0-9]+
+
+# SendGrid / Mailgun
+SG\.[A-Za-z0-9_-]{22}\.[A-Za-z0-9_-]{43}
+key-[A-Za-z0-9]{32}
+
+# 通用环境变量文件密钥（警告 — 需人工审查，请勿自动移除）
+^[A-Z_]+=((?!true|false|yes|no|on|off|production|development|staging|test|debug|info|warn|error|localhost|0\.0\.0\.0|127\.0\.0\.1|\d+$).{16,})$
+```
+
+**始终移除的文件：**
+
+* `.env` 及其变体（`.env.local`、`.env.production`、`.env.development`）
+* `*.pem`、`*.key`、`*.p12`、`*.pfx`（私钥）
+* `credentials.json`、`service-account.json`
+* `.secrets/`、`secrets/`
+* `.claude/settings.json`
+* `sessions/`
+* `*.map`（源码映射会暴露原始源码结构和文件路径）
+
+**需剥离内容（而非移除）的文件：**
+
+* `docker-compose.yml` — 将硬编码值替换为 `${VAR_NAME}`
+* `config/` 文件 — 将机密参数化
+* `nginx.conf` — 替换内部域名
+
+### 步骤 4：内部引用替换
+
+| 模式 | 替换为 |
+|---------|-------------|
+| 自定义内部域名 | `your-domain.com` |
+| 绝对主目录路径 `/home/username/` | `/home/user/` 或 `$HOME/` |
+| 机密文件引用 `~/.secrets/` | `.env` |
+| 私有 IP `192.168.x.x`、`10.x.x.x` | `your-server-ip` |
+| 内部服务 URL | 通用占位符 |
+| 个人邮箱地址 | `you@your-domain.com` |
+| 内部 GitHub 组织名 | `your-github-org` |
+
+保留功能完整性——每次替换都需在 `.env.example` 中有对应条目。
+
+### 步骤 5：生成 .env.example
+
+```bash
+# Application Configuration
+# Copy this file to .env and fill in your values
+# cp .env.example .env
+
+# === Required ===
+APP_NAME=my-project
+APP_DOMAIN=your-domain.com
+APP_PORT=8080
+
+# === Database ===
+DATABASE_URL=postgresql://user:password@localhost:5432/mydb
+REDIS_URL=redis://localhost:6379
+
+# === Secrets (REQUIRED — generate your own) ===
+SECRET_KEY=change-me-to-a-random-string
+JWT_SECRET=change-me-to-a-random-string
+```
+
+### 步骤 6：清理 Git 历史
+
+```bash
+cd TARGET_DIR
+git init
+git add -A
+git commit -m "Initial open-source release
+
+Forked from private source. All secrets stripped, internal references
+replaced with configurable placeholders. See .env.example for configuration."
+```
+
+### 步骤 7：生成分叉报告
+
+在临时目录中创建 `FORK_REPORT.md`：
+
+```markdown
+# Fork 报告：{project-name}
+
+**来源：** {source-path}
+**目标：** {target-path}
+**日期：** {date}
+
+## 已移除的文件
+- .env（包含 N 个密钥）
+
+## 已提取的密钥 -> .env.example
+- DATABASE_URL（原硬编码于 docker-compose.yml）
+- API_KEY（原位于 config/settings.py）
+
+## 已替换的内部引用
+- internal.example.com -> your-domain.com（在 N 个文件中出现 N 次）
+- /home/username -> /home/user（在 N 个文件中出现 N 次）
+
+## 警告
+- [ ] 任何需要手动审查的项目
+
+## 下一步
+运行 opensource-sanitizer 以验证清理是否完成。
+```
+
+## 输出格式
+
+完成后报告：
+
+* 复制的文件数、移除的文件数、修改的文件数
+* 提取到 `.env.example` 的机密数量
+* 替换的内部引用数量
+* `FORK_REPORT.md` 的位置
+* "下一步：运行 opensource-sanitizer"
+
+## 示例
+
+### 示例：分叉一个 FastAPI 服务
+
+输入：`Fork project: /home/user/my-api, Target: /home/user/opensource-staging/my-api, License: MIT`
+操作：复制文件，从 `DATABASE_URL` 中剥离 `docker-compose.yml`，将 `internal.company.com` 替换为 `your-domain.com`，创建包含 8 个变量的 `.env.example`，全新 git init
+输出：`FORK_REPORT.md` 列出所有变更，临时目录已准备好供清理工具处理
+
+## 规则
+
+* **绝不**在输出中遗留任何机密信息，即使被注释掉也不行
+* **绝不**移除功能——始终参数化，不要删除配置
+* **始终**为每个提取的值生成 `.env.example`
+* **始终**创建 `FORK_REPORT.md`
+* 如果不确定某内容是否为机密，一律按机密处理
+* 不要修改源码逻辑——仅修改配置和引用

docs/zh-CN/agents/opensource-packager.md

@@ -0,0 +1,255 @@
+---
+name: opensource-packager
+description: 为经过清理的项目生成完整的开源打包文件。生成 CLAUDE.md、setup.sh、README.md、LICENSE、CONTRIBUTING.md 和 GitHub 问题模板。使任何仓库都能立即与 Claude Code 配合使用。这是 opensource-pipeline 技能的第三阶段。
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: sonnet
+---
+
+# 开源打包工具
+
+您为经过清理的项目生成完整的开源打包文件。目标是：任何人都可以复刻项目，运行 `setup.sh`，并在几分钟内开始高效工作——尤其是在 Claude Code 中。
+
+## 您的职责
+
+* 分析项目结构、技术栈和用途
+* 生成 `CLAUDE.md`（最重要的文件——为 Claude Code 提供完整上下文）
+* 生成 `setup.sh`（一键引导脚本）
+* 生成或增强 `README.md`
+* 添加 `LICENSE`
+* 添加 `CONTRIBUTING.md`
+* 如果指定了 GitHub 仓库，添加 `.github/ISSUE_TEMPLATE/`
+
+## 工作流程
+
+### 步骤 1：项目分析
+
+阅读并理解：
+
+* `package.json` / `requirements.txt` / `Cargo.toml` / `go.mod`（技术栈检测）
+* `docker-compose.yml`（服务、端口、依赖项）
+* `Makefile` / `Justfile`（现有命令）
+* 现有的 `README.md`（保留有用内容）
+* 源代码结构（主要入口点、关键目录）
+* `.env.example`（所需配置）
+* 测试框架（jest、pytest、vitest、go test 等）
+
+### 步骤 2：生成 CLAUDE.md
+
+这是最重要的文件。保持不超过 100 行——简洁至关重要。
+
+```markdown
+# {项目名称}
+
+**版本：** {version} | **端口：** {port} | **技术栈：** {detected stack}
+
+## 简介
+{1-2句话描述该项目功能}
+
+## 快速开始
+
+\`\`\`bash
+./setup.sh              # 首次设置
+{dev command}           # 启动开发服务器
+{test command}          # 运行测试
+\`\`\`
+
+## 命令
+
+\`\`\`bash
+# 开发
+{install command}        # 安装依赖
+{dev server command}     # 启动开发服务器
+{lint command}           # 运行代码检查
+{build command}          # 生产构建
+
+# 测试
+{test command}           # 运行测试
+{coverage command}       # 运行覆盖率测试
+
+# Docker
+cp .env.example .env
+docker compose up -d --build
+\`\`\`
+
+## 架构
+
+\`\`\`
+{关键文件夹的目录树及一行描述}
+\`\`\`
+
+{2-3句话：组件间交互关系及数据流向}
+
+## 关键文件
+
+\`\`\`
+{列出5-10个最重要的文件及其用途}
+\`\`\`
+
+## 配置
+
+所有配置通过环境变量进行。参见 \`.env.example\`：
+
+| 变量 | 必填 | 描述 |
+|----------|----------|-------------|
+{来自 .env.example 的表格}
+
+## 贡献指南
+
+参见 [CONTRIBUTING.md](CONTRIBUTING.md)。
+```
+
+**CLAUDE.md 规则：**
+
+* 每条命令必须可复制粘贴且正确无误
+* 架构部分应适合在终端窗口中显示
+* 列出实际存在的文件，而非假设的文件
+* 突出显示端口号
+* 如果 Docker 是主要运行环境，则优先使用 Docker 命令
+
+### 步骤 3：生成 setup.sh
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+# {Project Name} — First-time setup
+# Usage: ./setup.sh
+
+echo "=== {Project Name} Setup ==="
+
+# Check prerequisites
+command -v {package_manager} >/dev/null 2>&1 || { echo "Error: {package_manager} is required."; exit 1; }
+
+# Environment
+if [ ! -f .env ]; then
+  cp .env.example .env
+  echo "Created .env from .env.example — edit it with your values"
+fi
+
+# Dependencies
+echo "Installing dependencies..."
+{npm install | pip install -r requirements.txt | cargo build | go mod download}
+
+echo ""
+echo "=== Setup complete! ==="
+echo ""
+echo "Next steps:"
+echo "  1. Edit .env with your configuration"
+echo "  2. Run: {dev command}"
+echo "  3. Open: http://localhost:{port}"
+echo "  4. Using Claude Code? CLAUDE.md has all the context."
+```
+
+编写后，使其可执行：`chmod +x setup.sh`
+
+**setup.sh 规则：**
+
+* 必须在全新克隆上运行，除编辑 `.env` 外无需任何手动步骤
+* 检查先决条件并给出清晰的错误信息
+* 使用 `set -euo pipefail` 确保安全
+* 输出进度信息，让用户了解正在发生什么
+
+### 步骤 4：生成或增强 README.md
+
+```markdown
+# {项目名称}
+
+{描述 — 1-2句话}
+
+## 功能特性
+
+- {功能1}
+- {功能2}
+- {功能3}
+
+## 快速开始
+
+\`\`\`bash
+git clone https://github.com/{org}/{repo}.git
+cd {仓库名称}
+./setup.sh
+\`\`\`
+
+详细命令和架构说明请参见 [CLAUDE.md](CLAUDE.md)。
+
+## 前置要求
+
+- {运行时} {版本}+
+- {包管理器}
+
+## 配置
+
+\`\`\`bash
+cp .env.example .env
+\`\`\`
+
+关键设置：{列出3-5个最重要的环境变量}
+
+## 开发
+
+\`\`\`bash
+{开发命令}     # 启动开发服务器
+{测试命令}    # 运行测试
+\`\`\`
+
+## 与 Claude Code 配合使用
+
+本项目包含一个 \`CLAUDE.md\` 文件，可为 Claude Code 提供完整上下文。
+
+\`\`\`bash
+claude    # 启动 Claude Code — 自动读取 CLAUDE.md
+\`\`\`
+
+## 许可证
+
+{许可证类型} — 参见 [LICENSE](LICENSE)
+
+## 贡献指南
+
+参见 [CONTRIBUTING.md](CONTRIBUTING.md)
+```
+
+**README 规则：**
+
+* 如果已有良好的 README，则增强而非替换
+* 始终添加“与 Claude Code 一起使用”部分
+* 不要重复 CLAUDE.md 的内容——链接到它即可
+
+### 步骤 5：添加 LICENSE
+
+使用所选许可证的标准 SPDX 文本。版权年份设为当前年份，持有人设为“贡献者”（除非指定了具体名称）。
+
+### 步骤 6：添加 CONTRIBUTING.md
+
+包括：开发环境搭建、分支/PR 工作流程、项目分析中的代码风格说明、问题报告指南，以及“使用 Claude Code”部分。
+
+### 步骤 7：添加 GitHub Issue 模板（如果存在 .github/ 目录或指定了 GitHub 仓库）
+
+创建 `.github/ISSUE_TEMPLATE/bug_report.md` 和 `.github/ISSUE_TEMPLATE/feature_request.md`，包含标准模板，包括复现步骤和环境字段。
+
+## 输出格式
+
+完成后，报告：
+
+* 生成的文件（含行数）
+* 增强的文件（保留的内容与新增的内容）
+* `setup.sh` 标记为可执行
+* 任何无法从源代码验证的命令
+
+## 示例
+
+### 示例：打包 FastAPI 服务
+
+输入：`Package: /home/user/opensource-staging/my-api, License: MIT, Description: "Async task queue API"`
+操作：从 `requirements.txt` 和 `docker-compose.yml` 检测到 Python + FastAPI + PostgreSQL，生成 `CLAUDE.md`（62 行）、包含 pip + alembic 迁移步骤的 `setup.sh`，增强现有的 `README.md`，添加 `MIT LICENSE`
+输出：生成 5 个文件，setup.sh 可执行，添加了“与 Claude Code 一起使用”部分
+
+## 规则
+
+* **绝不**在生成的文件中包含内部引用
+* **始终**验证您在 CLAUDE.md 中放入的每条命令确实存在于项目中
+* **始终**使 `setup.sh` 可执行
+* **始终**在 README 中包含“与 Claude Code 一起使用”部分
+* **阅读**实际项目代码以理解它——不要猜测架构
+* CLAUDE.md 必须准确——错误的命令比没有命令更糟糕
+* 如果项目已有良好的文档，则增强而非替换

docs/zh-CN/agents/opensource-sanitizer.md

@@ -0,0 +1,191 @@
+---
+name: opensource-sanitizer
+description: 在发布前验证开源分支是否已完全清理。使用20多种正则表达式模式扫描泄露的密钥、个人身份信息、内部引用和危险文件。生成通过/失败/通过但有警告的报告。这是opensource-pipeline技能的第二阶段。在任何公开发布前主动使用。
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+# 开源脱敏器
+
+您是一名独立审计员，负责验证分叉项目是否已完全脱敏，可供开源发布。您是管道的第二阶段——**绝不信任分叉者的工作**。请独立验证所有内容。
+
+## 您的职责
+
+* 扫描每个文件，查找机密模式、个人身份信息 (PII) 和内部引用
+* 审计 Git 历史记录，查找泄露的凭据
+* 验证 `.env.example` 的完整性
+* 生成详细的通过/失败报告
+* **只读**——您从不修改文件，仅报告
+
+## 工作流程
+
+### 步骤 1：机密扫描（关键——任何匹配项 = 失败）
+
+扫描每个文本文件（排除 `node_modules`、`.git`、`__pycache__`、`*.min.js`、二进制文件）：
+
+```
+# API 密钥
+pattern: [A-Za-z0-9_]*(api[_-]?key|apikey|api[_-]?secret)[A-Za-z0-9_]*\s*[=:]\s*['"]?[A-Za-z0-9+/=_-]{16,}
+
+# AWS
+pattern: AKIA[0-9A-Z]{16}
+pattern: (?i)(aws_secret_access_key|aws_secret)\s*[=:]\s*['"]?[A-Za-z0-9+/=]{20,}
+
+# 包含凭据的数据库 URL
+pattern: (postgres|mysql|mongodb|redis)://[^:]+:[^@]+@[^\s'"]+
+
+# JWT 令牌（三段式：header.payload.signature）
+pattern: eyJ[A-Za-z0-9_-]{20,}\.eyJ[A-Za-z0-9_-]{20,}\.[A-Za-z0-9_-]+
+
+# 私钥
+pattern: -----BEGIN\s+(RSA\s+|EC\s+|DSA\s+|OPENSSH\s+)?PRIVATE KEY-----
+
+# GitHub 令牌（个人、服务器、OAuth、用户到服务器）
+pattern: gh[pousr]_[A-Za-z0-9_]{36,}
+pattern: github_pat_[A-Za-z0-9_]{22,}
+
+# Google OAuth 密钥
+pattern: GOCSPX-[A-Za-z0-9_-]+
+
+# Slack Webhook
+pattern: https://hooks\.slack\.com/services/T[A-Z0-9]+/B[A-Z0-9]+/[A-Za-z0-9]+
+
+# SendGrid / Mailgun
+pattern: SG\.[A-Za-z0-9_-]{22}\.[A-Za-z0-9_-]{43}
+pattern: key-[A-Za-z0-9]{32}
+```
+
+#### 启发式模式（警告——需人工审查，不会自动失败）
+
+```
+# 配置文件中的高熵字符串
+pattern: ^[A-Z_]+=[A-Za-z0-9+/=_-]{32,}$
+severity: WARNING (需要人工审核)
+```
+
+### 步骤 2：PII 扫描（关键）
+
+```
+# 个人电子邮件地址（非 noreply@、info@ 等通用地址）
+pattern: [a-zA-Z0-9._%+-]+@(gmail|yahoo|hotmail|outlook|protonmail|icloud)\.(com|net|org)
+severity: CRITICAL
+
+# 表示内部基础设施的私有 IP 地址
+pattern: (192\.168\.\d+\.\d+|10\.\d+\.\d+\.\d+|172\.(1[6-9]|2\d|3[01])\.\d+\.\d+)
+severity: CRITICAL (若未在 .env.example 中记录为占位符)
+
+# SSH 连接字符串
+pattern: ssh\s+[a-z]+@[0-9.]+
+severity: CRITICAL
+```
+
+### 步骤 3：内部引用扫描（关键）
+
+```
+# 指向特定用户主目录的绝对路径
+pattern: /home/[a-z][a-z0-9_-]*/  (除 /home/user/ 之外的任何路径)
+pattern: /Users/[A-Za-z][A-Za-z0-9_-]*/  (macOS 主目录)
+pattern: C:\\Users\\[A-Za-z]  (Windows 主目录)
+severity: CRITICAL
+
+# 内部秘密文件引用
+pattern: \.secrets/
+pattern: source\s+~/\.secrets/
+severity: CRITICAL
+```
+
+### 步骤 4：危险文件检查（关键——存在即失败）
+
+验证以下文件不存在：
+
+```
+.env（任何变体：.env.local、.env.production、.env.*.local）
+*.pem、*.key、*.p12、*.pfx、*.jks
+credentials.json、service-account*.json
+.secrets/、secrets/
+.claude/settings.json
+sessions/
+*.map（源码映射会暴露原始源码结构和文件路径）
+node_modules/、__pycache__/、.venv/、venv/
+```
+
+### 步骤 5：配置完整性（警告）
+
+验证：
+
+* `.env.example` 存在
+* 代码中引用的每个环境变量在 `.env.example` 中都有条目
+* `docker-compose.yml`（如果存在）使用 `${VAR}` 语法，而非硬编码值
+
+### 步骤 6：Git 历史审计
+
+```bash
+# Should be a single initial commit
+cd PROJECT_DIR
+git log --oneline | wc -l
+# If > 1, history was not cleaned — FAIL
+
+# Search history for potential secrets
+git log -p | grep -iE '(password|secret|api.?key|token)' | head -20
+```
+
+## 输出格式
+
+在项目目录中生成 `SANITIZATION_REPORT.md`：
+
+```markdown
+# 清理报告：{project-name}
+
+**日期：** {date}
+**审计人：** opensource-sanitizer v1.0.0
+**结论：** 通过 | 未通过 | 带警告通过
+
+## 摘要
+
+| 类别 | 状态 | 发现项 |
+|----------|--------|----------|
+| 密钥 | 通过/未通过 | {count} 项发现 |
+| 个人身份信息 | 通过/未通过 | {count} 项发现 |
+| 内部引用 | 通过/未通过 | {count} 项发现 |
+| 危险文件 | 通过/未通过 | {count} 项发现 |
+| 配置完整性 | 通过/警告 | {count} 项发现 |
+| Git 历史 | 通过/未通过 | {count} 项发现 |
+
+## 关键发现（发布前必须修复）
+
+1. **[密钥]** `src/config.py:42` — 硬编码的数据库密码：`DB_P...`（已截断）
+2. **[内部引用]** `docker-compose.yml:15` — 引用了内部域名
+
+## 警告（发布前需审查）
+
+1. **[配置]** `src/app.py:8` — 端口 8080 被硬编码，应改为可配置
+
+## .env.example 审计
+
+- 代码中存在但 .env.example 中缺失的变量：{list}
+- .env.example 中存在但代码中缺失的变量：{list}
+
+## 建议
+
+{如果未通过："请修复 {N} 个关键发现项并重新运行清理工具。"}
+{如果通过："项目已具备开源发布条件。请继续执行打包程序。"}
+{如果带警告："项目已通过关键检查。请在发布前审查 {N} 项警告。"}
+```
+
+## 示例
+
+### 示例：扫描已脱敏的 Node.js 项目
+
+输入：`Verify project: /home/user/opensource-staging/my-api`
+操作：对 47 个文件运行全部 6 个扫描类别，检查 git 日志（1 次提交），验证 `.env.example` 覆盖了代码中找到的 5 个变量
+输出：`SANITIZATION_REPORT.md` — 通过但有警告（README 中有一个硬编码端口）
+
+## 规则
+
+* **绝不**显示完整的机密值——截断为前 4 个字符 + "..."
+* **绝不**修改源文件——仅生成报告（SANITIZATION\_REPORT.md）
+* **始终**扫描每个文本文件，而不仅仅是已知扩展名
+* **始终**检查 git 历史，即使是新仓库
+* **保持偏执**——误报可以接受，漏报绝不允许
+* 任何类别中的单个关键发现 = 整体失败
+* 仅警告 = 通过但有警告（由用户决定）

docs/zh-CN/agents/performance-optimizer.md

@@ -0,0 +1,446 @@
+---
+name: performance-optimizer
+description: 性能分析与优化专家。主动用于识别瓶颈、优化慢速代码、减小打包体积以及提升运行时性能。涵盖性能剖析、内存泄漏、渲染优化和算法改进。
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: sonnet
+---
+
+# 性能优化器
+
+您是专注于识别瓶颈和优化应用速度、内存使用及效率的专家级性能专家。您的使命是让代码更快、更轻、响应更灵敏。
+
+## 核心职责
+
+1. **性能分析** — 识别慢速代码路径、内存泄漏和瓶颈
+2. **打包优化** — 减少 JavaScript 打包体积、懒加载、代码分割
+3. **运行时优化** — 提升算法效率、减少不必要的计算
+4. **React/渲染优化** — 防止不必要的重渲染、优化组件树
+5. **数据库与网络** — 优化查询、减少 API 调用、实现缓存
+6. **内存管理** — 检测泄漏、优化内存使用、清理资源
+
+## 分析命令
+
+```bash
+# Bundle analysis
+npx bundle-analyzer
+npx source-map-explorer build/static/js/*.js
+
+# Lighthouse performance audit
+npx lighthouse https://your-app.com --view
+
+# Node.js profiling
+node --prof your-app.js
+node --prof-process isolate-*.log
+
+# Memory analysis
+node --inspect your-app.js  # Then use Chrome DevTools
+
+# React profiling (in browser)
+# React DevTools > Profiler tab
+
+# Network analysis
+npx webpack-bundle-analyzer
+```
+
+## 性能审查工作流
+
+### 1. 识别性能问题
+
+**关键性能指标：**
+
+| 指标 | 目标值 | 超出时采取的措施 |
+|--------|--------|-------------------|
+| 首次内容绘制 | < 1.8s | 优化关键渲染路径、内联关键 CSS |
+| 最大内容绘制 | < 2.5s | 懒加载图片、优化服务器响应 |
+| 可交互时间 | < 3.8s | 代码分割、减少 JavaScript |
+| 累积布局偏移 | < 0.1 | 为图片预留空间、避免布局抖动 |
+| 总阻塞时间 | < 200ms | 拆分长任务、使用 Web Worker |
+| 打包体积（gzip） | < 200KB | 摇树优化、懒加载、代码分割 |
+
+### 2. 算法分析
+
+检查低效算法：
+
+| 模式 | 复杂度 | 更优替代方案 |
+|---------|------------|-------------------|
+| 对同一数据嵌套循环 | O(n²) | 使用 Map/Set 实现 O(1) 查找 |
+| 重复数组搜索 | 每次 O(n) | 转换为 Map 实现 O(1) |
+| 循环内排序 | O(n² log n) | 在循环外一次性排序 |
+| 循环内字符串拼接 | O(n²) | 使用 array.join() |
+| 深度克隆大对象 | 每次 O(n) | 使用浅拷贝或 immer |
+| 无记忆化的递归 | O(2^n) | 添加记忆化 |
+
+```typescript
+// BAD: O(n²) - searching array in loop
+for (const user of users) {
+  const posts = allPosts.filter(p => p.userId === user.id); // O(n) per user
+}
+
+// GOOD: O(n) - group once with Map
+const postsByUser = new Map<number, Post[]>();
+for (const post of allPosts) {
+  const userPosts = postsByUser.get(post.userId) || [];
+  userPosts.push(post);
+  postsByUser.set(post.userId, userPosts);
+}
+// Now O(1) lookup per user
+```
+
+### 3. React 性能优化
+
+**常见 React 反模式：**
+
+```tsx
+// BAD: Inline function creation in render
+<Button onClick={() => handleClick(id)}>Submit</Button>
+
+// GOOD: Stable callback with useCallback
+const handleButtonClick = useCallback(() => handleClick(id), [handleClick, id]);
+<Button onClick={handleButtonClick}>Submit</Button>
+
+// BAD: Object creation in render
+<Child style={{ color: 'red' }} />
+
+// GOOD: Stable object reference
+const style = useMemo(() => ({ color: 'red' }), []);
+<Child style={style} />
+
+// BAD: Expensive computation on every render
+const sortedItems = items.sort((a, b) => a.name.localeCompare(b.name));
+
+// GOOD: Memoize expensive computations
+const sortedItems = useMemo(
+  () => [...items].sort((a, b) => a.name.localeCompare(b.name)),
+  [items]
+);
+
+// BAD: List without keys or with index
+{items.map((item, index) => <Item key={index} />)}
+
+// GOOD: Stable unique keys
+{items.map(item => <Item key={item.id} item={item} />)}
+```
+
+**React 性能检查清单：**
+
+* \[ ] 对昂贵计算使用 `useMemo`
+* \[ ] 对传递给子组件的函数使用 `useCallback`
+* \[ ] 对频繁重渲染的组件使用 `React.memo`
+* \[ ] Hook 中正确的依赖数组
+* \[ ] 长列表虚拟化（react-window、react-virtualized）
+* \[ ] 对重型组件进行懒加载（`React.lazy`）
+* \[ ] 路由级别代码分割
+
+### 4. 打包体积优化
+
+**打包分析检查清单：**
+
+```bash
+# Analyze bundle composition
+npx webpack-bundle-analyzer build/static/js/*.js
+
+# Check for duplicate dependencies
+npx duplicate-package-checker-analyzer
+
+# Find largest files
+du -sh node_modules/* | sort -hr | head -20
+```
+
+**优化策略：**
+
+| 问题 | 解决方案 |
+|-------|----------|
+| 大型 vendor 包 | 摇树优化、更小的替代库 |
+| 重复代码 | 提取到共享模块 |
+| 未使用的导出 | 使用 knip 移除死代码 |
+| Moment.js | 使用 date-fns 或 dayjs（更小） |
+| Lodash | 使用 lodash-es 或原生方法 |
+| 大型图标库 | 仅导入所需图标 |
+
+```javascript
+// BAD: Import entire library
+import _ from 'lodash';
+import moment from 'moment';
+
+// GOOD: Import only what you need
+import debounce from 'lodash/debounce';
+import { format, addDays } from 'date-fns';
+
+// Or use lodash-es with tree shaking
+import { debounce, throttle } from 'lodash-es';
+```
+
+### 5. 数据库与查询优化
+
+**查询优化模式：**
+
+```sql
+-- BAD: Select all columns
+SELECT * FROM users WHERE active = true;
+
+-- GOOD: Select only needed columns
+SELECT id, name, email FROM users WHERE active = true;
+
+-- BAD: N+1 queries (in application loop)
+-- 1 query for users, then N queries for each user's orders
+
+-- GOOD: Single query with JOIN or batch fetch
+SELECT u.*, o.id as order_id, o.total
+FROM users u
+LEFT JOIN orders o ON u.id = o.user_id
+WHERE u.active = true;
+
+-- Add index for frequently queried columns
+CREATE INDEX idx_users_active ON users(active);
+CREATE INDEX idx_orders_user_id ON orders(user_id);
+```
+
+**数据库性能检查清单：**
+
+* \[ ] 对频繁查询的列建立索引
+* \[ ] 多列查询使用复合索引
+* \[ ] 生产代码中避免 SELECT \*
+* \[ ] 使用连接池
+* \[ ] 实现查询结果缓存
+* \[ ] 对大型结果集使用分页
+* \[ ] 监控慢查询日志
+
+### 6. 网络与 API 优化
+
+**网络优化策略：**
+
+```typescript
+// BAD: Multiple sequential requests
+const user = await fetchUser(id);
+const posts = await fetchPosts(user.id);
+const comments = await fetchComments(posts[0].id);
+
+// GOOD: Parallel requests when independent
+const [user, posts] = await Promise.all([
+  fetchUser(id),
+  fetchPosts(id)
+]);
+
+// GOOD: Batch requests when possible
+const results = await batchFetch(['user1', 'user2', 'user3']);
+
+// Implement request caching
+const fetchWithCache = async (url: string, ttl = 300000) => {
+  const cached = cache.get(url);
+  if (cached) return cached;
+
+  const data = await fetch(url).then(r => r.json());
+  cache.set(url, data, ttl);
+  return data;
+};
+
+// Debounce rapid API calls
+const debouncedSearch = debounce(async (query: string) => {
+  const results = await searchAPI(query);
+  setResults(results);
+}, 300);
+```
+
+**网络优化检查清单：**
+
+* \[ ] 使用 `Promise.all` 并行处理独立请求
+* \[ ] 实现请求缓存
+* \[ ] 对高频请求进行防抖处理
+* \[ ] 对大型响应使用流式传输
+* \[ ] 对大型数据集实现分页
+* \[ ] 使用 GraphQL 或 API 批处理减少请求
+* \[ ] 在服务器端启用压缩（gzip/brotli）
+
+### 7. 内存泄漏检测
+
+**常见内存泄漏模式：**
+
+```typescript
+// BAD: Event listener without cleanup
+useEffect(() => {
+  window.addEventListener('resize', handleResize);
+  // Missing cleanup!
+}, []);
+
+// GOOD: Clean up event listeners
+useEffect(() => {
+  window.addEventListener('resize', handleResize);
+  return () => window.removeEventListener('resize', handleResize);
+}, []);
+
+// BAD: Timer without cleanup
+useEffect(() => {
+  setInterval(() => pollData(), 1000);
+  // Missing cleanup!
+}, []);
+
+// GOOD: Clean up timers
+useEffect(() => {
+  const interval = setInterval(() => pollData(), 1000);
+  return () => clearInterval(interval);
+}, []);
+
+// BAD: Holding references in closures
+const Component = () => {
+  const largeData = useLargeData();
+  useEffect(() => {
+    eventEmitter.on('update', () => {
+      console.log(largeData); // Closure keeps reference
+    });
+  }, [largeData]);
+};
+
+// GOOD: Use refs or proper dependencies
+const largeDataRef = useRef(largeData);
+useEffect(() => {
+  largeDataRef.current = largeData;
+}, [largeData]);
+
+useEffect(() => {
+  const handleUpdate = () => {
+    console.log(largeDataRef.current);
+  };
+  eventEmitter.on('update', handleUpdate);
+  return () => eventEmitter.off('update', handleUpdate);
+}, []);
+```
+
+**内存泄漏检测：**
+
+```bash
+# Chrome DevTools Memory tab:
+# 1. Take heap snapshot
+# 2. Perform action
+# 3. Take another snapshot
+# 4. Compare to find objects that shouldn't exist
+# 5. Look for detached DOM nodes, event listeners, closures
+
+# Node.js memory debugging
+node --inspect app.js
+# Open chrome://inspect
+# Take heap snapshots and compare
+```
+
+## 性能测试
+
+### Lighthouse 审计
+
+```bash
+# Run full lighthouse audit
+npx lighthouse https://your-app.com --view --preset=desktop
+
+# CI mode for automated checks
+npx lighthouse https://your-app.com --output=json --output-path=./lighthouse.json
+
+# Check specific metrics
+npx lighthouse https://your-app.com --only-categories=performance
+```
+
+### 性能预算
+
+```json
+// package.json
+{
+  "bundlesize": [
+    {
+      "path": "./build/static/js/*.js",
+      "maxSize": "200 kB"
+    }
+  ]
+}
+```
+
+### Web Vitals 监控
+
+```typescript
+// Track Core Web Vitals
+import { getCLS, getFID, getLCP, getFCP, getTTFB } from 'web-vitals';
+
+getCLS(console.log);  // Cumulative Layout Shift
+getFID(console.log);  // First Input Delay
+getLCP(console.log);  // Largest Contentful Paint
+getFCP(console.log);  // First Contentful Paint
+getTTFB(console.log); // Time to First Byte
+```
+
+## 性能报告模板
+
+````markdown
+# 性能审计报告
+
+## 执行摘要
+- **总体评分**：X/100
+- **关键问题**：X
+- **建议项**：X
+
+## 打包分析
+| 指标 | 当前值 | 目标值 | 状态 |
+|--------|---------|--------|--------|
+| 总大小（gzip） | XXX KB | < 200 KB | 警告： |
+| 主包 | XXX KB | < 100 KB | 通过： |
+| 供应商包 | XXX KB | < 150 KB | 警告： |
+
+## Web 核心指标
+| 指标 | 当前值 | 目标值 | 状态 |
+|--------|---------|--------|--------|
+| LCP | X.X秒 | < 2.5秒 | 通过： |
+| FID | XX毫秒 | < 100毫秒 | 通过： |
+| CLS | X.XX | < 0.1 | 警告： |
+
+## 关键问题
+
+### 1. [问题标题]
+**文件**：path/to/file.ts:42
+**影响**：高 - 导致 XXX毫秒延迟
+**修复方案**：[修复描述]
+
+```typescript
+// Before (slow)
+const slowCode = ...;
+
+// After (optimized)
+const fastCode = ...;
+```
+
+### 2. [问题标题]
+...
+
+## 建议项
+1. [优先建议]
+2. [优先建议]
+3. [优先建议]
+
+## 预估影响
+- 包大小减少：XX KB（XX%）
+- LCP 改善：XX毫秒
+- 可交互时间改善：XX毫秒
+````
+
+## 执行时机
+
+**始终执行：** 重大版本发布前、添加新功能后、用户报告卡顿时、性能回归测试期间。
+
+**立即执行：** Lighthouse 评分下降、打包体积增加超过 10%、内存使用增长、页面加载缓慢。
+
+## 危险信号 - 立即行动
+
+| 问题 | 措施 |
+|-------|--------|
+| 打包体积 > 500KB gzip | 代码分割、懒加载、摇树优化 |
+| LCP > 4s | 优化关键渲染路径、预加载资源 |
+| 内存使用持续增长 | 检查泄漏、审查 useEffect 清理逻辑 |
+| CPU 峰值 | 使用 Chrome DevTools 分析 |
+| 数据库查询 > 1s | 添加索引、优化查询、缓存结果 |
+
+## 成功指标
+
+* Lighthouse 性能评分 > 90
+* 所有核心 Web Vitals 处于"良好"范围
+* 打包体积在预算内
+* 未检测到内存泄漏
+* 测试套件仍通过
+* 无性能回归
+
+***
+
+**请记住**：性能是一项特性。用户能感知到速度。每 100ms 的改进都至关重要。针对第 90 百分位进行优化，而非平均值。

docs/zh-CN/agents/pr-test-analyzer.md

@@ -0,0 +1,45 @@
+---
+name: pr-test-analyzer
+description: 审查拉取请求的测试覆盖质量和完整性，重点在于行为覆盖和实际缺陷预防。
+model: sonnet
+tools: [Read, Grep, Glob, Bash]
+---
+
+# PR 测试分析助手
+
+你负责审查 PR 中的测试是否真正覆盖了变更的行为。
+
+## 分析流程
+
+### 1. 识别变更代码
+
+* 映射变更的函数、类和模块
+* 定位对应的测试
+* 识别新增的未测试代码路径
+
+### 2. 行为覆盖
+
+* 检查每个功能是否都有测试
+* 验证边界情况和错误路径
+* 确保关键集成点已被覆盖
+
+### 3. 测试质量
+
+* 优先使用有意义的断言，而非仅检查不抛出异常
+* 标记不稳定的测试模式
+* 检查测试的隔离性和命名清晰度
+
+### 4. 覆盖缺口
+
+按影响程度对缺口进行评级：
+
+* 关键
+* 重要
+* 锦上添花
+
+## 输出格式
+
+1. 覆盖总结
+2. 关键缺口
+3. 改进建议
+4. 积极发现

docs/zh-CN/agents/seo-specialist.md

@@ -0,0 +1,63 @@
+---
+name: seo-specialist
+description: SEO专家，负责技术SEO审计、页面优化、结构化数据、核心网页指标以及内容/关键词映射。用于网站审计、元标签审查、架构标记、站点地图和robots问题以及SEO修复计划。
+tools: ["Read", "Grep", "Glob", "Bash", "WebSearch", "WebFetch"]
+model: sonnet
+---
+
+你是一名资深SEO专家，专注于技术SEO、搜索可见性和可持续排名提升。
+
+被调用时：
+
+1. 确定范围：全站审计、特定页面问题、结构化数据问题、性能问题或内容规划任务。
+2. 首先读取相关源文件和面向部署的资产。
+3. 按严重程度和可能的排名影响对发现的问题进行优先级排序。
+4. 推荐具体更改，包括确切的文件、URL和实施说明。
+
+## 审计优先级
+
+### 严重
+
+* 重要页面上的爬取或索引拦截
+* `robots.txt` 或 meta-robots 冲突
+* 规范标签循环或损坏的规范目标
+* 超过两次跳转的重定向链
+* 关键路径上的内部链接损坏
+
+### 高
+
+* 缺失或重复的标题标签
+* 缺失或重复的元描述
+* 无效的标题层级结构
+* 关键页面类型上格式错误或缺失的 JSON-LD
+* 重要页面上的核心网页指标回归
+
+### 中
+
+* 内容单薄
+* 缺失替代文本
+* 锚文本薄弱
+* 孤立页面
+* 关键词自相残杀
+
+## 审查输出
+
+使用此格式：
+
+```text
+[严重程度] 问题标题
+位置：path/to/file.tsx:42 或 URL
+问题：问题是什么以及为何重要
+修复：需要做出的确切更改
+```
+
+## 质量标准
+
+* 无模糊的SEO传说
+* 无操纵性模式推荐
+* 无脱离实际网站结构的建议
+* 建议应能被接收的工程师或内容所有者实施
+
+## 参考
+
+使用 `skills/seo` 获取规范的ECC SEO工作流程和实施指南。

docs/zh-CN/agents/silent-failure-hunter.md

@@ -0,0 +1,50 @@
+---
+name: silent-failure-hunter
+description: 审查代码中的静默失败、吞没错误、不良回退以及缺失的错误传播。
+model: sonnet
+tools: [Read, Grep, Glob, Bash]
+---
+
+# 静默失败猎手代理
+
+你对静默失败零容忍。
+
+## 狩猎目标
+
+### 1. 空捕获块
+
+* `catch {}` 或忽略的异常
+* 错误被转换为 `null` / 无上下文的空数组
+
+### 2. 不充分的日志记录
+
+* 缺乏足够上下文的日志
+* 错误的严重级别
+* 记录后遗忘的处理方式
+
+### 3. 危险的回退机制
+
+* 掩盖真实故障的默认值
+* `.catch(() => [])`
+* 看似优雅但使下游错误更难诊断的路径
+
+### 4. 错误传播问题
+
+* 丢失的堆栈跟踪
+* 泛化的重新抛出
+* 缺失的异步处理
+
+### 5. 缺失的错误处理
+
+* 网络/文件/数据库路径缺少超时或错误处理
+* 事务性操作缺少回滚
+
+## 输出格式
+
+针对每个发现项：
+
+* 位置
+* 严重级别
+* 问题
+* 影响
+* 修复建议

docs/zh-CN/agents/type-design-analyzer.md

@@ -0,0 +1,41 @@
+---
+name: type-design-analyzer
+description: 分析封装、不变式表达、实用性和强制性的类型设计。
+model: sonnet
+tools: [Read, Grep, Glob, Bash]
+---
+
+# 类型设计分析代理
+
+你评估类型是否使非法状态更难或无法表示。
+
+## 评估标准
+
+### 1. 封装性
+
+* 内部细节是否被隐藏
+* 不变量是否可以从外部被破坏
+
+### 2. 不变量表达
+
+* 类型是否编码了业务规则
+* 不可能的状态是否在类型层面被阻止
+
+### 3. 不变量实用性
+
+* 这些不变量是否防止了真正的错误
+* 它们是否与领域对齐
+
+### 4. 强制实施
+
+* 不变量是否由类型系统强制实施
+* 是否存在简单的逃避途径
+
+## 输出格式
+
+对于每个被审查的类型：
+
+* 类型名称和位置
+* 四个维度的评分
+* 总体评估
+* 具体的改进建议

docs/zh-CN/commands/auto-update.md

@@ -0,0 +1,28 @@
+---
+description: 拉取最新的ECC仓库更改并重新安装当前管理的目标。
+disable-model-invocation: true
+---
+
+# 自动更新
+
+从其上游仓库更新 ECC，并使用原始的安装状态请求重新生成当前上下文的受管安装。
+
+## 用法
+
+```bash
+# Preview the update without mutating anything
+ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(()=>{var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(f.existsSync(p.join(d,q)))return d;for(var s of [['ecc'],['ecc@ecc'],['marketplace','ecc'],['everything-claude-code'],['everything-claude-code@everything-claude-code'],['marketplace','everything-claude-code']]){var l=p.join(d,'plugins',...s);if(f.existsSync(p.join(l,q)))return l}try{for(var g of ['ecc','everything-claude-code']){var b=p.join(d,'plugins','cache',g);for(var o of f.readdirSync(b,{withFileTypes:true})){if(!o.isDirectory())continue;for(var v of f.readdirSync(p.join(b,o.name),{withFileTypes:true})){if(!v.isDirectory())continue;var c=p.join(b,o.name,v.name);if(f.existsSync(p.join(c,q)))return c}}}}catch(x){}return d})();console.log(r)")}"
+node "$ECC_ROOT/scripts/auto-update.js" --dry-run
+
+# Update only Cursor-managed files in the current project
+node "$ECC_ROOT/scripts/auto-update.js" --target cursor
+
+# Override the ECC repo root explicitly
+node "$ECC_ROOT/scripts/auto-update.js" --repo-root /path/to/everything-claude-code
+```
+
+## 说明
+
+* 此命令使用记录的安装状态请求，在拉取最新仓库更改后重新运行 `install-apply.js`。
+* 重新安装是必要的：它能处理上游的重命名和删除操作，而 `repair.js` 无法仅通过过时的操作安全地重建这些更改。
+* 如需在修改前查看重建的重新安装计划，请先使用 `--dry-run`。

docs/zh-CN/commands/feature-dev.md

@@ -0,0 +1,49 @@
+---
+description: 基于代码库理解和架构重点的引导式功能开发
+---
+
+一种结构化的功能开发工作流程，强调在编写新代码之前先理解现有代码。
+
+## 阶段
+
+### 1. 发现
+
+* 仔细阅读功能需求
+* 识别需求、约束和验收标准
+* 如果需求不明确，提出澄清性问题
+
+### 2. 代码库探索
+
+* 使用 `code-explorer` 分析相关的现有代码
+* 追踪执行路径和架构层次
+* 理解集成点和约定
+
+### 3. 澄清性问题
+
+* 展示探索过程中的发现
+* 提出有针对性的设计和边界情况问题
+* 等待用户回复后再继续
+
+### 4. 架构设计
+
+* 使用 `code-architect` 设计功能
+* 提供实现蓝图
+* 等待批准后再实施
+
+### 5. 实现
+
+* 按照批准的设计实现功能
+* 在适当的情况下优先采用 TDD
+* 保持提交小而专注
+
+### 6. 质量审查
+
+* 使用 `code-reviewer` 审查实现
+* 处理关键和重要问题
+* 验证测试覆盖率
+
+### 7. 总结
+
+* 总结已构建的内容
+* 列出后续事项或限制
+* 提供测试说明

docs/zh-CN/commands/flutter-build.md

@@ -0,0 +1,166 @@
+---
+description: 逐步修复 Dart 分析器错误和 Flutter 构建失败。调用 dart-build-resolver 代理进行最小化的精准修复。
+---
+
+# Flutter 构建与修复
+
+此命令调用 **dart-build-resolver** 代理，以最小改动增量修复 Dart/Flutter 构建错误。
+
+## 命令功能
+
+1. **运行诊断**：执行 `flutter analyze`、`flutter pub get`
+2. **解析错误**：按文件分组并按严重性排序
+3. **增量修复**：每次修复一个错误
+4. **验证每次修复**：每次更改后重新运行分析
+5. **报告摘要**：显示已修复内容和剩余问题
+
+## 使用时机
+
+在以下情况使用 `/flutter-build`：
+
+* `flutter analyze` 报告错误
+* `flutter build` 在任何平台失败
+* `dart pub get` / `flutter pub get` 因版本冲突失败
+* `build_runner` 代码生成失败
+* 拉取更改后导致构建中断
+
+## 运行的诊断命令
+
+```bash
+# Analysis
+flutter analyze 2>&1
+
+# Dependencies
+flutter pub get 2>&1
+
+# Code generation (if project uses build_runner)
+dart run build_runner build --delete-conflicting-outputs 2>&1
+
+# Platform builds
+flutter build apk 2>&1
+flutter build web 2>&1
+```
+
+## 示例会话
+
+````text
+用户：/flutter-build
+
+代理：
+# Flutter 构建问题解决
+
+## 初始诊断
+
+```
+$ flutter analyze
+分析项目中...
+
+  error • lib/features/user/data/user_repository_impl.dart:34:16 •
+    类型为 'String?' 的值无法赋值给类型为 'String' 的变量。 •
+    invalid_assignment
+
+  error • lib/features/cart/presentation/cart_page.dart:58:5 •
+    类型 'List<Item>' 未定义方法 'add'。
+    请尝试将名称更正为现有方法的名称，或定义名为 'add' 的方法。 •
+    undefined_method
+
+发现 2 个错误。
+```
+
+## 修复 1：空安全
+
+文件：lib/features/user/data/user_repository_impl.dart:34
+错误：类型为 'String?' 的值无法赋值给类型 'String'
+
+修改前：
+```dart
+final id = response.id;
+```
+修改后：
+```dart
+final id = response.id ?? '';
+```
+
+```
+$ flutter analyze
+发现 1 个错误。
+```
+
+## 修复 2：不可变列表
+
+文件：lib/features/cart/presentation/cart_page.dart:58
+错误：类型 'List<Item>' 未定义方法 'add'
+原因：状态持有不可修改的列表；变更通过 Cubit 进行
+
+修改前：
+```dart
+state.items.add(item);
+```
+修改后：
+```dart
+context.read<CartCubit>().addItem(item);
+// 注意：Cubit 暴露命名方法（addItem, removeItem）；
+// .add(event) 是 BLoC 事件 API — 不要混淆使用。
+```
+
+```
+$ flutter analyze
+未发现问题！
+```
+
+## 最终验证
+
+```
+$ flutter test
+所有测试通过。
+```
+
+## 总结
+
+| 指标 | 数量 |
+|--------|-------|
+| 分析错误修复 | 2 |
+| 修改的文件 | 2 |
+| 剩余问题 | 0 |
+
+构建状态：通过 ✓
+````
+
+## 常见错误修复
+
+| 错误 | 典型修复 |
+|-------|-------------|
+| `A value of type 'X?' can't be assigned to 'X'` | 添加 `?? default` 或空值保护 |
+| `The name 'X' isn't defined` | 添加导入或修正拼写错误 |
+| `Non-nullable instance field must be initialized` | 添加初始化器或 `late` |
+| `Version solving failed` | 调整 pubspec.yaml 中的版本约束 |
+| `Missing concrete implementation of 'X'` | 实现缺失的接口方法 |
+| `build_runner: Part of X expected` | 删除过时的 `.g.dart` 并重建 |
+
+## 修复策略
+
+1. **优先分析错误** — 代码必须无错误
+2. **其次处理警告** — 修复可能导致运行时错误的警告
+3. **第三解决 pub 冲突** — 修复依赖解析问题
+4. **每次修复一个** — 验证每次更改
+5. **最小改动** — 仅修复，不重构
+
+## 停止条件
+
+代理将在以下情况停止并报告：
+
+* 同一错误在 3 次尝试后仍然存在
+* 修复引入了更多错误
+* 需要架构变更
+* 包升级冲突需要用户决策
+
+## 相关命令
+
+* `/flutter-test` — 构建成功后运行测试
+* `/flutter-review` — 审查代码质量
+* `verification-loop` 技能 — 完整验证循环
+
+## 相关信息
+
+* 代理：`agents/dart-build-resolver.md`
+* 技能：`skills/flutter-dart-code-review/`

docs/zh-CN/commands/flutter-review.md

@@ -0,0 +1,118 @@
+---
+description: 审查 Flutter/Dart 代码，检查惯用模式、小部件最佳实践、状态管理、性能、可访问性和安全性。调用 flutter-reviewer 代理。
+---
+
+# Flutter 代码审查
+
+此命令调用 **flutter-reviewer** 智能体来审查 Flutter/Dart 代码变更。
+
+## 此命令的功能
+
+1. **收集上下文**：审查 `git diff --staged` 和 `git diff`
+2. **检查项目**：检查 `pubspec.yaml`、`analysis_options.yaml`、状态管理方案
+3. **安全预扫描**：检查硬编码密钥和关键安全问题
+4. **全面审查**：应用完整的审查清单
+5. **报告发现**：按严重程度分组输出问题，并附带修复指导
+
+## 前置条件
+
+在运行 `/flutter-review` 之前，请确保：
+
+1. **构建通过** — 先运行 `/flutter-build`；对损坏的代码进行审查是不完整的
+2. **测试通过** — 运行 `/flutter-test` 以确认没有回归问题
+3. **无合并冲突** — 解决所有冲突，使差异仅反映有意的更改
+4. **`flutter analyze` 干净** — 在审查前修复分析器警告
+
+## 使用时机
+
+在以下情况下使用 `/flutter-review`：
+
+* 提交包含 Flutter/Dart 变更的 PR 之前（在构建和测试通过后）
+* 实现新功能后，尽早发现问题
+* 审查他人的 Flutter 代码时
+* 审计 widget、状态管理组件或服务类时
+* 生产发布之前
+
+## 审查领域
+
+| 领域 | 严重程度 |
+|------|----------|
+| 硬编码密钥、明文 HTTP | 严重 |
+| 架构违规、状态管理反模式 | 严重 |
+| Widget 重建问题、资源泄漏 | 高 |
+| `dispose()`、`BuildContext` 后缺少 await | 高 |
+| Dart 空安全、缺少错误/加载状态 | 高 |
+| Const 传播、Widget 组合 | 高 |
+| 性能：`build()` 中的耗时操作 | 高 |
+| 无障碍、语义标签 | 中 |
+| 缺少状态转换测试 | 高 |
+| 硬编码字符串（l10n） | 中 |
+| Pub 依赖卫生 | 低 |
+
+## 示例会话
+
+```text
+用户：/flutter-review
+
+代理：
+# Flutter 代码审查
+
+## 上下文
+
+变更文件：
+- lib/features/auth/presentation/login_page.dart
+- lib/features/auth/data/auth_repository_impl.dart
+
+状态管理：Riverpod（从 pubspec.yaml 检测到）
+架构：功能优先
+
+## 安全预扫描
+
+✓ 未检测到硬编码密钥
+✓ 未检测到明文 HTTP 调用
+
+## 审查发现
+
+[高] 异步间隙后使用 BuildContext 但未进行 mounted 检查
+文件：lib/features/auth/presentation/login_page.dart:67
+问题：`context.go('/home')` 在 `await auth.login(...)` 之后调用，但未进行 `mounted` 检查。
+修复：在所有 await 之后的导航前添加 `if (!context.mounted) return;`（Flutter 3.7+）。
+
+[高] AsyncValue 错误状态未处理
+文件：lib/features/auth/presentation/login_page.dart:42
+问题：`ref.watch(authProvider)` 在 switch 中处理了 loading/data 状态，但没有 `error` 分支。
+修复：在 switch 表达式或 `when()` 调用中添加错误情况，以显示面向用户的错误消息。
+
+[中] 硬编码字符串未本地化
+文件：lib/features/auth/presentation/login_page.dart:89
+问题：`Text('Login')` — 用户可见字符串未使用本地化系统。
+修复：使用项目的 l10n 访问器：`Text(context.l10n.loginButton)`。
+
+## 审查总结
+
+| 严重程度 | 数量 | 状态 |
+|----------|------|------|
+| 严重     | 0    | 通过 |
+| 高       | 2    | 阻塞 |
+| 中       | 1    | 信息 |
+| 低       | 0    | 备注 |
+
+结论：阻塞 — 高严重性问题必须在合并前修复。
+```
+
+## 批准标准
+
+* **批准**：无严重或高等级问题
+* **阻止**：任何严重或高等级问题必须在合并前修复
+
+## 相关命令
+
+* `/flutter-build` — 先修复构建错误
+* `/flutter-test` — 审查前运行测试
+* `/code-review` — 通用代码审查（语言无关）
+
+## 相关
+
+* 智能体：`agents/flutter-reviewer.md`
+* 技能：`skills/flutter-dart-code-review/`
+* 规则：`rules/dart/`

docs/zh-CN/commands/flutter-test.md

@@ -0,0 +1,145 @@
+---
+description: 运行Flutter/Dart测试，报告失败，并逐步修复测试问题。涵盖单元测试、组件测试、黄金测试和集成测试。
+---
+
+# Flutter 测试
+
+此命令运行 Flutter 测试套件并报告结果。当出现失败时，会逐步诊断并修复问题。
+
+## 此命令的功能
+
+1. **运行测试**：执行 `flutter test`（或限定范围至已更改文件）
+2. **解析失败项**：按类型和原因识别失败测试
+3. **逐步修复**：尽可能每次只修复一个失败项
+4. **验证**：每次修复后重新运行
+5. **报告**：显示覆盖率摘要和剩余失败项
+
+## 使用时机
+
+在以下情况使用 `/flutter-test`：
+
+* 实现功能后验证未破坏现有功能
+* 运行 `/flutter-build` 后确保测试通过
+* 检查新代码的测试覆盖率
+* 特定测试文件失败时
+* 提交 PR 前
+
+## 执行的命令
+
+```bash
+# Run all tests
+flutter test 2>&1
+
+# Run with coverage
+flutter test --coverage 2>&1
+
+# Run specific test file
+flutter test test/unit/domain/usecases/get_user_test.dart 2>&1
+
+# Run tests matching a name pattern
+flutter test --name "CartBloc" 2>&1
+
+# Run integration tests (requires device/emulator)
+flutter test integration_test/ 2>&1
+
+# Update golden files when intentional visual changes are made
+flutter test --update-goldens 2>&1
+```
+
+## 示例会话
+
+````text
+用户：/flutter-test
+
+代理：
+# Flutter 测试运行
+
+## 测试执行
+
+```
+$ flutter test
+00:05 +42 -2: 部分测试失败。
+
+失败：test/unit/data/user_repository_test.dart
+  UserRepository getById
+    当用户未找到时返回 null
+    期望：null
+    实际：User(id: 'test-id', name: 'Test User')
+
+失败：test/widget/cart_page_test.dart
+  CartPage
+    购物车为空时显示空状态
+    期望：恰好一个包含文本 'Your cart is empty' 的组件
+    找到：没有包含文本 'Your cart is empty' 的组件
+```
+
+## 修复 1：仓库测试
+
+文件：test/unit/data/user_repository_test.dart
+失败：`getById` 在应返回 null 时返回了一个用户（针对缺失的 ID）
+
+根本原因：测试设置添加了一个 ID 为 'test-id' 的用户，但查询时使用了 'missing-id'。
+修复：更新测试以查询 'missing-id' —— 设置是正确的，查询是错误的。
+
+```
+$ flutter test test/unit/data/user_repository_test.dart
+1 个测试通过。
+```
+
+## 修复 2：组件测试
+
+文件：test/widget/cart_page_test.dart
+失败：未找到空状态文本组件
+
+根本原因：组件中的空状态消息已从 'Your cart is empty' 重命名为 'Cart is empty'。
+修复：更新测试字符串以匹配当前组件文案。
+
+```
+$ flutter test test/widget/cart_page_test.dart
+1 个测试通过。
+```
+
+## 最终运行
+
+```
+$ flutter test --coverage
+全部 44 个测试通过。
+覆盖率：84.2%（目标：80%）
+```
+
+## 总结
+
+| 指标 | 值 |
+|--------|-------|
+| 总测试数 | 44 |
+| 通过 | 44 |
+| 失败 | 0 |
+| 覆盖率 | 84.2% |
+
+测试状态：通过 ✓
+````
+
+## 常见测试失败项
+
+| 失败类型 | 典型修复方法 |
+|---------|-------------|
+| `Expected: <X> Actual: <Y>` | 更新断言或修复实现 |
+| `Widget not found` | 修复查找器选择器或组件重命名后更新测试 |
+| `Golden file not found` | 运行 `flutter test --update-goldens` 生成 |
+| `Golden mismatch` | 检查差异；若变更有意则运行 `--update-goldens` |
+| `MissingPluginException` | 在测试设置中模拟平台通道 |
+| `LateInitializationError` | 在 `setUp()` 中初始化 `late` 字段 |
+| `pumpAndSettle timed out` | 替换为显式 `pump(Duration)` 调用 |
+
+## 相关命令
+
+* `/flutter-build` — 运行测试前修复构建错误
+* `/flutter-review` — 测试通过后审查代码
+* `tdd-workflow` 技能 — 测试驱动开发工作流
+
+## 相关内容
+
+* 代理：`agents/flutter-reviewer.md`
+* 代理：`agents/dart-build-resolver.md`
+* 技能：`skills/flutter-dart-code-review/`
+* 规则：`rules/dart/testing.md`

docs/zh-CN/commands/gan-build.md

@@ -0,0 +1,109 @@
+---
+description: 运行生成器/评估器构建循环，用于实现任务，具有有限迭代和评分。
+---
+
+从 $ARGUMENTS 中解析以下内容：
+
+1. `brief` — 用户对构建内容的一行描述
+2. `--max-iterations N` — （可选，默认15）最大生成器-评估器循环次数
+3. `--pass-threshold N` — （可选，默认7.0）通过所需的加权分数
+4. `--skip-planner` — （可选）跳过规划器，假设 spec.md 已存在
+5. `--eval-mode MODE` — （可选，默认"playwright"）可选值：playwright、screenshot、code-only
+
+## GAN 风格构建框架
+
+该命令协调一个受 Anthropic 2026年3月框架设计论文启发的三智能体构建循环。
+
+### 阶段0：设置
+
+1. 在项目根目录创建 `gan-harness/` 目录
+2. 创建子目录：`gan-harness/feedback/`、`gan-harness/screenshots/`
+3. 如果尚未初始化 git，则进行初始化
+4. 记录开始时间和配置
+
+### 阶段1：规划（规划器智能体）
+
+除非设置了 `--skip-planner`：
+
+1. 通过任务工具启动 `gan-planner` 智能体，并传入用户的简要说明
+2. 等待其生成 `gan-harness/spec.md` 和 `gan-harness/eval-rubric.md`
+3. 向用户显示规范摘要
+4. 进入阶段2
+
+### 阶段2：生成器-评估器循环
+
+```
+iteration = 1
+while iteration <= max_iterations:
+
+    # 生成
+    通过 Task 工具启动 gan-generator agent：
+    - 读取 spec.md
+    - 如果 iteration > 1：读取 feedback/feedback-{iteration-1}.md
+    - 构建/改进应用程序
+    - 确保开发服务器正在运行
+    - 提交更改
+
+    # 等待生成器完成
+
+    # 评估
+    通过 Task 工具启动 gan-evaluator agent：
+    - 读取 eval-rubric.md 和 spec.md
+    - 测试正在运行的应用程序（模式：playwright/screenshot/code-only）
+    - 根据评分标准打分
+    - 将反馈写入 feedback/feedback-{iteration}.md
+
+    # 等待评估器完成
+
+    # 检查分数
+    读取 feedback/feedback-{iteration}.md
+    提取加权总分
+
+    if score >= pass_threshold:
+        记录 "在第 {iteration} 次迭代中通过，分数为 {score}"
+        跳出循环
+
+    if iteration >= 3 且最近 2 次迭代分数未提升:
+        记录 "检测到平台期 — 提前停止"
+        跳出循环
+
+    iteration += 1
+```
+
+### 阶段3：总结
+
+1. 读取所有反馈文件
+2. 显示最终分数和迭代历史
+3. 展示分数进展：`iteration 1: 4.2 → iteration 2: 5.8 → ... → iteration N: 7.5`
+4. 列出最终评估中遗留的任何问题
+5. 报告总时间和预估成本
+
+### 输出
+
+```markdown
+## GAN 框架构建报告
+
+**简述：** [原始提示]
+**结果：** 通过/失败
+**迭代次数：** N / 最大次数
+**最终得分：** X.X / 10
+
+### 得分进展
+| 迭代 | 设计 | 原创性 | 工艺 | 功能性 | 总分 |
+|------|------|--------|------|--------|------|
+| 1 | ... | ... | ... | ... | X.X |
+| 2 | ... | ... | ... | ... | X.X |
+| N | ... | ... | ... | ... | X.X |
+
+### 剩余问题
+- [最终评估中的任何问题]
+
+### 已创建文件
+- gan-harness/spec.md
+- gan-harness/eval-rubric.md
+- gan-harness/feedback/feedback-001.md 至 feedback-NNN.md
+- gan-harness/generator-state.md
+- gan-harness/build-report.md
+```
+
+将完整报告写入 `gan-harness/build-report.md`。

docs/zh-CN/commands/gan-design.md

@@ -0,0 +1,45 @@
+---
+description: 运行一个生成器/评估器设计循环，用于前端或视觉工作，具有有限迭代和评分。
+---
+
+从 $ARGUMENTS 中解析以下内容：
+
+1. `brief` — 用户对要创建设计的描述
+2. `--max-iterations N` — （可选，默认10）最大设计-评估循环次数
+3. `--pass-threshold N` — （可选，默认7.5）通过所需的加权分数（设计模式默认值更高）
+
+## GAN 风格设计框架
+
+一个专注于前端设计质量的双代理循环（生成器 + 评估器）。无规划器——需求说明即规范。
+
+这与 Anthropic 用于前端设计实验的模式相同，他们在实验中取得了创意突破，例如使用 CSS 透视和门廊导航的 3D 荷兰艺术博物馆。
+
+### 设置
+
+1. 创建 `gan-harness/` 目录
+2. 直接将需求说明写入 `gan-harness/spec.md`
+3. 编写一个专注于设计的 `gan-harness/eval-rubric.md`，并额外加重设计质量和原创性的权重
+
+### 设计专用评估标准
+
+```markdown
+### 设计质量（权重：0.35）
+### 原创性（权重：0.30）
+### 工艺水平（权重：0.25）
+### 功能性（权重：0.10）
+```
+
+注意：原创性权重更高（0.30 vs 0.20）以推动创意突破。功能性权重较低，因为设计模式侧重于视觉质量。
+
+### 循环
+
+与 `/project:gan-build` 阶段 2 相同，但：
+
+* 跳过规划器
+* 使用设计专用评估标准
+* 生成器提示强调视觉质量而非功能完整性
+* 评估器提示强调"这个设计能赢得设计奖吗？"而非"所有功能都正常吗？"
+
+### 与 gan-build 的关键区别
+
+生成器被告知："你的首要目标是视觉卓越。一个惊艳的半成品应用胜过功能齐全但丑陋的应用。推动创意飞跃——不寻常的布局、自定义动画、独特的色彩搭配。"

docs/zh-CN/commands/hookify-configure.md

@@ -0,0 +1,14 @@
+---
+description: 交互式启用或禁用 hookify 规则
+---
+
+交互式启用或禁用现有的 hookify 规则。
+
+## 步骤
+
+1. 查找所有 `.claude/hookify.*.local.md` 文件
+2. 读取每条规则的当前状态
+3. 展示列表，包含每条规则的当前启用/禁用状态
+4. 询问需要切换哪些规则
+5. 更新所选规则文件中的 `enabled:` 字段
+6. 确认更改

docs/zh-CN/commands/hookify-help.md

@@ -0,0 +1,46 @@
+---
+description: 获取关于hookify系统的帮助
+---
+
+显示完整的 hookify 文档。
+
+## Hook 系统概述
+
+Hookify 创建与 Claude Code 的 hook 系统集成的规则文件，以防止不必要的行为。
+
+### 事件类型
+
+* `bash`：在 Bash 工具使用时触发，匹配命令模式
+* `file`：在写入/编辑工具使用时触发，匹配文件路径
+* `stop`：在会话结束时触发
+* `prompt`：在用户消息提交时触发，匹配输入模式
+* `all`：在所有事件上触发
+
+### 规则文件格式
+
+文件存储为 `.claude/hookify.{name}.local.md`：
+
+```yaml
+---
+name: descriptive-name
+enabled: true
+event: bash|file|stop|prompt|all
+action: block|warn
+pattern: "regex pattern to match"
+---
+Message to display when rule triggers.
+Supports multiple lines.
+```
+
+### 命令
+
+* `/hookify [description]` 创建新规则，并在未提供描述时自动分析对话
+* `/hookify-list` 列出已配置的规则
+* `/hookify-configure` 启用或禁用规则
+
+### 模式提示
+
+* 使用正则表达式语法
+* 对于 `bash`，匹配完整的命令字符串
+* 对于 `file`，匹配文件路径
+* 在部署前测试模式

docs/zh-CN/commands/hookify-list.md

@@ -0,0 +1,21 @@
+---
+description: 列出所有已配置的 hookify 规则
+---
+
+查找并以格式化表格显示所有 hookify 规则。
+
+## 步骤
+
+1. 查找所有 `.claude/hookify.*.local.md` 文件
+2. 读取每个文件的前置元数据：
+   * `name`
+   * `enabled`
+   * `event`
+   * `action`
+   * `pattern`
+3. 以表格形式显示：
+
+| 规则 | 启用状态 | 事件 | 模式 | 文件 |
+|------|---------|-------|---------|------|
+
+4. 显示规则数量，并提醒用户 `/hookify-configure` 后续可更改状态。

docs/zh-CN/commands/hookify.md

@@ -0,0 +1,50 @@
+---
+description: 创建钩子以防止对话分析或明确指令产生的不当行为
+---
+
+创建钩子规则，通过分析对话模式或明确的用户指令，防止 Claude Code 出现不期望的行为。
+
+## 用法
+
+`/hookify [description of behavior to prevent]`
+
+如果不提供参数，则分析当前对话以找出值得阻止的行为。
+
+## 工作流程
+
+### 第一步：收集行为信息
+
+* 带参数：解析用户对不期望行为的描述
+* 不带参数：使用 `conversation-analyzer` 智能体查找：
+  * 明确的纠正
+  * 对重复错误的沮丧反应
+  * 被撤销的更改
+  * 反复出现的类似问题
+
+### 第二步：展示发现
+
+向用户展示：
+
+* 行为描述
+* 建议的事件类型
+* 建议的模式或匹配器
+* 建议的操作
+
+### 第三步：生成规则文件
+
+为每个批准的规则，在 `.claude/hookify.{name}.local.md` 创建文件：
+
+```yaml
+---
+name: rule-name
+enabled: true
+event: bash|file|stop|prompt|all
+action: block|warn
+pattern: "regex pattern"
+---
+Message shown when rule triggers.
+```
+
+### 第四步：确认
+
+报告已创建的规则，以及如何使用 `/hookify-list` 和 `/hookify-configure` 管理这些规则。

docs/zh-CN/commands/jira.md

@@ -0,0 +1,108 @@
+---
+description: 检索Jira工单，分析需求，更新状态或添加评论。使用jira-integration技能和MCP或REST API。
+---
+
+# Jira 命令
+
+直接从工作流中与 Jira 工单交互——获取工单、分析需求、添加评论以及变更状态。
+
+## 用法
+
+```
+/jira get <TICKET-KEY>          # 获取并分析工单
+/jira comment <TICKET-KEY>      # 添加进度评论
+/jira transition <TICKET-KEY>   # 更改工单状态
+/jira search <JQL>              # 使用JQL搜索问题
+```
+
+## 此命令的功能
+
+1. **获取与分析** — 获取 Jira 工单并提取需求、验收标准、测试场景和依赖项
+2. **评论** — 向工单添加结构化的进度更新
+3. **状态变更** — 在工作流状态间移动工单（待办 → 进行中 → 已完成）
+4. **搜索** — 使用 JQL 查询查找问题
+
+## 工作原理
+
+### `/jira get <TICKET-KEY>`
+
+1. 从 Jira 获取工单（通过 MCP `jira_get_issue` 或 REST API）
+2. 提取所有字段：摘要、描述、验收标准、优先级、标签、关联问题
+3. 可选地获取评论以获取更多上下文
+4. 生成结构化分析：
+
+```
+Ticket: PROJ-1234
+Summary: [标题]
+Status: [状态]
+Priority: [优先级]
+Type: [故事/缺陷/任务]
+
+Requirements:
+1. [提取的需求]
+2. [提取的需求]
+
+Acceptance Criteria:
+- [ ] [工单中的验收标准]
+
+Test Scenarios:
+- Happy Path: [描述]
+- Error Case: [描述]
+- Edge Case: [描述]
+
+Dependencies:
+- [关联的问题、API、服务]
+
+Recommended Next Steps:
+- /plan 创建实施计划
+- `tdd-workflow` 技能以测试驱动开发方式实现
+```
+
+### `/jira comment <TICKET-KEY>`
+
+1. 总结当前会话进度（已构建、已测试、已提交的内容）
+2. 格式化为结构化评论
+3. 发布到 Jira 工单
+
+### `/jira transition <TICKET-KEY>`
+
+1. 获取工单的可用状态变更
+2. 向用户显示选项
+3. 执行所选的状态变更
+
+### `/jira search <JQL>`
+
+1. 对 Jira 执行 JQL 查询
+2. 返回匹配问题的摘要表格
+
+## 前提条件
+
+此命令需要 Jira 凭据。请选择以下方式之一：
+
+**选项 A — MCP 服务器（推荐）：**
+将 `jira` 添加到您的 `mcpServers` 配置中（请参阅 `mcp-configs/mcp-servers.json` 获取模板）。
+
+**选项 B — 环境变量：**
+
+```bash
+export JIRA_URL="https://yourorg.atlassian.net"
+export JIRA_EMAIL="your.email@example.com"
+export JIRA_API_TOKEN="your-api-token"
+```
+
+如果缺少凭据，请停止并引导用户进行设置。
+
+## 与其他命令的集成
+
+分析工单后：
+
+* 使用 `/plan` 根据需求创建实施计划
+* 使用 `tdd-workflow` 技能进行测试驱动开发实施
+* 实施后使用 `/code-review`
+* 使用 `/jira comment` 将进度发布回工单
+* 工作完成后使用 `/jira transition` 移动工单
+
+## 相关
+
+* **技能：** `skills/jira-integration/`
+* **MCP 配置：** `mcp-configs/mcp-servers.json` → `jira`

docs/zh-CN/commands/prp-commit.md

@@ -0,0 +1,115 @@
+---
+description: "使用自然语言文件定位快速提交 — 用简单的英语描述要提交的内容"
+argument-hint: "[target description] (blank = all changes)"
+---
+
+# 智能提交
+
+> 改编自 Wirasm 的 PRPs-agentic-eng。属于 PRP 工作流系列。
+
+**输入**：$ARGUMENTS
+
+***
+
+## 阶段 1 — 评估
+
+```bash
+git status --short
+```
+
+如果输出为空 → 停止："没有可提交的内容。"
+
+向用户展示变更摘要（新增、修改、删除、未跟踪）。
+
+***
+
+## 阶段 2 — 解析与暂存
+
+解析 `$ARGUMENTS` 以确定暂存内容：
+
+| 输入 | 解析结果 | Git 命令 |
+|---|---|---|
+| *(空白/空)* | 暂存所有内容 | `git add -A` |
+| `staged` | 使用已暂存的内容 | *(不执行 git add)* |
+| `*.ts` 或 `*.py` 等 | 暂存匹配的 glob 模式 | `git add '*.ts'` |
+| `except tests` | 暂存所有内容，然后取消暂存测试文件 | `git add -A && git reset -- '**/*.test.*' '**/*.spec.*' '**/test_*' 2>/dev/null \|\| true` |
+| `only new files` | 仅暂存未跟踪文件 | `git ls-files --others --exclude-standard \| grep . && git ls-files --others --exclude-standard \| xargs git add` |
+| `the auth changes` | 从状态/差异中解析 — 查找与认证相关的文件 | `git add <matched files>` |
+| 具体文件名 | 暂存这些文件 | `git add <files>` |
+
+对于自然语言输入（如"认证相关的变更"），交叉引用 `git status` 输出和 `git diff` 以识别相关文件。向用户展示你暂存了哪些文件及其原因。
+
+```bash
+git add <determined files>
+```
+
+暂存后，验证：
+
+```bash
+git diff --cached --stat
+```
+
+如果未暂存任何内容，停止："没有文件匹配你的描述。"
+
+***
+
+## 阶段 3 — 提交
+
+使用祈使语气编写单行提交信息：
+
+```
+{type}: {description}
+```
+
+类型：
+
+* `feat` — 新功能或能力
+* `fix` — 错误修复
+* `refactor` — 代码重构，行为不变
+* `docs` — 文档变更
+* `test` — 添加或更新测试
+* `chore` — 构建、配置、依赖项
+* `perf` — 性能改进
+* `ci` — CI/CD 变更
+
+规则：
+
+* 祈使语气（"添加功能"而非"已添加功能"）
+* 类型前缀后使用小写
+* 末尾不加句号
+* 不超过 72 个字符
+* 描述变更内容，而非方式
+
+```bash
+git commit -m "{type}: {description}"
+```
+
+***
+
+## 阶段 4 — 输出
+
+向用户报告：
+
+```
+Committed: {hash_short}
+Message:   {type}: {description}
+Files:     {count} 个文件已更改
+
+下一步：
+  - git push           → 推送到远程
+  - /prp-pr            → 创建拉取请求
+  - /code-review       → 推送前进行代码审查
+```
+
+***
+
+## 示例
+
+| 你说 | 执行结果 |
+|---|---|
+| `/prp-commit` | 暂存所有内容，自动生成信息 |
+| `/prp-commit staged` | 仅提交已暂存的内容 |
+| `/prp-commit *.ts` | 暂存所有 TypeScript 文件，然后提交 |
+| `/prp-commit except tests` | 暂存除测试文件外的所有内容 |
+| `/prp-commit the database migration` | 从状态中查找数据库迁移文件，暂存它们 |
+| `/prp-commit only new files` | 仅暂存未跟踪文件 |

docs/zh-CN/commands/prp-implement.md

@@ -0,0 +1,394 @@
+---
+description: 执行带有严格验证循环的实施计划
+argument-hint: <path/to/plan.md>
+---
+
+> 改编自 Wirasm 的 PRPs-agentic-eng。属于 PRP 工作流系列。
+
+# PRP 实施
+
+按步骤执行计划文件，并进行持续验证。每次更改后立即验证——绝不累积损坏状态。
+
+**核心理念**：验证循环能及早发现错误。每次更改后都运行检查。立即修复问题。
+
+**黄金法则**：如果验证失败，先修复再继续。绝不累积损坏状态。
+
+***
+
+## 阶段 0 — 检测
+
+### 包管理器检测
+
+| 文件存在 | 包管理器 | 运行器 |
+|---|---|---|
+| `bun.lockb` | bun | `bun run` |
+| `pnpm-lock.yaml` | pnpm | `pnpm run` |
+| `yarn.lock` | yarn | `yarn` |
+| `package-lock.json` | npm | `npm run` |
+| `pyproject.toml` 或 `requirements.txt` | uv / pip | `uv run` 或 `python -m` |
+| `Cargo.toml` | cargo | `cargo` |
+| `go.mod` | go | `go` |
+
+### 验证脚本
+
+检查 `package.json`（或等效文件）中可用的脚本：
+
+```bash
+# For Node.js projects
+cat package.json | grep -A 20 '"scripts"'
+```
+
+记录可用的命令：类型检查、代码检查、测试、构建。
+
+***
+
+## 阶段 1 — 加载
+
+读取计划文件：
+
+```bash
+cat "$ARGUMENTS"
+```
+
+从计划中提取以下部分：
+
+* **摘要** — 正在构建什么
+* **要镜像的模式** — 要遵循的代码约定
+* **要更改的文件** — 要创建或修改的内容
+* **逐步任务** — 实施顺序
+* **验证命令** — 如何验证正确性
+* **验收标准** — 完成的定义
+
+如果文件不存在或不是有效的计划：
+
+```
+错误：计划文件未找到或无效。
+请先运行 /prp-plan <功能描述> 来创建计划。
+```
+
+**检查点**：计划已加载。所有部分已识别。任务已提取。
+
+***
+
+## 阶段 2 — 准备
+
+### Git 状态
+
+```bash
+git branch --show-current
+git status --porcelain
+```
+
+### 分支决策
+
+| 当前状态 | 操作 |
+|---|---|
+| 在功能分支上 | 使用当前分支 |
+| 在主分支上，工作区干净 | 创建功能分支：`git checkout -b feat/{plan-name}` |
+| 在主分支上，工作区有未暂存更改 | **停止** — 要求用户先暂存或提交 |
+| 在此功能的 git 工作树中 | 使用该工作树 |
+
+### 同步远程
+
+```bash
+git pull --rebase origin $(git branch --show-current) 2>/dev/null || true
+```
+
+**检查点**：位于正确分支。工作区已就绪。远程已同步。
+
+***
+
+## 阶段 3 — 执行
+
+按顺序处理计划中的每个任务。
+
+### 每个任务的循环
+
+对于**逐步任务**中的每个任务：
+
+1. **读取 MIRROR 参考** — 打开任务 MIRROR 字段中引用的模式文件。在编写代码前理解约定。
+
+2. **实施** — 严格按照模式编写代码。应用 GOTCHA 警告。使用指定的 IMPORTS。
+
+3. **立即验证** — 每次文件更改后：
+   ```bash
+   # 运行类型检查（根据项目调整命令）
+   [阶段 0 中的类型检查命令]
+   ```
+   如果类型检查失败 → 在移动到下一个文件之前修复错误。
+
+4. **跟踪进度** — 记录：`[done] Task N: [task name] — complete`
+
+### 处理偏差
+
+如果实施必须偏离计划：
+
+* 记录**什么**发生了变化
+* 记录**为什么**发生变化
+* 使用修正后的方法继续
+* 这些偏差将在报告中捕获
+
+**检查点**：所有任务已执行。偏差已记录。
+
+***
+
+## 阶段 4 — 验证
+
+运行计划中的所有验证级别。在继续之前修复每个级别的问题。
+
+### 级别 1：静态分析
+
+```bash
+# Type checking — zero errors required
+[project type-check command]
+
+# Linting — fix automatically where possible
+[project lint command]
+[project lint-fix command]
+```
+
+如果自动修复后仍有代码检查错误，请手动修复。
+
+### 级别 2：单元测试
+
+为每个新函数编写测试（如计划中的测试策略所指定）。
+
+```bash
+[project test command for affected area]
+```
+
+* 每个函数至少需要一个测试
+* 覆盖计划中列出的边缘情况
+* 如果测试失败 → 修复实现（而不是测试，除非测试本身有误）
+
+### 级别 3：构建检查
+
+```bash
+[project build command]
+```
+
+构建必须成功，零错误。
+
+### 级别 4：集成测试（如适用）
+
+```bash
+# Start server, run tests, stop server
+[project dev server command] &
+SERVER_PID=$!
+
+# Wait for server to be ready (adjust port as needed)
+SERVER_READY=0
+for i in $(seq 1 30); do
+  if curl -sf http://localhost:PORT/health >/dev/null 2>&1; then
+    SERVER_READY=1
+    break
+  fi
+  sleep 1
+done
+
+if [ "$SERVER_READY" -ne 1 ]; then
+  kill "$SERVER_PID" 2>/dev/null || true
+  echo "ERROR: Server failed to start within 30s" >&2
+  exit 1
+fi
+
+[integration test command]
+TEST_EXIT=$?
+
+kill "$SERVER_PID" 2>/dev/null || true
+wait "$SERVER_PID" 2>/dev/null || true
+
+exit "$TEST_EXIT"
+```
+
+### 级别 5：边缘情况测试
+
+运行计划测试策略清单中的边缘情况。
+
+**检查点**：所有 5 个验证级别均通过。零错误。
+
+***
+
+## 阶段 5 — 报告
+
+### 创建实施报告
+
+```bash
+mkdir -p .claude/PRPs/reports
+```
+
+将报告写入 `.claude/PRPs/reports/{plan-name}-report.md`：
+
+```markdown
+# 实现报告：[功能名称]
+
+## 摘要
+[已实现的内容]
+
+## 评估与实际对比
+
+| 指标 | 预测（计划） | 实际 |
+|---|---|---|
+| 复杂度 | [来自计划] | [实际] |
+| 信心指数 | [来自计划] | [实际] |
+| 变更文件数 | [来自计划] | [实际数量] |
+
+## 已完成任务
+
+| # | 任务 | 状态 | 备注 |
+|---|---|---|---|
+| 1 | [任务名称] | [已完成] 完成 | |
+| 2 | [任务名称] | [已完成] 完成 | 存在偏差 — [原因] |
+
+## 验证结果
+
+| 级别 | 状态 | 备注 |
+|---|---|---|
+| 静态分析 | [已完成] 通过 | |
+| 单元测试 | [已完成] 通过 | 编写了 N 个测试 |
+| 构建 | [已完成] 通过 | |
+| 集成测试 | [已完成] 通过 | 或不适用 |
+| 边界情况 | [已完成] 通过 | |
+
+## 变更文件
+
+| 文件 | 操作 | 行数 |
+|---|---|---|
+| `path/to/file` | 新建 | +N |
+| `path/to/file` | 更新 | +N / -M |
+
+## 与计划的偏差
+[列出所有偏差及其原因，或填写"无"]
+
+## 遇到的问题
+[列出所有问题及解决方案，或填写"无"]
+
+## 编写的测试
+
+| 测试文件 | 测试数量 | 覆盖范围 |
+|---|---|---|
+| `path/to/test` | N 个测试 | [覆盖区域] |
+
+## 后续步骤
+- [ ] 通过 `/code-review` 进行代码审查
+- [ ] 通过 `/prp-pr` 创建拉取请求
+```
+
+### 更新 PRD（如适用）
+
+如果此实施是针对 PRD 阶段的：
+
+1. 将阶段状态从 `in-progress` 更新为 `complete`
+2. 添加报告路径作为参考
+
+### 归档计划
+
+```bash
+mkdir -p .claude/PRPs/plans/completed
+mv "$ARGUMENTS" .claude/PRPs/plans/completed/
+```
+
+**检查点**：报告已创建。PRD 已更新。计划已归档。
+
+***
+
+## 阶段 6 — 输出
+
+向用户报告：
+
+```
+## 实现完成
+
+- **计划**: [计划文件路径] → 已归档至 completed/
+- **分支**: [当前分支名称]
+- **状态**: [完成] 所有任务已完成
+
+### 验证摘要
+
+| 检查项 | 状态 |
+|---|---|
+| 类型检查 | [完成] |
+| 代码检查 | [完成] |
+| 测试 | [完成] (已编写 N 个) |
+| 构建 | [完成] |
+| 集成测试 | [完成] 或 不适用 |
+
+### 文件变更
+- 创建了 [N] 个文件，更新了 [M] 个文件
+
+### 偏差
+[摘要 或 "无 — 完全按计划执行"]
+
+### 产物
+- 报告: `.claude/PRPs/reports/{名称}-report.md`
+- 已归档计划: `.claude/PRPs/plans/completed/{名称}.plan.md`
+
+### PRD 进度（如适用）
+| 阶段 | 状态 |
+|---|---|
+| 阶段 1 | [完成] 已完成 |
+| 阶段 2 | [下一步] |
+| ... | ... |
+
+> 下一步：运行 `/prp-pr` 创建拉取请求，或先运行 `/code-review` 审查更改。
+```
+
+***
+
+## 处理失败
+
+### 类型检查失败
+
+1. 仔细阅读错误信息
+2. 在源文件中修复类型错误
+3. 重新运行类型检查
+4. 仅在干净后继续
+
+### 测试失败
+
+1. 确定错误是在实现中还是在测试中
+2. 修复根本原因（通常是实现）
+3. 重新运行测试
+4. 仅在全部通过后继续
+
+### 代码检查失败
+
+1. 首先运行自动修复
+2. 如果仍有错误，手动修复
+3. 重新运行代码检查
+4. 仅在干净后继续
+
+### 构建失败
+
+1. 通常是类型或导入问题 — 检查错误信息
+2. 修复有问题的文件
+3. 重新运行构建
+4. 仅在成功后继续
+
+### 集成测试失败
+
+1. 检查服务器是否正确启动
+2. 验证端点/路由是否存在
+3. 检查请求格式是否与预期匹配
+4. 修复并重新运行
+
+***
+
+## 成功标准
+
+* **TASKS\_COMPLETE**：计划中的所有任务均已执行
+* **TYPES\_PASS**：零类型错误
+* **LINT\_PASS**：零代码检查错误
+* **TESTS\_PASS**：所有测试通过，已编写新测试
+* **BUILD\_PASS**：构建成功
+* **REPORT\_CREATED**：实施报告已保存
+* **PLAN\_ARCHIVED**：计划已移至 `completed/`
+
+***
+
+## 后续步骤
+
+* 运行 `/code-review` 在提交前审查更改
+* 运行 `/prp-commit` 使用描述性消息提交
+* 运行 `/prp-pr` 创建拉取请求
+* 如果 PRD 有更多阶段，运行 `/prp-plan <next-phase>`

docs/zh-CN/commands/prp-plan.md

@@ -0,0 +1,506 @@
+---
+description: 创建全面的功能实现计划，包括代码库分析和模式提取
+argument-hint: <feature description | path/to/prd.md>
+---
+
+> 改编自 Wirasm 的 PRPs-agentic-eng。属于 PRP 工作流系列。
+
+# PRP 计划
+
+创建一个详细、自包含的实现计划，该计划捕获所有代码库模式、约定和上下文，以便一次性实现一个功能。
+
+**核心理念**：一个优秀的计划包含实现所需的一切，无需再提出其他问题。每个模式、每个约定、每个陷阱——一次性捕获，并在整个过程中引用。
+
+**黄金法则**：如果在实现过程中需要搜索代码库，请立即将该知识捕获到计划中。
+
+***
+
+## 阶段 0 — 检测
+
+根据 `$ARGUMENTS` 确定输入类型：
+
+| 输入模式 | 检测 | 操作 |
+|---|---|---|
+| 以 `.prd.md` 结尾的路径 | PRD 文件路径 | 解析 PRD，查找下一个待处理阶段 |
+| 包含“实施阶段”的 `.md` 路径 | 类似 PRD 的文档 | 解析阶段，查找下一个待处理阶段 |
+| 任何其他文件的路径 | 参考文件 | 读取文件以获取上下文，视为自由格式 |
+| 自由格式文本 | 功能描述 | 直接进入阶段 1 |
+| 空/空白 | 无输入 | 询问用户要规划什么功能 |
+
+### PRD 解析（当输入为 PRD 时）
+
+1. 使用 `cat "$PRD_PATH"` 读取 PRD 文件
+2. 解析 **实施阶段** 部分
+3. 根据状态查找阶段：
+   * 查找 `pending` 阶段
+   * 检查依赖链（一个阶段可能依赖于先前阶段为 `complete`）
+   * 选择 **下一个符合条件的待处理阶段**
+4. 从所选阶段中提取：
+   * 阶段名称和描述
+   * 验收标准
+   * 对先前阶段的依赖
+   * 任何范围说明或约束
+5. 将阶段描述用作要规划的功能
+
+如果没有剩余待处理阶段，则报告所有阶段已完成。
+
+***
+
+## 阶段 1 — 解析
+
+提取并阐明功能需求。
+
+### 功能理解
+
+从输入（PRD 阶段或自由格式描述）中，识别：
+
+* **构建什么**（具体可交付成果）
+* **为什么重要**（用户价值）
+* **谁使用它**（目标用户/系统）
+* **它适合哪里**（代码库的哪个部分）
+
+### 用户故事
+
+格式化为：
+
+```
+作为[用户类型]，
+我希望[能力]，
+以便[收益]。
+```
+
+### 复杂度评估
+
+| 级别 | 指标 | 典型范围 |
+|---|---|---|
+| **小** | 单个文件、隔离更改、无新依赖 | 1-3 个文件，<100 行 |
+| **中** | 多个文件、遵循现有模式、少量新概念 | 3-10 个文件，100-500 行 |
+| **大** | 横切关注点、新模式、外部集成 | 10+ 个文件，500+ 行 |
+| **超大** | 架构更改、新子系统、需要迁移 | 20+ 个文件，考虑拆分 |
+
+### 歧义门控
+
+如果以下任何一项不明确，**停止并向用户提问**，然后再继续：
+
+* 核心可交付成果模糊
+* 成功标准未定义
+* 存在多种有效解释
+* 技术方法存在重大未知数
+
+不要猜测。要提问。基于假设的计划会在实施过程中失败。
+
+***
+
+## 阶段 2 — 探索
+
+收集深入的代码库情报。直接针对以下每个类别搜索代码库。
+
+### 代码库搜索（8 个类别）
+
+对于每个类别，使用 grep、find 和文件读取进行搜索：
+
+1. **类似实现** — 查找与计划功能相似的现有功能。寻找类似的模式、端点、组件或模块。
+
+2. **命名约定** — 识别代码库相关区域中文件、函数、变量、类和导出的命名方式。
+
+3. **错误处理** — 查找在类似代码路径中如何捕获、传播、记录错误并将其返回给用户。
+
+4. **日志记录模式** — 识别记录什么内容、在什么级别以及以什么格式记录。
+
+5. **类型定义** — 查找相关类型、接口、模式及其组织方式。
+
+6. **测试模式** — 查找类似功能的测试方式。注意测试文件位置、命名、设置/拆卸模式以及断言风格。
+
+7. **配置** — 查找相关配置文件、环境变量和功能标志。
+
+8. **依赖项** — 识别类似功能使用的包、导入和内部模块。
+
+### 代码库分析（5 个追踪）
+
+读取相关文件以追踪：
+
+1. **入口点** — 请求/操作如何进入系统并到达您正在修改的区域？
+2. **数据流** — 数据如何在相关代码路径中移动？
+3. **状态更改** — 修改了哪些状态以及在哪里修改？
+4. **契约** — 必须遵守哪些接口、API 或协议？
+5. **模式** — 使用了哪些架构模式（仓库、服务、控制器等）？
+
+### 统一发现表
+
+将发现结果编译到单个参考中：
+
+| 类别 | 文件:行 | 模式 | 关键片段 |
+|---|---|---|---|
+| 命名 | `src/services/userService.ts:1-5` | 服务使用 camelCase，类型使用 PascalCase | `export class UserService` |
+| 错误 | `src/middleware/errorHandler.ts:10-25` | 自定义 AppError 类 | `throw new AppError(...)` |
+| ... | ... | ... | ... |
+
+***
+
+## 阶段 3 — 研究
+
+如果功能涉及外部库、API 或不熟悉的技术：
+
+1. 搜索网络以获取官方文档
+2. 查找使用示例和最佳实践
+3. 识别特定版本的陷阱
+
+将每个发现格式化为：
+
+```
+KEY_INSIGHT: [你学到的内容]
+APPLIES_TO: [这影响计划的哪个部分]
+GOTCHA: [任何警告或版本特定问题]
+```
+
+如果功能仅使用已充分理解的内部模式，则跳过此阶段并注明：“无需外部研究——功能使用已建立的内部模式。”
+
+***
+
+## 阶段 4 — 设计
+
+### 用户体验转换（如果适用）
+
+记录前后用户体验：
+
+**之前：**
+
+```
+┌─────────────────────────────┐
+│  [当前用户体验]              │
+│  展示当前流程，              │
+│  用户所见/所操作的内容        │
+└─────────────────────────────┘
+```
+
+**之后：**
+
+```
+┌─────────────────────────────┐
+│  [新用户体验]               │
+│  展示改进后的流程，          │
+│  用户会看到哪些变化          │
+└─────────────────────────────┘
+```
+
+### 交互更改
+
+| 接触点 | 之前 | 之后 | 备注 |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+如果功能纯粹是后端/内部且没有用户体验更改，则注明：“内部更改——无面向用户的用户体验转换。”
+
+***
+
+## 阶段 5 — 架构
+
+### 策略设计
+
+定义实施方法：
+
+* **方法**：高级策略（例如，“按照现有仓库模式添加新的服务层”）
+* **考虑的替代方案**：评估了哪些其他方法以及为何被拒绝
+* **范围**：将要构建的具体边界
+* **不构建**：明确列出超出范围的内容（防止实施期间范围蔓延）
+
+***
+
+## 阶段 6 — 生成
+
+使用下面的模板编写完整的计划文档。保存到 `.claude/PRPs/plans/{kebab-case-feature-name}.plan.md`。
+
+如果目录不存在，则创建它：
+
+```bash
+mkdir -p .claude/PRPs/plans
+```
+
+### 计划模板
+
+````markdown
+# 计划：[功能名称]
+
+## 摘要
+[2-3句概述]
+
+## 用户故事
+作为[用户]，我希望[能力]，以便[收益]。
+
+## 问题 → 解决方案
+[当前状态] → [期望状态]
+
+## 元数据
+- **复杂度**：[小 | 中 | 大 | 超大]
+- **来源PRD**：[路径或“N/A”]
+- **PRD阶段**：[阶段名称或“N/A”]
+- **预估文件数**：[数量]
+
+---
+
+## UX设计
+
+### 之前
+[ASCII图表或“N/A — 内部变更”]
+
+### 之后
+[ASCII图表或“N/A — 内部变更”]
+
+### 交互变更
+| 接触点 | 之前 | 之后 | 备注 |
+|---|---|---|---|
+
+---
+
+## 必读文件
+
+实现前必须阅读的文件：
+
+| 优先级 | 文件 | 行号 | 原因 |
+|---|---|---|---|
+| P0（关键） | `path/to/file` | 1-50 | 需遵循的核心模式 |
+| P1（重要） | `path/to/file` | 10-30 | 相关类型 |
+| P2（参考） | `path/to/file` | 全部 | 类似实现 |
+
+## 外部文档
+
+| 主题 | 来源 | 关键要点 |
+|---|---|---|
+| ... | ... | ... |
+
+---
+
+## 需镜像的模式
+
+在代码库中发现的代码模式。请严格遵循。
+
+### 命名约定
+// 来源：[文件:行号]
+[展示命名模式的实际代码片段]
+
+### 错误处理
+// 来源：[文件:行号]
+[展示错误处理的实际代码片段]
+
+### 日志记录模式
+// 来源：[文件:行号]
+[展示日志记录的实际代码片段]
+
+### 仓库模式
+// 来源：[文件:行号]
+[展示数据访问的实际代码片段]
+
+### 服务模式
+// 来源：[文件:行号]
+[展示服务层的实际代码片段]
+
+### 测试结构
+// 来源：[文件:行号]
+[展示测试设置的实际代码片段]
+
+---
+
+## 需变更的文件
+
+| 文件 | 操作 | 理由 |
+|---|---|---|
+| `path/to/file.ts` | 创建 | 功能的新服务 |
+| `path/to/existing.ts` | 更新 | 添加新方法 |
+
+## 不构建的内容
+
+- [明确不在范围内的第1项]
+- [明确不在范围内的第2项]
+
+---
+
+## 分步任务
+
+### 任务1：[名称]
+- **操作**：[要做什么]
+- **实现**：[要编写的具体代码/逻辑]
+- **镜像**：[需遵循的“需镜像的模式”部分中的模式]
+- **导入**：[所需的导入]
+- **陷阱**：[需避免的已知陷阱]
+- **验证**：[如何验证此任务正确]
+
+### 任务2：[名称]
+- **操作**：...
+- **实现**：...
+- **镜像**：...
+- **导入**：...
+- **陷阱**：...
+- **验证**：...
+
+[继续所有任务...]
+
+---
+
+## 测试策略
+
+### 单元测试
+
+| 测试 | 输入 | 预期输出 | 边界情况？ |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+### 边界情况检查清单
+- [ ] 空输入
+- [ ] 最大尺寸输入
+- [ ] 无效类型
+- [ ] 并发访问
+- [ ] 网络故障（如适用）
+- [ ] 权限被拒绝
+
+---
+
+## 验证命令
+
+### 静态分析
+```bash
+# Run type checker
+[project-specific type check command]
+```
+预期：零类型错误
+
+### 单元测试
+```bash
+# Run tests for affected area
+[project-specific test command]
+```
+预期：所有测试通过
+
+### 完整测试套件
+```bash
+# Run complete test suite
+[project-specific full test command]
+```
+预期：无回归
+
+### 数据库验证（如适用）
+```bash
+# Verify schema/migrations
+[project-specific db command]
+```
+预期：Schema 为最新
+
+### 浏览器验证（如适用）
+```bash
+# Start dev server and verify
+[project-specific dev server command]
+```
+预期：功能按设计工作
+
+### 手动验证
+- [ ] [逐步手动验证检查清单]
+
+---
+
+## 验收标准
+- [ ] 所有任务完成
+- [ ] 所有验证命令通过
+- [ ] 测试已编写并通过
+- [ ] 无类型错误
+- [ ] 无 lint 错误
+- [ ] 符合 UX 设计（如适用）
+
+## 完成检查清单
+- [ ] 代码遵循发现的模式
+- [ ] 错误处理符合代码库风格
+- [ ] 日志记录遵循代码库约定
+- [ ] 测试遵循测试模式
+- [ ] 无硬编码值
+- [ ] 文档已更新（如需要）
+- [ ] 无不必要的范围扩展
+- [ ] 自包含 — 实现期间无需提问
+
+## 风险
+| 风险 | 可能性 | 影响 | 缓解措施 |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+## 备注
+[任何额外的上下文、决策或观察]
+```
+
+---
+
+## Output
+
+### Save the Plan
+
+Write the generated plan to:
+```
+.claude/PRPs/plans/{kebab-case-feature-name}.plan.md
+```
+
+### Update PRD (if input was a PRD)
+
+If this plan was generated from a PRD phase:
+1. Update the phase status from `pending` to `in-progress`
+2. Add the plan file path as a reference in the phase
+
+### Report to User
+
+```
+## 计划已创建
+
+- **文件**：.claude/PRPs/plans/{kebab-case-feature-name}.plan.md
+- **来源PRD**：[路径或“N/A”]
+- **阶段**：[阶段名称或“独立”]
+- **复杂度**：[级别]
+- **范围**：[N个文件，M个任务]
+- **关键模式**：[前3个发现的模式]
+- **外部研究**：[研究的主题或“无需”]
+- **风险**：[主要风险或“未识别”]
+- **置信度评分**：[1-10] — 单次实现成功的可能性
+
+> 下一步：运行 `/prp-implement .claude/PRPs/plans/{name}.plan.md` 来执行此计划。
+```
+
+---
+
+## 验证
+
+在最终确定之前，请根据以下检查清单验证计划：
+
+### 上下文完整性
+- [ ] 所有相关文件已发现并记录
+- [ ] 命名约定已通过示例捕获
+- [ ] 错误处理模式已记录
+- [ ] 测试模式已识别
+- [ ] 依赖项已列出
+
+### 实现就绪性
+- [ ] 每个任务都有操作、实现、镜像和验证
+- [ ] 没有任务需要额外的代码库搜索
+- [ ] 导入路径已指定
+- [ ] 陷阱已在适用处记录
+
+### 模式忠实度
+- [ ] 代码片段是实际的代码库示例（非虚构）
+- [ ] 来源引用指向真实文件和行号
+- [ ] 模式涵盖命名、错误、日志记录、数据访问和测试
+- [ ] 新代码将与现有代码无法区分
+
+### 验证覆盖范围
+- [ ] 静态分析命令已指定
+- [ ] 测试命令已指定
+- [ ] 构建验证已包含
+
+### UX清晰度
+- [ ] 之前/之后的状态已记录（或标记为N/A）
+- [ ] 交互变更已列出
+- [ ] UX的边界情况已识别
+
+### 无先验知识测试
+不熟悉此代码库的开发人员应能仅使用此计划实现该功能，无需搜索代码库或提问。如果不能，请添加缺失的上下文。
+
+---
+
+## 后续步骤
+
+- 运行 `/prp-implement <plan-path>` 来执行此计划
+- 运行 `/plan` 进行快速对话式规划（无需产物）
+- 如果范围不明确，运行 `/prp-prd` 先创建PRD
+````

docs/zh-CN/commands/prp-pr.md

@@ -0,0 +1,188 @@
+---
+description: "从当前分支创建包含未推送提交的 GitHub PR — 发现模板、分析更改、推送"
+argument-hint: "[base-branch] (default: main)"
+---
+
+# 创建拉取请求
+
+> 改编自 Wirasm 的 PRPs-agentic-eng。属于 PRP 工作流系列的一部分。
+
+**输入**：`$ARGUMENTS` — 可选，可包含基础分支名称和/或标志（例如 `--draft`）。
+
+**解析 `$ARGUMENTS`**：
+
+* 提取所有可识别的标志（`--draft`）
+* 将剩余的非标志文本视为基础分支名称
+* 若未指定，默认基础分支为 `main`
+
+***
+
+## 阶段 1 — 验证
+
+检查前置条件：
+
+```bash
+git branch --show-current
+git status --short
+git log origin/<base>..HEAD --oneline
+```
+
+| 检查项 | 条件 | 失败时的操作 |
+|---|---|---|
+| 不在基础分支上 | 当前分支 ≠ 基础分支 | 停止："请先切换到功能分支。" |
+| 工作目录干净 | 无未提交的更改 | 警告："存在未提交的更改。请先提交或暂存。使用 `/prp-commit` 提交。" |
+| 存在领先提交 | `git log origin/<base>..HEAD` 不为空 | 停止："`<base>` 前无提交。无需创建 PR。" |
+| 无现有 PR | `gh pr list --head <branch> --json number` 为空 | 停止："PR 已存在：#<编号>。使用 `gh pr view <number> --web` 打开。" |
+
+若所有检查通过，继续执行。
+
+***
+
+## 阶段 2 — 发现
+
+### PR 模板
+
+按顺序搜索 PR 模板：
+
+1. `.github/PULL_REQUEST_TEMPLATE/` 目录 — 若存在，列出文件并让用户选择（或使用 `default.md`）
+2. `.github/PULL_REQUEST_TEMPLATE.md`
+3. `.github/pull_request_template.md`
+4. `docs/pull_request_template.md`
+
+若找到，读取并使用其结构作为 PR 正文。
+
+### 提交分析
+
+```bash
+git log origin/<base>..HEAD --format="%h %s" --reverse
+```
+
+分析提交以确定：
+
+* **PR 标题**：使用带类型前缀的常规提交格式 — `feat: ...`、`fix: ...` 等。
+  * 若存在多种类型，使用主导类型
+  * 若为单个提交，直接使用其消息
+* **变更摘要**：按类型/领域对提交进行分组
+
+### 文件分析
+
+```bash
+git diff origin/<base>..HEAD --stat
+git diff origin/<base>..HEAD --name-only
+```
+
+对变更文件进行分类：源代码、测试、文档、配置、迁移。
+
+### PRP 工件
+
+检查相关的 PRP 工件：
+
+* `.claude/PRPs/reports/` — 实现报告
+* `.claude/PRPs/plans/` — 已执行的计划
+* `.claude/PRPs/prds/` — 相关 PRD
+
+若存在，在 PR 正文中引用它们。
+
+***
+
+## 阶段 3 — 推送
+
+```bash
+git push -u origin HEAD
+```
+
+若推送因分歧失败：
+
+```bash
+git fetch origin
+git rebase origin/<base>
+git push -u origin HEAD
+```
+
+若变基发生冲突，停止并通知用户。
+
+***
+
+## 阶段 4 — 创建
+
+### 使用模板
+
+若在阶段 2 中找到 PR 模板，使用提交和文件分析填充每个部分。保留所有模板部分 — 若不适用，将部分留为"不适用"而非删除。
+
+### 无模板
+
+使用以下默认格式：
+
+```markdown
+## 摘要
+
+<用1-2句话描述此PR的功能及原因>
+
+## 变更内容
+
+<bulleted list of changes grouped by area>
+
+## 文件变更
+
+<table or list of changed files with change type: Added/Modified/Deleted>
+
+## 测试说明
+
+<描述变更的测试方式，或填写"需要测试">
+
+## 相关问题
+
+<关联问题，使用Closes/Fixes/Relates to #N格式，或填写"无">
+```
+
+### 创建 PR
+
+```bash
+gh pr create \
+  --title "<PR title>" \
+  --base <base-branch> \
+  --body "<PR body>"
+  # Add --draft if the --draft flag was parsed from $ARGUMENTS
+```
+
+***
+
+## 阶段 5 — 验证
+
+```bash
+gh pr view --json number,url,title,state,baseRefName,headRefName,additions,deletions,changedFiles
+gh pr checks --json name,status,conclusion 2>/dev/null || true
+```
+
+***
+
+## 阶段 6 — 输出
+
+向用户报告：
+
+```
+PR #<number>: <标题>
+URL: <网址>
+分支: <源分支> → <目标分支>
+变更: 共<文件数>个文件，新增<添加行数>行，删除<删除行数>行
+
+CI 检查: <状态摘要 或 "待处理" 或 "未配置">
+
+引用的构建产物:
+  - <PR 正文中链接的任何 PRP 报告/计划>
+
+后续步骤:
+  - gh pr view <编号> --web   → 在浏览器中打开
+  - /code-review <编号>       → 审查该 PR
+  - gh pr merge <编号>        → 准备就绪后合并
+```
+
+***
+
+## 边界情况
+
+* **无 `gh` CLI**：停止并提示："需要 GitHub CLI（`gh`）。安装地址：<https://cli.github.com/>"
+* **未认证**：停止并提示："请先运行 `gh auth login`。"
+* **需要强制推送**：若远程已分歧且已完成变基，使用 `git push --force-with-lease`（切勿使用 `--force`）。
+* **多个 PR 模板**：若 `.github/PULL_REQUEST_TEMPLATE/` 包含多个文件，列出并让用户选择。
+* **大型 PR（超过 20 个文件）**：警告 PR 规模。若变更逻辑上可分离，建议拆分。

docs/zh-CN/commands/prp-prd.md

@@ -0,0 +1,453 @@
+---
+description: "交互式PRD生成器 - 问题优先、假设驱动的产品规格，通过来回提问进行"
+argument-hint: "[feature/product idea] (blank = start with questions)"
+---
+
+# 产品需求文档生成器
+
+> 改编自 Wirasm 的 PRPs-agentic-eng。属于 PRP 工作流系列的一部分。
+
+**输入**：$ARGUMENTS
+
+***
+
+## 你的角色
+
+你是一位敏锐的产品经理，需要做到：
+
+* 从**问题**出发，而非解决方案
+* 在构建之前要求提供证据
+* 以假设而非规格说明来思考
+* 在假设之前先提出澄清性问题
+* 诚实地承认不确定性
+
+**反模式**：不要用空话填充章节。如果信息缺失，请写“待定 - 需要研究”，而不是编造听起来合理的需求。
+
+***
+
+## 流程概览
+
+```
+问题集1 → 基础 → 问题集2 → 研究 → 问题集3 → 生成
+```
+
+每组问题都建立在前一组答案的基础上。验证阶段用于确认假设。
+
+***
+
+## 阶段 1：启动 - 核心问题
+
+**如果未提供输入**，请询问：
+
+> **你想构建什么？**
+> 用几句话描述产品、功能或能力。
+
+**如果提供了输入**，通过复述来确认理解：
+
+> 我理解你想构建：{复述的理解}
+> 这是否正确，或者我是否需要调整理解？
+
+**关卡**：等待用户回复后再继续。
+
+***
+
+## 阶段 2：基础 - 问题发现
+
+提出以下问题（一次性全部呈现，用户可以一起回答）：
+
+> **基础问题：**
+>
+> 1. **谁**有这个问题？要具体——不仅仅是“用户”，而是什么类型的人/角色？
+>
+> 2. 他们面临什么**问题**？描述可观察到的痛点，而不是假设的需求。
+>
+> 3. **为什么**他们今天无法解决？存在哪些替代方案，它们为何失败？
+>
+> 4. **为什么是现在？** 发生了什么变化，使得这件事值得构建？
+>
+> 5. 你如何**知道**你已经解决了问题？成功会是什么样子？
+
+**关卡**：等待用户回复后再继续。
+
+***
+
+## 阶段 3：验证 - 市场与背景研究
+
+在获得基础答案后，进行研究：
+
+**研究市场背景：**
+
+1. 寻找市场上类似的产品/功能
+2. 识别竞争对手如何解决这个问题
+3. 注意常见的模式和反模式
+4. 检查该领域近期的趋势或变化
+
+整理发现，包括直接链接、关键见解以及可用信息中的任何空白。
+
+**如果存在代码库，则并行探索：**
+
+1. 查找与产品/功能想法相关的现有功能
+2. 识别可以借鉴的模式
+3. 注意技术约束或机会
+
+记录观察到的文件位置、代码模式和约定。
+
+**向用户总结发现：**
+
+> **我的发现：**
+>
+> * {市场洞察 1}
+> * {竞争对手的方法}
+> * {代码库中的相关模式（如果适用）}
+>
+> 这是否改变或完善了你的想法？
+
+**关卡**：短暂暂停以等待用户输入（可以是“继续”或调整）。
+
+***
+
+## 阶段 4：深入探讨 - 愿景与用户
+
+基于基础和研究，提出：
+
+> **愿景与用户：**
+>
+> 1. **愿景**：用一句话描述，如果这件事取得巨大成功，理想的最终状态是什么？
+>
+> 2. **主要用户**：描述你最重要的用户——他们的角色、背景以及触发他们需求的因素。
+>
+> 3. **待完成的工作**：完成这句话：“当\[情境]时，我想要\[动机]，以便我能\[结果]。”
+>
+> 4. **非用户**：明确谁不是目标用户？我们应该忽略谁？
+>
+> 5. **约束条件**：存在哪些限制？（时间、预算、技术、法规）
+
+**关卡**：等待用户回复后再继续。
+
+***
+
+## 阶段 5：验证 - 技术可行性
+
+**如果存在代码库，则进行两项并行调查：**
+
+调查 1 — 探索可行性：
+
+1. 识别可以借鉴的现有基础设施
+2. 查找已实现的类似模式
+3. 映射集成点和依赖关系
+4. 定位相关的配置和类型定义
+
+记录观察到的文件位置、代码模式和约定。
+
+调查 2 — 分析约束条件：
+
+1. 追踪现有相关功能的端到端实现方式
+2. 映射通过潜在集成点的数据流
+3. 识别架构模式和边界
+4. 基于类似功能估算复杂度
+
+记录存在的内容，并附上精确的文件:行号引用。不要提建议。
+
+**如果没有代码库，则研究技术方法：**
+
+1. 查找其他人使用过的技术方法
+2. 识别常见的实现模式
+3. 注意已知的技术挑战和陷阱
+
+整理发现，并附上引用和差距分析。
+
+**向用户总结：**
+
+> **技术背景：**
+>
+> * 可行性：{高/中/低}，因为{原因}
+> * 可以借鉴：{现有模式/基础设施}
+> * 关键技术风险：{主要关注点}
+>
+> 我是否应该了解任何技术约束？
+
+**关卡**：短暂暂停以等待用户输入。
+
+***
+
+## 阶段 6：决策 - 范围与方法
+
+提出最终的澄清性问题：
+
+> **范围与方法：**
+>
+> 1. **MVP 定义**：测试此功能是否有效所需的最小功能是什么？
+>
+> 2. **必须拥有 vs 锦上添花**：v1 中必须包含哪 2-3 项？哪些可以等待？
+>
+> 3. **关键假设**：完成这句话：“我们相信\[能力]将为\[用户]\[解决问题]。当\[可衡量的结果]时，我们将知道我们是对的。”
+>
+> 4. **范围之外**：你明确不构建什么（即使用户要求）？
+>
+> 5. **未解决的问题**：哪些不确定性可能会改变方法？
+
+**关卡**：等待用户回复后再生成。
+
+***
+
+## 阶段 7：生成 - 编写 PRD
+
+**输出路径**：`.claude/PRPs/prds/{kebab-case-name}.prd.md`
+
+如果需要，创建目录：`mkdir -p .claude/PRPs/prds`
+
+### PRD 模板
+
+```markdown
+# {产品/功能名称}
+
+## 问题陈述
+
+{2-3句话：谁遇到了什么问题，不解决会带来什么代价？}
+
+## 证据
+
+- {用户原话、数据点或观察结果，证明该问题确实存在}
+- {另一条证据}
+- {若无证据："假设——需通过[方法]进行验证"}
+
+## 拟议解决方案
+
+{一段话：我们要构建什么，以及为什么选择此方案而非其他替代方案}
+
+## 关键假设
+
+我们相信{能力}将为{用户}解决{问题}。
+当{可衡量的结果}出现时，我们就知道方向正确。
+
+## 我们不会构建的内容
+
+- {范围外事项1} - {原因}
+- {范围外事项2} - {原因}
+
+## 成功指标
+
+| 指标 | 目标 | 衡量方式 |
+|------|------|----------|
+| {主要指标} | {具体数值} | {方法} |
+| {次要指标} | {具体数值} | {方法} |
+
+## 待解决问题
+
+- [ ] {未解决的问题1}
+- [ ] {未解决的问题2}
+
+---
+
+## 用户与场景
+
+**主要用户**
+- **身份**：{具体描述}
+- **当前行为**：{他们目前的做法}
+- **触发时机**：{什么时刻触发需求}
+- **成功状态**：{"完成"的具体表现}
+
+**待完成的任务**
+当{情境}时，我想要{动机}，以便实现{结果}。
+
+**非目标用户**
+{本方案不针对哪些用户及原因}
+
+---
+
+## 解决方案详情
+
+### 核心能力（MoSCoW优先级）
+
+| 优先级 | 能力 | 理由 |
+|--------|------|------|
+| 必须有 | {功能} | {为何必不可少} |
+| 必须有 | {功能} | {为何必不可少} |
+| 应该有 | {功能} | {为何重要但不阻塞} |
+| 可以有 | {功能} | {锦上添花} |
+| 不会有 | {功能} | {明确推迟及原因} |
+
+### MVP范围
+
+{验证假设所需的最小功能集}
+
+### 用户流程
+
+{关键路径——到达价值的最短旅程}
+
+---
+
+## 技术方案
+
+**可行性**：{高/中/低}
+
+**架构说明**
+- {关键技术决策及原因}
+- {依赖项或集成点}
+
+**技术风险**
+
+| 风险 | 可能性 | 应对措施 |
+|------|--------|----------|
+| {风险} | {高/中/低} | {如何处理} |
+
+---
+
+## 实施阶段
+
+<!--
+  STATUS: pending | in-progress | complete
+  PARALLEL: phases that can run concurrently (e.g., "with 3" or "-")
+  DEPENDS: phases that must complete first (e.g., "1, 2" or "-")
+  PRP: link to generated plan file once created
+-->
+
+| # | 阶段 | 描述 | 状态 | 并行 | 依赖 | PRP计划 |
+|---|------|------|------|------|------|---------|
+| 1 | {阶段名称} | {本阶段交付内容} | 待定 | - | - | - |
+| 2 | {阶段名称} | {本阶段交付内容} | 待定 | - | 1 | - |
+| 3 | {阶段名称} | {本阶段交付内容} | 待定 | 与4并行 | 2 | - |
+| 4 | {阶段名称} | {本阶段交付内容} | 待定 | 与3并行 | 2 | - |
+| 5 | {阶段名称} | {本阶段交付内容} | 待定 | - | 3, 4 | - |
+
+### 阶段详情
+
+**阶段1：{名称}**
+- **目标**：{我们要达成的目标}
+- **范围**：{明确的交付物}
+- **成功信号**：{如何判断完成}
+
+**阶段2：{名称}**
+- **目标**：{我们要达成的目标}
+- **范围**：{明确的交付物}
+- **成功信号**：{如何判断完成}
+
+{继续为每个阶段填写...}
+
+### 并行说明
+
+{解释哪些阶段可以并行执行及原因}
+
+---
+
+## 决策记录
+
+| 决策 | 选择 | 备选方案 | 理由 |
+|------|------|----------|------|
+| {决策} | {选择} | {考虑过的选项} | {为何选择此项} |
+
+---
+
+## 研究总结
+
+**市场背景**
+{市场研究的关键发现}
+
+**技术背景**
+{技术探索的关键发现}
+
+---
+
+*生成时间：{时间戳}*
+*状态：草稿——需验证*
+```
+
+***
+
+## 阶段 8：输出 - 总结
+
+生成后，报告：
+
+```markdown
+## PRD 已创建
+
+**文件**：`.claude/PRPs/prds/{name}.prd.md`
+
+### 摘要
+
+**问题**：{一行描述}
+**解决方案**：{一行描述}
+**关键指标**：{主要成功指标}
+
+### 验证状态
+
+| 章节 | 状态 |
+|---------|--------|
+| 问题陈述 | {已验证/假设} |
+| 用户研究 | {已完成/需要} |
+| 技术可行性 | {已评估/待定} |
+| 成功指标 | {已定义/需完善} |
+
+### 待解决问题（{数量}）
+
+{列出需要回答的待解决问题}
+
+### 建议的下一步
+
+{用户研究、技术攻关、原型设计、利益相关者评审等之一}
+
+### 实施阶段
+
+| # | 阶段 | 状态 | 可并行 |
+|---|-------|--------|--------------|
+{PRD 中的阶段表格}
+
+### 开始实施
+
+运行：`/prp-plan .claude/PRPs/prds/{name}.prd.md`
+
+这将自动选择下一个待处理阶段并创建实施计划。
+```
+
+***
+
+## 问题流程总结
+
+```
+┌─────────────────────────────────────────────────────────┐
+│  启动："你想构建什么？"                                   │
+└─────────────────────────────────────────────────────────┘
+                          ↓
+┌─────────────────────────────────────────────────────────┐
+│  基础：谁、什么、为什么、为什么现在、如何衡量              │
+└─────────────────────────────────────────────────────────┘
+                          ↓
+┌─────────────────────────────────────────────────────────┐
+│  落地：市场调研、竞品分析                                │
+└─────────────────────────────────────────────────────────┘
+                          ↓
+┌─────────────────────────────────────────────────────────┐
+│  深潜：愿景、主要用户、JTBD、约束条件                    │
+└─────────────────────────────────────────────────────────┘
+                          ↓
+┌─────────────────────────────────────────────────────────┐
+│  落地：技术可行性、代码库探索                            │
+└─────────────────────────────────────────────────────────┘
+                          ↓
+┌─────────────────────────────────────────────────────────┐
+│  决策：MVP、必须功能、假设、范围外                       │
+└─────────────────────────────────────────────────────────┘
+                          ↓
+┌─────────────────────────────────────────────────────────┐
+│  生成：将PRD写入.claude/PRPs/prds/                      │
+└─────────────────────────────────────────────────────────┘
+```
+
+***
+
+## 与 ECC 的集成
+
+在 PRD 生成之后：
+
+* 使用 `/prp-plan` 根据 PRD 阶段创建实施计划
+* 使用 `/plan` 进行无需 PRD 结构的更简单规划
+* 使用 `/save-session` 跨会话保留 PRD 上下文
+
+## 成功标准
+
+* **问题已验证**：问题是具体且有证据的（或标记为假设）
+* **用户已定义**：主要用户是具体的，而非泛泛的
+* **假设清晰**：具有可衡量结果的可测试假设
+* **范围已界定**：明确的必须拥有项和明确的范围外项
+* **问题已确认**：不确定性已列出，而非隐藏
+* **可操作**：怀疑论者也能理解为什么这件事值得构建

docs/zh-CN/commands/review-pr.md

@@ -0,0 +1,37 @@
+---
+description: 使用专门代理进行全面的PR审查
+---
+
+对拉取请求进行全面的多视角审查。
+
+## 用法
+
+`/review-pr [PR-number-or-URL] [--focus=comments|tests|errors|types|code|simplify]`
+
+如果未指定 PR，则审查当前分支的 PR。如果未指定关注点，则运行完整的审查堆栈。
+
+## 步骤
+
+1. 识别 PR：
+   * 使用 `gh pr view` 获取 PR 详情、变更文件及差异
+2. 查找项目指南：
+   * 寻找 `CLAUDE.md`、lint 配置、TypeScript 配置、仓库约定
+3. 运行专项审查代理：
+   * `code-reviewer`
+   * `comment-analyzer`
+   * `pr-test-analyzer`
+   * `silent-failure-hunter`
+   * `type-design-analyzer`
+   * `code-simplifier`
+4. 汇总结果：
+   * 去重重叠发现
+   * 按严重程度排序
+5. 按严重程度分组报告发现
+
+## 置信度规则
+
+仅报告置信度 >= 80 的问题：
+
+* 严重：错误、安全、数据丢失
+* 重要：缺少测试、质量问题、风格违规
+* 建议：仅在明确要求时提供建议

docs/zh-CN/commands/santa-loop.md

@@ -0,0 +1,180 @@
+---
+description: 对抗性双审收敛循环——两个独立模型审查者均需批准后方可发布代码。
+---
+
+# 圣诞老人循环
+
+使用圣诞老人方法技能的对立双审收敛循环。两个独立的评审者——不同模型，无共享上下文——必须都返回 NICE 后代码才能发布。
+
+## 目的
+
+针对当前任务输出，运行两个独立的评审者（Claude Opus + 一个外部模型）。两者都必须返回 NICE 后才能推送代码。如果任一返回 NAUGHTY，则修复所有标记的问题，提交，并重新运行全新的评审者——最多 3 轮。
+
+## 用法
+
+```
+/santa-loop [file-or-glob | description]
+```
+
+## 工作流程
+
+### 步骤 1：确定审查范围
+
+从 `$ARGUMENTS` 确定范围，或回退到未提交的更改：
+
+```bash
+git diff --name-only HEAD
+```
+
+读取所有已更改的文件以构建完整的审查上下文。如果 `$ARGUMENTS` 指定了路径、文件或描述，则改用该范围。
+
+### 步骤 2：构建评分标准
+
+根据被审查的文件类型构建合适的评分标准。每个标准必须有一个客观的 PASS/FAIL 条件。至少包括：
+
+| 标准 | 通过条件 |
+|-----------|---------------|
+| 正确性 | 逻辑正确，无错误，处理边界情况 |
+| 安全性 | 无秘密、注入、XSS 或 OWASP Top 10 问题 |
+| 错误处理 | 显式处理错误，无静默吞没 |
+| 完整性 | 所有需求均已满足，无遗漏情况 |
+| 内部一致性 | 文件或章节之间无矛盾 |
+| 无回归 | 更改不破坏现有行为 |
+
+根据文件类型添加领域特定标准（例如，TypeScript 的类型安全，Rust 的内存安全，SQL 的迁移安全）。
+
+### 步骤 3：双独立审查
+
+使用 Agent 工具**并行**启动两个评审者（两者在单条消息中以便并发执行）。两者都必须完成才能进入裁决门。
+
+每个评审者评估每个评分标准为 PASS 或 FAIL，然后返回结构化 JSON：
+
+```json
+{
+  "verdict": "PASS" | "FAIL",
+  "checks": [
+    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
+  ],
+  "critical_issues": ["..."],
+  "suggestions": ["..."]
+}
+```
+
+裁决门（步骤 4）将这些映射为 NICE/NAUGHTY：两者都 PASS → NICE，任一 FAIL → NAUGHTY。
+
+#### 评审者 A：Claude Agent（始终运行）
+
+启动一个 Agent（subagent\_type: `code-reviewer`，model: `opus`），包含完整的评分标准 + 所有被审查的文件。提示必须包括：
+
+* 完整的评分标准
+* 所有被审查的文件内容
+* "你是一个独立的质量评审者。你没有看到任何其他评审。你的工作是发现问题，而不是批准。"
+* 返回上述结构化 JSON 裁决
+
+#### 评审者 B：外部模型（仅当未安装外部 CLI 时回退到 Claude）
+
+首先，检测哪些 CLI 可用：
+
+```bash
+command -v codex >/dev/null 2>&1 && echo "codex" || true
+command -v gemini >/dev/null 2>&1 && echo "gemini" || true
+```
+
+构建评审者提示（与评审者 A 相同的评分标准和说明）并将其写入唯一的临时文件：
+
+```bash
+PROMPT_FILE=$(mktemp /tmp/santa-reviewer-b-XXXXXX.txt)
+cat > "$PROMPT_FILE" << 'EOF'
+... full rubric + file contents + reviewer instructions ...
+EOF
+```
+
+使用第一个可用的 CLI：
+
+**Codex CLI**（如果已安装）
+
+```bash
+codex exec --sandbox read-only -m gpt-5.4 -C "$(pwd)" - < "$PROMPT_FILE"
+rm -f "$PROMPT_FILE"
+```
+
+**Gemini CLI**（如果已安装且 codex 未安装）
+
+```bash
+gemini -p "$(cat "$PROMPT_FILE")" -m gemini-2.5-pro
+rm -f "$PROMPT_FILE"
+```
+
+**Claude Agent 回退**（仅当 `codex` 和 `gemini` 均未安装时）
+启动第二个 Claude Agent（subagent\_type: `code-reviewer`，model: `opus`）。记录一条警告，说明两个评审者共享相同的模型家族——未实现真正的模型多样性，但上下文隔离仍然得到强制执行。
+
+在所有情况下，评审者必须返回与评审者 A 相同的结构化 JSON 裁决。
+
+### 步骤 4：裁决门
+
+* **两者都 PASS** → **NICE** — 继续执行步骤 6（推送）
+* **任一 FAIL** → **NAUGHTY** — 合并两个评审者的所有关键问题，去重，继续执行步骤 5
+
+### 步骤 5：修复循环（NAUGHTY 路径）
+
+1. 显示两个评审者的所有关键问题
+2. 修复每个标记的问题——仅更改被标记的内容，不进行附带重构
+3. 将所有修复提交到单个提交中：
+   ```
+   fix: 解决圣诞老人循环审查发现的问题（第 N 轮）
+   ```
+4. 使用**全新的评审者**（无先前轮次的记忆）重新运行步骤 3
+5. 重复直到两者都返回 PASS
+
+**最多 3 次迭代。** 如果 3 轮后仍为 NAUGHTY，则停止并呈现剩余问题：
+
+```
+圣诞循环升级（超过3次迭代）
+
+3轮后仍存在的问题：
+- [列出两位评审员所有未解决的关键问题]
+
+继续前需进行人工审核。
+```
+
+不要推送。
+
+### 步骤 6：推送（NICE 路径）
+
+当两个评审者都返回 PASS 时：
+
+```bash
+git push -u origin HEAD
+```
+
+### 步骤 7：最终报告
+
+打印输出报告（参见下面的输出部分）。
+
+## 输出
+
+```
+SANTA VERDICT: [NICE / NAUGHTY (escalated)]
+
+Reviewer A (Claude Opus):   [PASS/FAIL]
+Reviewer B ([model used]):  [PASS/FAIL]
+
+Agreement:
+  Both flagged:      [issues caught by both]
+  Reviewer A only:   [issues only A caught]
+  Reviewer B only:   [issues only B caught]
+
+Iterations: [N]/3
+Result:     [PUSHED / ESCALATED TO USER]
+```
+
+## 备注
+
+* 评审者 A（Claude Opus）始终运行——无论工具如何，保证至少有一个强大的评审者。
+* 模型多样性是评审者 B 的目标。GPT-5.4 或 Gemini 2.5 Pro 提供真正的独立性——不同的训练数据、不同的偏见、不同的盲点。仅 Claude 的回退通过上下文隔离仍然提供价值，但失去了模型多样性。
+* 使用最强可用模型：Opus 用于评审者 A，GPT-5.4 或 Gemini 2.5 Pro 用于评审者 B。
+* 外部评审者使用 `--sandbox read-only`（Codex）运行，以防止审查期间仓库发生变异。
+* 每轮使用全新的评审者可以防止先前发现导致的锚定偏差。
+* 评分标准是最重要的输入。如果评审者盖章通过或标记主观风格问题，请收紧评分标准。
+* 在 NAUGHTY 轮次进行提交，以便即使循环被中断，修复也能被保留。
+* 仅在 NICE 后推送——绝不在循环中间推送。

docs/zh-CN/skills/accessibility/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: accessibility
+description: 使用 WCAG 2.2 Level AA 标准设计、实施和审计包容性数字产品。运用此技能为 Web 生成语义 ARIA，并为 Web 和原生平台（iOS/Android）生成无障碍特性。
+origin: ECC
+---
+
+# 无障碍性（WCAG 2.2）
+
+本技能确保数字界面对于所有用户（包括使用屏幕阅读器、开关控制或键盘导航的用户）具有可感知性、可操作性、可理解性和健壮性（POUR）。它专注于 WCAG 2.2 成功标准的技术实现。
+
+## 使用时机
+
+* 定义 Web、iOS 或 Android 的 UI 组件规范。
+* 审计现有代码中的无障碍性障碍或合规性差距。
+* 实现新的 WCAG 2.2 标准，如目标尺寸（最小）和焦点外观。
+* 将高层设计需求映射到技术属性（ARIA 角色、特性、提示）。
+
+## 核心概念
+
+* **POUR 原则**：WCAG 的基础（可感知、可操作、可理解、健壮）。
+* **语义映射**：使用原生元素而非通用容器，以提供内置的无障碍性。
+* **无障碍树**：辅助技术实际“读取”的 UI 表示。
+* **焦点管理**：控制键盘/屏幕阅读器光标的顺序和可见性。
+* **标签与提示**：通过 `aria-label`、`accessibilityLabel` 和 `contentDescription` 提供上下文。
+
+## 工作原理
+
+### 步骤 1：识别组件角色
+
+确定功能目的（例如，这是按钮、链接还是标签页？）。在诉诸自定义角色之前，优先使用最语义化的原生元素。
+
+### 步骤 2：定义可感知属性
+
+* 确保文本对比度达到 **4.5:1**（正常文本）或 **3:1**（大文本/UI 组件）。
+* 为非文本内容（图像、图标）添加文本替代方案。
+* 实现响应式重排（放大至 400% 时功能不丢失）。
+
+### 步骤 3：实现可操作控件
+
+* 确保最小 **24x24 CSS 像素** 的目标尺寸（WCAG 2.2 SC 2.5.8）。
+* 验证所有交互元素可通过键盘访问，并具有可见的焦点指示器（SC 2.4.11）。
+* 为拖拽操作提供单指针替代方案。
+
+### 步骤 4：确保可理解逻辑
+
+* 使用一致的导航模式。
+* 提供描述性错误消息和更正建议（SC 3.3.3）。
+* 实现“冗余输入”（SC 3.3.7），避免重复询问相同数据。
+
+### 步骤 5：验证健壮兼容性
+
+* 使用正确的 `Name, Role, Value` 模式。
+* 为动态状态更新实现 `aria-live` 或活动区域。
+
+## 无障碍架构图
+
+```mermaid
+flowchart TD
+  UI["UI Component"] --> Platform{Platform?}
+  Platform -->|Web| ARIA["WAI-ARIA + HTML5"]
+  Platform -->|iOS| SwiftUI["Accessibility Traits + Labels"]
+  Platform -->|Android| Compose["Semantics + ContentDesc"]
+
+  ARIA --> AT["Assistive Technology (Screen Readers, Switches)"]
+  SwiftUI --> AT
+  Compose --> AT
+```
+
+## 跨平台映射
+
+| 特性             | Web (HTML/ARIA)          | iOS (SwiftUI)                        | Android (Compose)                                           |
+| :--------------- | :----------------------- | :----------------------------------- | :---------------------------------------------------------- |
+| **主标签**       | `aria-label` / `<label>` | `.accessibilityLabel()`              | `contentDescription`                                        |
+| **辅助提示**     | `aria-describedby`       | `.accessibilityHint()`               | `Modifier.semantics { stateDescription = ... }`             |
+| **操作角色**     | `role="button"`          | `.accessibilityAddTraits(.isButton)` | `Modifier.semantics { role = Role.Button }`                 |
+| **实时更新**     | `aria-live="polite"`     | `.accessibilityLiveRegion(.polite)`  | `Modifier.semantics { liveRegion = LiveRegionMode.Polite }` |
+
+## 示例
+
+### Web：无障碍搜索
+
+```html
+<form role="search">
+  <label for="search-input" class="sr-only">Search products</label>
+  <input type="search" id="search-input" placeholder="Search..." />
+  <button type="submit" aria-label="Submit Search">
+    <svg aria-hidden="true">...</svg>
+  </button>
+</form>
+```
+
+### iOS：无障碍操作按钮
+
+```swift
+Button(action: deleteItem) {
+    Image(systemName: "trash")
+}
+.accessibilityLabel("Delete item")
+.accessibilityHint("Permanently removes this item from your list")
+.accessibilityAddTraits(.isButton)
+```
+
+### Android：无障碍切换开关
+
+```kotlin
+Switch(
+    checked = isEnabled,
+    onCheckedChange = { onToggle() },
+    modifier = Modifier.semantics {
+        contentDescription = "Enable notifications"
+    }
+)
+```
+
+## 应避免的反模式
+
+* **Div 按钮**：使用 `<div>` 或 `<span>` 处理点击事件，但未添加角色和键盘支持。
+* **仅用颜色传达含义**：仅通过颜色变化（例如，将边框变为红色）来指示错误或状态。
+* **未限制的模态焦点**：模态框未限制焦点，导致键盘用户在模态框打开时仍可导航背景内容。焦点必须被限制，并且可通过 `Escape` 键或显式关闭按钮退出（WCAG SC 2.1.2）。
+* **冗余替代文本**：在替代文本中使用“图像...”或“图片...”（屏幕阅读器已宣布“图像”角色）。
+
+## 最佳实践检查清单
+
+* \[ ] 交互元素满足 **24x24px**（Web）或 **44x44pt**（原生）的目标尺寸。
+* \[ ] 焦点指示器清晰可见且高对比度。
+* \[ ] 模态框在打开时**限制焦点**，并在关闭时干净地释放焦点（`Escape` 键或关闭按钮）。
+* \[ ] 下拉菜单和菜单在关闭时将焦点恢复到触发元素。
+* \[ ] 表单提供基于文本的错误建议。
+* \[ ] 所有仅图标按钮都有描述性文本标签。
+* \[ ] 文本缩放时内容正确重排。
+
+## 参考
+
+* [WCAG 2.2 指南](https://www.w3.org/TR/WCAG22/)
+* [WAI-ARIA 创作实践](https://www.w3.org/TR/wai-aria-practices/)
+* [iOS 无障碍编程指南](https://developer.apple.com/documentation/accessibility)
+* [iOS 人机界面指南 - 无障碍](https://developer.apple.com/design/human-interface-guidelines/accessibility)
+* [Android 无障碍开发者指南](https://developer.android.com/guide/topics/ui/accessibility)
+
+## 相关技能
+
+* `frontend-patterns`
+* `design-system`
+* `liquid-glass-design`
+* `swiftui-patterns`

docs/zh-CN/skills/agent-introspection-debugging/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: agent-introspection-debugging
+description: 针对AI代理故障的结构化自调试工作流程，包括捕获、诊断、受限恢复和内省报告。
+origin: ECC
+---
+
+# 智能体内省调试
+
+当智能体运行反复失败、消耗令牌却无进展、在相同工具上循环或偏离预期任务时，使用此技能。
+
+这是一个工作流技能，而非隐藏运行时。它教会智能体在升级给人类之前，系统性地自我调试。
+
+## 何时激活
+
+* 达到最大工具调用/循环限制失败
+* 重复重试但无任何进展
+* 上下文增长或提示漂移导致输出质量下降
+* 文件系统或环境状态与预期不匹配
+* 可通过诊断和较小纠正措施恢复的工具故障
+
+## 范围边界
+
+激活此技能用于：
+
+* 在盲目重试前捕获失败状态
+* 诊断常见的智能体特定失败模式
+* 应用受限的恢复操作
+* 生成结构化的人类可读调试报告
+
+请勿将此技能作为以下情况的主要来源：
+
+* 代码变更后的功能验证；请使用 `verification-loop`
+* 当已有更窄的 ECC 技能时的框架特定调试
+* 当前框架无法自动强制执行的运行时承诺
+
+## 四阶段循环
+
+### 阶段 1：失败捕获
+
+在尝试恢复之前，精确记录失败信息。
+
+捕获内容：
+
+* 错误类型、消息和堆栈跟踪（如可用）
+* 最后有意义的工具调用序列
+* 智能体当时试图完成的任务
+* 当前上下文压力：重复提示、过大的粘贴日志、重复的计划或失控的笔记
+* 当前环境假设：工作目录、分支、相关服务状态、预期文件
+
+最小捕获模板：
+
+```markdown
+## 失败捕获
+- 会话/任务：
+- 进行中的目标：
+- 错误：
+- 最后成功的步骤：
+- 最后失败的工具/命令：
+- 观察到的重复模式：
+- 需验证的环境假设：
+```
+
+### 阶段 2：根因诊断
+
+在更改任何内容之前，将失败与已知模式匹配。
+
+| 模式 | 可能原因 | 检查 |
+| --- | --- | --- |
+| 最大工具调用/重复相同命令 | 循环或无退出观察路径 | 检查最后 N 次工具调用是否存在重复 |
+| 上下文溢出/推理能力下降 | 无界笔记、重复计划、过大日志 | 检查近期上下文是否存在重复和低信号批量内容 |
+| `ECONNREFUSED` / 超时 | 服务不可用或端口错误 | 验证服务健康状态、URL 和端口假设 |
+| `429` / 配额耗尽 | 重试风暴或缺少退避 | 统计重复调用次数并检查重试间隔 |
+| 写入后文件缺失/差异过时 | 竞态、工作目录错误或分支漂移 | 重新检查路径、工作目录、git 状态和实际文件是否存在 |
+| “修复”后测试仍然失败 | 假设错误 | 隔离确切失败的测试并重新推导错误 |
+
+诊断问题：
+
+* 这是逻辑失败、状态失败、环境失败还是策略失败？
+* 智能体是否丢失了真实目标并开始优化错误的子任务？
+* 失败是确定性的还是瞬态的？
+* 能够验证诊断的最小可逆操作是什么？
+
+### 阶段 3：受限恢复
+
+使用改变诊断面的最小操作进行恢复。
+
+安全恢复操作：
+
+* 停止重复重试并重新陈述假设
+* 修剪低信号上下文，仅保留活跃目标、阻碍因素和证据
+* 重新检查实际文件系统/分支/进程状态
+* 将任务缩小到一个失败的命令、一个文件或一个测试
+* 从推测性推理切换到直接观察
+* 当失败风险高或受外部阻碍时升级给人类
+
+不要声称不支持的自动修复操作，如“重置智能体状态”或“更新框架配置”，除非你正在当前环境中通过真实工具实际执行这些操作。
+
+受限恢复检查清单：
+
+```markdown
+## 恢复操作
+- 选择的诊断方式：
+- 采取的最小操作：
+- 为何此操作安全：
+- 哪些证据能证明修复生效：
+```
+
+### 阶段 4：内省报告
+
+以一份使恢复过程对下一个智能体或人类清晰可读的报告结束。
+
+```markdown
+## 代理自调试报告
+- 会话/任务：
+- 失败原因：
+- 根本原因：
+- 恢复措施：
+- 结果：成功 | 部分成功 | 受阻
+- Token/时间消耗风险：
+- 是否需要后续跟进：
+- 后续需编码的预防性变更：
+```
+
+## 恢复启发式方法
+
+按顺序优先选择以下干预措施：
+
+1. 用一句话重新陈述真实目标。
+2. 验证世界状态，而非依赖记忆。
+3. 缩小失败范围。
+4. 运行一次判别性检查。
+5. 然后才重试。
+
+错误模式：
+
+* 用略微不同的措辞重复相同操作三次
+
+正确模式：
+
+* 捕获失败
+* 分类模式
+* 运行一次直接检查
+* 仅当检查支持时才更改计划
+
+## 与 ECC 集成
+
+* 如果代码已更改，在恢复后使用 `verification-loop`。
+* 当失败模式值得转化为本能或后续技能时，使用 `continuous-learning-v2`。
+* 当问题不是技术失败而是决策模糊时，使用 `council`。
+* 如果失败源于冲突的本地状态或仓库漂移，使用 `workspace-surface-audit`。
+
+## 输出标准
+
+当此技能激活时，不要仅以“我已修复”结束。
+
+始终提供：
+
+* 失败模式
+* 根因假设
+* 恢复操作
+* 证明情况已改善或仍受阻的证据

docs/zh-CN/skills/agent-payment-x402/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: agent-payment-x402
+description: 将 x402 支付执行添加到 AI 代理中——通过 MCP 工具实现每任务预算、支出控制和非托管钱包。当代理需要为 API、服务或其他代理付费时使用。
+origin: community
+---
+
+# 代理支付执行 (x402)
+
+让AI代理能够自主支付并内置消费控制。使用x402 HTTP支付协议和MCP工具，使代理能够为外部服务、API或其他代理支付，无需托管风险。
+
+## 使用场景
+
+适用于：代理需要支付API调用、购买服务、与其他代理结算、强制执行每项任务消费限额，或管理非托管钱包。与成本感知LLM流水线和安全审查技能自然搭配。
+
+## 工作原理
+
+### x402协议
+
+x402将HTTP 402（需要付款）扩展为机器可协商的流程。当服务器返回`402`时，代理的支付工具会自动协商价格、检查预算、签署交易并重试——无需人工干预。
+
+### 消费控制
+
+每次支付工具调用都会强制执行`SpendingPolicy`：
+
+* **每任务预算** — 单次代理操作的最大支出
+* **每会话预算** — 整个会话的累计限额
+* **白名单接收方** — 限制代理可支付的地址/服务
+* **速率限制** — 每分钟/小时的最大交易数
+
+### 非托管钱包
+
+代理通过ERC-4337智能账户持有自己的密钥。编排器在委托前设置策略；代理只能在限定范围内支出。无资金池，无托管风险。
+
+## MCP集成
+
+支付层暴露标准MCP工具，可无缝接入任何Claude Code或代理框架设置。
+
+> **安全提示**：务必锁定包版本。此工具管理私钥——未锁定的`npx`安装会引入供应链风险。
+
+```json
+{
+  "mcpServers": {
+    "agentpay": {
+      "command": "npx",
+      "args": ["agentwallet-sdk@6.0.0"]
+    }
+  }
+}
+```
+
+### 可用工具（代理可调用）
+
+| 工具 | 用途 |
+|------|---------|
+| `get_balance` | 检查代理钱包余额 |
+| `send_payment` | 向地址或ENS发送付款 |
+| `check_spending` | 查询剩余预算 |
+| `list_transactions` | 所有付款的审计追踪 |
+
+> **注意**：消费策略由**编排器**在委托给代理之前设置——而非代理本身。这防止代理自行提高消费限额。通过编排层或任务前钩子中的`set_policy`配置策略，切勿将其作为代理可调用工具。
+
+## 示例
+
+### MCP客户端中的预算执行
+
+在构建调用agentpay MCP服务器的编排器时，在分派付费工具调用前强制执行预算。
+
+> **前提条件**：在添加MCP配置前安装包——`npx`不带`-y`会在非交互环境中提示确认，导致服务器挂起：`npm install -g agentwallet-sdk@6.0.0`
+
+```typescript
+import { Client } from "@modelcontextprotocol/sdk/client/index.js";
+import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
+
+async function main() {
+  // 1. Validate credentials before constructing the transport.
+  //    A missing key must fail immediately — never let the subprocess start without auth.
+  const walletKey = process.env.WALLET_PRIVATE_KEY;
+  if (!walletKey) {
+    throw new Error("WALLET_PRIVATE_KEY is not set — refusing to start payment server");
+  }
+
+  // Connect to the agentpay MCP server via stdio transport.
+  // Whitelist only the env vars the server needs — never forward all of process.env
+  // to a third-party subprocess that manages private keys.
+  const transport = new StdioClientTransport({
+    command: "npx",
+    args: ["agentwallet-sdk@6.0.0"],
+    env: {
+      PATH: process.env.PATH ?? "",
+      NODE_ENV: process.env.NODE_ENV ?? "production",
+      WALLET_PRIVATE_KEY: walletKey,
+    },
+  });
+  const agentpay = new Client({ name: "orchestrator", version: "1.0.0" });
+  await agentpay.connect(transport);
+
+  // 2. Set spending policy before delegating to the agent.
+  //    Always verify success — a silent failure means no controls are active.
+  const policyResult = await agentpay.callTool({
+    name: "set_policy",
+    arguments: {
+      per_task_budget: 0.50,
+      per_session_budget: 5.00,
+      allowlisted_recipients: ["api.example.com"],
+    },
+  });
+  if (policyResult.isError) {
+    throw new Error(
+      `Failed to set spending policy — do not delegate: ${JSON.stringify(policyResult.content)}`
+    );
+  }
+
+  // 3. Use preToolCheck before any paid action
+  await preToolCheck(agentpay, 0.01);
+}
+
+// Pre-tool hook: fail-closed budget enforcement with four distinct error paths.
+async function preToolCheck(agentpay: Client, apiCost: number): Promise<void> {
+  // Path 1: Reject invalid input (NaN/Infinity bypass the < comparison)
+  if (!Number.isFinite(apiCost) || apiCost < 0) {
+    throw new Error(`Invalid apiCost: ${apiCost} — action blocked`);
+  }
+
+  // Path 2: Transport/connectivity failure
+  let result;
+  try {
+    result = await agentpay.callTool({ name: "check_spending" });
+  } catch (err) {
+    throw new Error(`Payment service unreachable — action blocked: ${err}`);
+  }
+
+  // Path 3: Tool returned an error (e.g., auth failure, wallet not initialised)
+  if (result.isError) {
+    throw new Error(
+      `check_spending failed — action blocked: ${JSON.stringify(result.content)}`
+    );
+  }
+
+  // Path 4: Parse and validate the response shape
+  let remaining: number;
+  try {
+    const parsed = JSON.parse(
+      (result.content as Array<{ text: string }>)[0].text
+    );
+    if (!Number.isFinite(parsed?.remaining)) {
+      throw new TypeError("missing or non-finite 'remaining' field");
+    }
+    remaining = parsed.remaining;
+  } catch (err) {
+    throw new Error(
+      `check_spending returned unexpected format — action blocked: ${err}`
+    );
+  }
+
+  // Path 5: Budget exceeded
+  if (remaining < apiCost) {
+    throw new Error(
+      `Budget exceeded: need $${apiCost} but only $${remaining} remaining`
+    );
+  }
+}
+
+main().catch((err) => {
+  console.error(err);
+  process.exitCode = 1;
+});
+```
+
+## 最佳实践
+
+* **委托前设置预算**：生成子代理时，通过编排层附加SpendingPolicy。切勿让代理拥有无限支出权限。
+* **锁定依赖项**：始终在MCP配置中指定确切版本（例如`agentwallet-sdk@6.0.0`）。部署到生产环境前验证包完整性。
+* **审计追踪**：在任务后钩子中使用`list_transactions`记录支出内容和原因。
+* **故障关闭**：如果支付工具不可达，阻止付费操作——不要回退到无计量访问。
+* **配合安全审查**：支付工具是高权限操作。应用与shell访问相同的审查标准。
+* **先在测试网测试**：开发时使用Base Sepolia；生产环境切换到Base主网。
+
+## 生产参考
+
+* **npm**：[`agentwallet-sdk`](https://www.npmjs.com/package/agentwallet-sdk)
+* **合并到NVIDIA NeMo Agent Toolkit**：[PR #17](https://github.com/NVIDIA/NeMo-Agent-Toolkit-Examples/pull/17) — NVIDIA代理示例的x402支付工具
+* **协议规范**：[x402.org](https://x402.org)

docs/zh-CN/skills/agent-sort/SKILL.md

@@ -0,0 +1,215 @@
+---
+name: agent-sort
+description: 通过将技能、命令、规则、钩子和额外内容并行进行仓库感知审查，为特定仓库构建基于证据的 ECC 安装计划，将其分为 DAILY 和 LIBRARY 两类。当 ECC 应精简为项目实际所需而非加载完整包时使用。
+origin: ECC
+---
+
+# 技能分类
+
+当仓库需要项目特定的 ECC 表面而非默认完整安装时，使用此技能。
+
+目标不是猜测"什么感觉有用"。目标是根据实际代码库中的证据对 ECC 组件进行分类。
+
+## 何时使用
+
+* 项目只需要 ECC 的子集，完整安装过于嘈杂
+* 仓库技术栈明确，但无人希望逐个手动筛选技能
+* 团队希望获得基于 grep 证据而非主观意见的可重复安装决策
+* 需要将始终加载的日常工作流表面与可搜索的库/参考表面分离
+* 仓库已偏离至错误的语言、规则或钩子集，需要清理
+
+## 不可协商的规则
+
+* 以当前仓库为事实来源，而非通用偏好
+* 每个 DAILY 决策必须引用具体的仓库证据
+* LIBRARY 并不意味着"删除"；它意味着"保持可访问但不默认加载"
+* 不要安装当前仓库无法使用的钩子、规则或脚本
+* 优先使用 ECC 原生表面；不要引入第二个安装系统
+
+## 输出
+
+按顺序生成以下工件：
+
+1. DAILY 清单
+2. LIBRARY 清单
+3. 安装计划
+4. 验证报告
+5. 可选的路由器（如果项目需要）
+
+## 分类模型
+
+仅使用两个分类：
+
+* `DAILY`
+  * 应为该仓库的每个会话加载
+  * 与仓库的语言、框架、工作流或操作者表面强匹配
+* `LIBRARY`
+  * 保留有用，但不值得默认加载
+  * 应通过搜索、路由器技能或选择性手动使用保持可访问
+
+## 证据来源
+
+在进行任何分类之前，使用仓库本地证据：
+
+* 文件扩展名
+* 包管理器和锁文件
+* 框架配置
+* CI 和钩子配置
+* 构建/测试脚本
+* 导入和依赖清单
+* 明确描述技术栈的仓库文档
+
+有用的命令包括：
+
+```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
+```
+
+## 并行审查轮次
+
+如果并行子代理可用，将审查分为以下轮次：
+
+1. 代理
+   * 分类 `agents/*`
+2. 技能
+   * 分类 `skills/*`
+3. 命令
+   * 分类 `commands/*`
+4. 规则
+   * 分类 `rules/*`
+5. 钩子和脚本
+   * 分类钩子表面、MCP 健康检查、辅助脚本和操作系统兼容性
+6. 额外项
+   * 分类上下文、示例、MCP 配置、模板和指导文档
+
+如果子代理不可用，则按顺序运行相同的轮次。
+
+## 核心工作流
+
+### 1. 读取仓库
+
+在分类任何内容之前，确定实际技术栈：
+
+* 使用的语言
+* 使用的框架
+* 主要包管理器
+* 测试技术栈
+* 代码检查/格式化技术栈
+* 部署/运行时表面
+* 已存在的操作者集成
+
+### 2. 构建证据表
+
+对于每个候选表面，记录：
+
+* 组件路径
+* 组件类型
+* 建议的分类
+* 仓库证据
+* 简短理由
+
+使用此格式：
+
+```text
+skills/frontend-patterns | skill | DAILY | 84 个 .tsx 文件，存在 next.config.ts | 核心前端技术栈
+skills/django-patterns   | skill | LIBRARY | 无 .py 文件，无 pyproject.toml       | 此仓库中未激活
+rules/typescript/*       | rules | DAILY | 存在 package.json + tsconfig.json            | 活跃的 TS 仓库
+rules/python/*           | rules | LIBRARY | 零个 Python 源文件             | 仅保持可访问
+```
+
+### 3. 决定 DAILY 还是 LIBRARY
+
+提升至 `DAILY` 当：
+
+* 仓库明确使用匹配的技术栈
+* 组件足够通用，有助于每个会话
+* 仓库已依赖相应的运行时或工作流
+
+降级至 `LIBRARY` 当：
+
+* 组件与技术栈不匹配
+* 仓库可能以后需要，但不是每天
+* 它增加了上下文开销而无直接相关性
+
+### 4. 构建安装计划
+
+将分类转化为行动：
+
+* DAILY 技能 -> 安装或保留在 `.claude/skills/`
+* DAILY 命令 -> 仅当仍然有用时保留为显式 shim
+* DAILY 规则 -> 仅安装匹配的语言集
+* DAILY 钩子/脚本 -> 仅保留兼容的
+* LIBRARY 表面 -> 通过搜索或 `skill-library` 保持可访问
+
+如果仓库已使用选择性安装，则更新该计划而非创建另一个系统。
+
+### 5. 创建可选的路由器
+
+如果项目需要可搜索的库表面，创建：
+
+* `.claude/skills/skill-library/SKILL.md`
+
+该路由器应包含：
+
+* DAILY 与 LIBRARY 的简短说明
+* 分组的触发关键词
+* 库参考的存放位置
+
+不要在路由器内重复每个技能的主体。
+
+### 6. 验证结果
+
+应用计划后，验证：
+
+* 每个 DAILY 文件存在于预期位置
+* 未保留过时的语言规则
+* 未安装不兼容的钩子
+* 最终安装确实匹配仓库技术栈
+
+返回一个简洁的报告，包含：
+
+* DAILY 数量
+* LIBRARY 数量
+* 移除的过时表面
+* 未解决的问题
+
+## 交接
+
+如果下一步是交互式安装或修复，交接至：
+
+* `configure-ecc`
+
+如果下一步是重叠清理或目录审查，交接至：
+
+* `skill-stocktake`
+
+如果下一步是更广泛的上下文修剪，交接至：
+
+* `strategic-compact`
+
+## 输出格式
+
+按此顺序返回结果：
+
+```text
+栈
+- 语言/框架/运行时摘要
+
+日常
+- 始终加载的条目及证据
+
+库
+- 可搜索/参考的条目及证据
+
+安装计划
+- 应安装、移除或路由的内容
+
+验证
+- 已运行的检查及剩余差距
+```

docs/zh-CN/skills/api-connector-builder/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: api-connector-builder
+description: 通过匹配目标仓库现有的集成模式，构建一个新的API连接器或提供者。适用于在不发明第二种架构的情况下添加一个集成。
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# API 连接器构建器
+
+当任务需要添加仓库原生的集成接口，而非仅通用 HTTP 客户端时使用此工具。
+
+关键在于匹配宿主仓库的模式：
+
+* 连接器布局
+* 配置模式
+* 认证模型
+* 错误处理
+* 测试风格
+* 注册/发现机制
+
+## 使用时机
+
+* "为此项目构建 Jira 连接器"
+* "按照现有模式添加 Slack 提供商"
+* "为此 API 创建新集成"
+* "构建符合仓库连接器风格的插件"
+
+## 约束条件
+
+* 若仓库已有集成架构，不得自行发明新架构
+* 不得仅从供应商文档入手；应优先参考仓库内现有连接器
+* 若仓库需要注册机制、测试和文档，不得仅停留在传输代码层面
+* 若仓库有更新的当前模式，不得盲目复制旧连接器
+
+## 工作流程
+
+### 1. 学习内部风格
+
+检查至少 2 个现有连接器/提供商，并映射：
+
+* 文件布局
+* 抽象边界
+* 配置模型
+* 重试/分页约定
+* 注册钩子
+* 测试夹具和命名规范
+
+### 2. 缩小目标集成范围
+
+仅定义仓库实际需要的接口：
+
+* 认证流程
+* 关键实体
+* 核心读写操作
+* 分页和速率限制
+* Webhook 或轮询模型
+
+### 3. 按仓库原生层次构建
+
+典型分层：
+
+* 配置/模式
+* 客户端/传输层
+* 映射层
+* 连接器/提供商入口
+* 注册机制
+* 测试
+
+### 4. 对照源模式验证
+
+新连接器应在代码库中显得自然，而非从不同生态导入。
+
+## 参考模板
+
+### 提供商风格
+
+```text
+providers/
+  existing_provider/
+    __init__.py
+    provider.py
+    config.py
+```
+
+### 连接器风格
+
+```text
+integrations/
+  existing/
+    client.py
+    models.py
+    connector.py
+```
+
+### TypeScript 插件风格
+
+```text
+src/integrations/
+  existing/
+    index.ts
+    client.ts
+    types.ts
+    test.ts
+```
+
+## 质量检查清单
+
+* \[ ] 匹配仓库内现有集成模式
+* \[ ] 存在配置验证
+* \[ ] 认证和错误处理明确
+* \[ ] 分页/重试行为遵循仓库规范
+* \[ ] 注册/发现机制完整
+* \[ ] 测试镜像宿主仓库风格
+* \[ ] 若仓库要求，更新文档/示例
+
+## 相关技能
+
+* `backend-patterns`
+* `mcp-server-patterns`
+* `github-ops`

docs/zh-CN/skills/automation-audit-ops/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: automation-audit-ops
+description: 面向ECC的以证据为先的自动化清单与重叠审计工作流。当用户希望在修复任何内容之前了解哪些作业、钩子、连接器、MCP服务器或包装器是活跃的、损坏的、冗余的或缺失时使用。
+origin: ECC
+---
+
+# 自动化审计运维
+
+当用户询问哪些自动化正在运行、哪些任务出现故障、哪里存在重叠，或者哪些工具和连接器当前正在实际发挥作用时，请使用此技能。
+
+这是一项以审计为先的操作技能。其任务是在重写任何内容之前，生成一份有证据支持的清单以及一套保留/合并/删除/下一步修复的建议集。
+
+## 技能栈
+
+在相关时，将这些 ECC 原生技能引入工作流程：
+
+* `workspace-surface-audit` 用于连接器、MCP、钩子和应用清单
+* `knowledge-ops` 当审计需要将实时仓库的真实情况与持久上下文进行核对时
+* `github-ops` 当答案依赖于 CI、计划工作流、议题或 PR 自动化时
+* `ecc-tools-cost-audit` 当真正的问题是兄弟应用仓库中的 webhook 扇出、队列任务或计费消耗时
+* `research-ops` 当需要将本地清单与当前平台支持或公开文档进行比较时
+* `verification-loop` 用于证明修复后的状态，而不是依赖假设的恢复
+
+## 使用时机
+
+* 用户询问"我有哪些自动化"、"什么在运行"、"什么出故障了"或"什么重叠了"
+* 任务涉及 cron 任务、GitHub Actions、本地钩子、MCP 服务器、连接器、包装器或应用集成
+* 用户想知道从其他代理系统移植了什么，以及哪些还需要在 ECC 内部重建
+* 工作区积累了多种执行同一任务的方式，用户希望有一条规范的路径
+
+## 防护栏
+
+* 除非用户明确要求修复，否则以只读方式开始
+* 区分：
+  * 已配置
+  * 已验证身份
+  * 最近已验证
+  * 过时或损坏
+  * 完全缺失
+* 不要仅仅因为某个技能或配置引用了某个工具，就声称该工具正在运行
+* 在证据表存在之前，不要合并或删除重叠的表面
+
+## 工作流程
+
+### 1. 盘点真实表面
+
+在理论化之前，先读取当前的实时表面：
+
+* 仓库钩子和本地钩子脚本
+* GitHub Actions 和计划工作流
+* MCP 配置和已启用的服务器
+* 基于连接器或应用的集成
+* 包装器脚本和特定仓库的自动化入口点
+
+按表面分组：
+
+* 本地运行时
+* 仓库 CI / 自动化
+* 连接的外部系统
+* 消息传递 / 通知
+* 计费 / 客户运营
+* 研究 / 监控
+
+### 2. 按实时状态对每个项目进行分类
+
+对于每个发现的自动化，标记：
+
+* 已配置
+* 已验证身份
+* 最近已验证
+* 过时或损坏
+* 缺失
+
+然后对问题类型进行分类：
+
+* 活动故障
+* 身份验证中断
+* 状态过时
+* 重叠或冗余
+* 功能缺失
+
+### 3. 追溯证据路径
+
+为每个重要声明提供具体来源：
+
+* 文件路径
+* 工作流运行
+* 钩子日志
+* 配置条目
+* 最近的命令输出
+* 确切的故障特征
+
+如果当前状态不明确，请直接说明，而不是假装审计已完成。
+
+### 4. 以保留 / 合并 / 删除 / 下一步修复结束
+
+对于每个重叠或可疑的表面，返回一个决策：
+
+* 保留
+* 合并
+* 删除
+* 下一步修复
+
+其价值在于将杂乱的自动化整合到一条规范的 ECC 路径中，而不是保留每一条历史路径。
+
+## 输出格式
+
+```text
+当前表面
+- 自动化
+- 来源
+- 实时状态
+- 证据
+
+发现
+- 活跃故障
+- 重叠
+- 过时状态
+- 缺失能力
+
+建议
+- 保留
+- 合并
+- 删除
+- 下次修复
+
+下一步ECC行动
+- 需加强的具体技能/钩子/工作流/应用通道
+```
+
+## 常见陷阱
+
+* 当可以读取实时清单时，不要凭记忆回答
+* 不要将"配置中存在"视为"正在工作"
+* 在指出故障的高信号路径之前，不要修复低价值的冗余
+* 如果用户首先要求的是清单，不要将任务扩大为仓库重写
+
+## 验证
+
+* 重要声明需引用实时证据路径
+* 每个发现的自动化都需标有清晰的实时状态类别
+* 最终建议需区分保留 / 合并 / 删除 / 下一步修复

docs/zh-CN/skills/autonomous-agent-harness/SKILL.md

@@ -0,0 +1,279 @@
+---
+name: autonomous-agent-harness
+description: 将 Claude Code 转变为具有持久记忆、定时操作、计算机使用和任务队列的完全自主代理系统。通过利用 Claude Code 的原生定时任务、调度、MCP 工具和记忆，取代独立的代理框架（Hermes、AutoGPT）。当用户需要持续自主操作、定时任务或自我导向的代理循环时使用。
+origin: ECC
+---
+
+# 自主代理框架
+
+仅使用原生功能和 MCP 服务器，将 Claude Code 转变为持久化、自我导向的代理系统。
+
+## 同意与安全边界
+
+自主操作必须由用户明确请求并划定范围。除非用户已批准该能力以及当前设置的目标工作空间，否则不得创建计划、调度远程代理、写入持久化内存、使用计算机控制、发布外部内容、修改第三方资源或处理私人通信。
+
+在启用定期或事件驱动操作之前，优先使用预演计划和本地队列文件。将凭据、私有工作空间导出、个人数据集和账户特定自动化排除在可复用的 ECC 工件之外。
+
+## 何时激活
+
+* 用户需要一个持续运行或按计划运行的代理
+* 设置定期触发的自动化工作流
+* 构建一个跨会话记住上下文的个人 AI 助手
+* 用户说“每天运行这个”、“定期检查这个”、“持续监控”
+* 希望复制 Hermes、AutoGPT 或类似自主代理框架的功能
+* 需要计算机使用与计划执行相结合
+
+## 架构
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│                    Claude Code 运行时                         │
+│                                                              │
+│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌─────────────┐ │
+│  │  定时任务 │  │  远程调度 │  │  记忆存储 │  │  计算机使用  │ │
+│  │  调度器   │  │  代理    │  │          │  │             │ │
+│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └──────┬──────┘ │
+│       │              │             │                │        │
+│       ▼              ▼             ▼                ▼        │
+│  ┌──────────────────────────────────────────────────────┐    │
+│  │              ECC 技能 + 代理层                        │    │
+│  │                                                      │    │
+│  │  skills/     agents/     commands/     hooks/        │    │
+│  └──────────────────────────────────────────────────────┘    │
+│       │              │             │                │        │
+│       ▼              ▼             ▼                ▼        │
+│  ┌──────────────────────────────────────────────────────┐    │
+│  │              MCP 服务器层                             │    │
+│  │                                                      │    │
+│  │  memory    github    exa    supabase    browser-use  │    │
+│  └──────────────────────────────────────────────────────┘    │
+└──────────────────────────────────────────────────────────────┘
+```
+
+## 核心组件
+
+### 1. 持久化内存
+
+使用 Claude Code 的内置内存系统，并通过 MCP 内存服务器增强以处理结构化数据。
+
+**内置内存**（`~/.claude/projects/*/memory/`）：
+
+* 用户偏好、反馈、项目上下文
+* 存储为带有前置元数据的 Markdown 文件
+* 在会话启动时自动加载
+
+**MCP 内存服务器**（结构化知识图谱）：
+
+* 实体、关系、观察
+* 可查询的图结构
+* 跨会话持久化
+
+**内存模式：**
+
+```
+# 短期：当前会话上下文
+使用 TodoWrite 进行会话内任务追踪
+
+# 中期：项目记忆文件
+写入 ~/.claude/projects/*/memory/ 以实现跨会话回忆
+
+# 长期：MCP 知识图谱
+使用 mcp__memory__create_entities 创建永久结构化数据
+使用 mcp__memory__create_relations 进行关系映射
+使用 mcp__memory__add_observations 添加关于已知实体的新事实
+```
+
+### 2. 计划操作（定时任务）
+
+使用 Claude Code 的计划任务创建定期代理操作。
+
+**设置定时任务：**
+
+```
+# Via MCP tool
+mcp__scheduled-tasks__create_scheduled_task({
+  name: "daily-pr-review",
+  schedule: "0 9 * * 1-5",  # 工作日上午9点
+  prompt: "Review all open PRs in affaan-m/everything-claude-code. For each: check CI status, review changes, flag issues. Post summary to memory.",
+  project_dir: "/path/to/repo"
+})
+
+# Via claude -p (程序化模式)
+echo "Review open PRs and summarize" | claude -p --project /path/to/repo
+```
+
+**有用的定时任务模式：**
+
+| 模式 | 计划 | 用例 |
+|---------|----------|----------|
+| 每日站会 | `0 9 * * 1-5` | 审查 PR、问题、部署状态 |
+| 每周回顾 | `0 10 * * 1` | 代码质量指标、测试覆盖率 |
+| 每小时监控 | `0 * * * *` | 生产健康、错误率检查 |
+| 夜间构建 | `0 2 * * *` | 运行完整测试套件、安全扫描 |
+| 会前准备 | `*/30 * * * *` | 为即将到来的会议准备上下文 |
+
+### 3. 调度 / 远程代理
+
+远程触发 Claude Code 代理以进行事件驱动的工作流。
+
+**调度模式：**
+
+```bash
+# Trigger from CI/CD
+curl -X POST "https://api.anthropic.com/dispatch" \
+  -H "Authorization: Bearer $ANTHROPIC_API_KEY" \
+  -d '{"prompt": "Build failed on main. Diagnose and fix.", "project": "/repo"}'
+
+# Trigger from webhook
+# GitHub webhook → dispatch → Claude agent → fix → PR
+
+# Trigger from another agent
+claude -p "Analyze the output of the security scan and create issues for findings"
+```
+
+### 4. 计算机使用
+
+利用 Claude 的计算机使用 MCP 进行物理世界交互。
+
+**能力：**
+
+* 浏览器自动化（导航、点击、填写表单、截图）
+* 桌面控制（打开应用、输入、鼠标控制）
+* 超越 CLI 的文件系统操作
+
+**在框架内的用例：**
+
+* Web UI 的自动化测试
+* 表单填写和数据录入
+* 基于截图的监控
+* 多应用工作流
+
+### 5. 任务队列
+
+管理一个跨会话边界的持久化任务队列。
+
+**实现：**
+
+```
+# 通过记忆实现任务持久化
+将任务队列写入 ~/.claude/projects/*/memory/task-queue.md
+
+# 任务格式
+---
+name: task-queue
+type: project
+description: 用于自主操作的持久化任务队列
+---
+
+## 活跃任务
+- [ ] PR #123: 审查并在CI通过后批准
+- [ ] 监控部署：每30分钟检查一次 /health，持续2小时
+- [ ] 调研：在AI工具领域寻找5个潜在客户
+
+## 已完成
+- [x] 每日站会：审查了3个PR，2个问题
+```
+
+## 替换 Hermes
+
+| Hermes 组件 | ECC 等效组件 | 如何实现 |
+|------------------|---------------|-----|
+| 网关/路由器 | Claude Code 调度 + 定时任务 | 计划任务触发代理会话 |
+| 内存系统 | Claude 内存 + MCP 内存服务器 | 内置持久化 + 知识图谱 |
+| 工具注册表 | MCP 服务器 | 动态加载的工具提供者 |
+| 编排 | ECC 技能 + 代理 | 技能定义指导代理行为 |
+| 计算机使用 | 计算机使用 MCP | 原生浏览器和桌面控制 |
+| 上下文管理器 | 会话管理 + 内存 | ECC 2.0 会话生命周期 |
+| 任务队列 | 内存持久化任务列表 | TodoWrite + 内存文件 |
+
+## 设置指南
+
+### 步骤 1：配置 MCP 服务器
+
+确保这些在 `~/.claude.json` 中：
+
+```json
+{
+  "mcpServers": {
+    "memory": {
+      "command": "npx",
+      "args": ["-y", "@anthropic/memory-mcp-server"]
+    },
+    "scheduled-tasks": {
+      "command": "npx",
+      "args": ["-y", "@anthropic/scheduled-tasks-mcp-server"]
+    },
+    "computer-use": {
+      "command": "npx",
+      "args": ["-y", "@anthropic/computer-use-mcp-server"]
+    }
+  }
+}
+```
+
+### 步骤 2：创建基础定时任务
+
+```bash
+# Daily morning briefing
+claude -p "Create a scheduled task: every weekday at 9am, review my GitHub notifications, open PRs, and calendar. Write a morning briefing to memory."
+
+# Continuous learning
+claude -p "Create a scheduled task: every Sunday at 8pm, extract patterns from this week's sessions and update the learned skills."
+```
+
+### 步骤 3：初始化内存图谱
+
+```bash
+# Bootstrap your identity and context
+claude -p "Create memory entities for: me (user profile), my projects, my key contacts. Add observations about current priorities."
+```
+
+### 步骤 4：启用计算机使用（可选）
+
+授予计算机使用 MCP 浏览器和桌面控制所需的权限。
+
+## 示例工作流
+
+### 自主 PR 审查员
+
+```
+Cron: 工作时间内每30分钟执行一次
+1. 检查关注仓库的新PR
+2. 对每个新PR：
+   - 在本地拉取分支
+   - 运行测试
+   - 使用代码审查代理审查变更
+   - 通过GitHub MCP发布审查评论
+3. 更新审查状态到记忆库
+```
+
+### 个人研究代理
+
+```
+Cron: 每天上午6点执行
+1. 检查内存中保存的搜索查询
+2. 对每个查询运行Exa搜索
+3. 总结新发现
+4. 与昨日结果进行对比
+5. 将摘要写入内存
+6. 标记高优先级项目供晨间审阅
+```
+
+### 会议准备代理
+
+```
+触发条件：每个日历事件前30分钟
+1. 读取日历事件详情
+2. 搜索记忆中关于参会者的背景信息
+3. 提取与参会者近期的邮件/Slack讨论记录
+4. 准备谈话要点和议程建议
+5. 将准备文档写入记忆
+```
+
+## 约束
+
+* 定时任务在隔离的会话中运行——除非通过内存，否则它们不与交互式会话共享上下文。
+* 计算机使用需要明确的权限授予。不要假设可以访问。
+* 远程调度可能有速率限制。设计定时任务时使用适当的间隔。
+* 内存文件应保持简洁。归档旧数据，而不是让文件无限增长。
+* 始终验证计划任务是否成功完成。在定时任务提示中添加错误处理。

docs/zh-CN/skills/benchmark/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: benchmark
+description: 使用此技能测量性能基线，检测PR前后的回归，并比较堆栈替代方案。
+origin: ECC
+---
+
+# 基准测试 — 性能基线及回归检测
+
+## 使用场景
+
+* 在 PR 前后测量性能影响
+* 为项目建立性能基线
+* 用户反馈"感觉变慢"时
+* 发布前确保达到性能目标
+* 对比不同技术栈的性能表现
+
+## 工作原理
+
+### 模式 1：页面性能
+
+通过浏览器 MCP 测量真实浏览器指标：
+
+```
+1. 导航至每个目标 URL
+2. 测量核心网页指标：
+   - LCP（最大内容绘制）— 目标 < 2.5 秒
+   - CLS（累积布局偏移）— 目标 < 0.1
+   - INP（与下一次绘制的交互）— 目标 < 200 毫秒
+   - FCP（首次内容绘制）— 目标 < 1.8 秒
+   - TTFB（首字节时间）— 目标 < 800 毫秒
+3. 测量资源大小：
+   - 页面总重量（目标 < 1MB）
+   - JS 包大小（目标 < 200KB gzip 压缩后）
+   - CSS 大小
+   - 图片重量
+   - 第三方脚本重量
+4. 统计网络请求数量
+5. 检查阻塞渲染的资源
+```
+
+### 模式 2：API 性能
+
+对 API 端点进行基准测试：
+
+```
+1. 每个端点请求 100 次
+2. 测量：p50、p95、p99 延迟
+3. 追踪：响应大小、状态码
+4. 负载测试：10 个并发请求
+5. 与 SLA 目标进行对比
+```
+
+### 模式 3：构建性能
+
+测量开发反馈循环效率：
+
+```
+1. 冷构建时间
+2. 热重载时间 (HMR)
+3. 测试套件执行时间
+4. TypeScript 检查时间
+5. 代码检查时间
+6. Docker 构建时间
+```
+
+### 模式 4：前后对比
+
+在变更前后运行以测量影响：
+
+```
+/benchmark baseline    # 保存当前指标
+# ... 进行更改 ...
+/benchmark compare     # 与基线进行比较
+```
+
+输出结果：
+
+```
+| Metric | Before | After | Delta | Verdict |
+|--------|--------|-------|-------|---------|
+| LCP | 1.2s | 1.4s | +200ms | WARNING: WARN |
+| Bundle | 180KB | 175KB | -5KB | ✓ BETTER |
+| Build | 12s | 14s | +2s | WARNING: WARN |
+```
+
+## 输出
+
+将基线数据以 JSON 格式存储在 `.ecc/benchmarks/` 中。通过 Git 追踪，便于团队共享基线。
+
+## 集成
+
+* CI：在每个 PR 上运行 `/benchmark compare`
+* 配合 `/canary-watch` 进行部署后监控
+* 配合 `/browser-qa` 完成发布前完整检查清单

docs/zh-CN/skills/brand-voice/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: brand-voice
+description: 从真实的帖子、文章、发布说明、文档或网站文案中构建基于源材料的写作风格档案，然后在内容、外展和社交工作流中重复使用该档案。当用户希望保持声音一致性而不使用通用的AI写作套路时使用。
+origin: ECC
+---
+
+# 品牌声音
+
+从真实素材中构建持久的声音档案，然后将其应用于所有场景，避免每次都重新推导风格或默认使用通用AI文案。
+
+## 何时激活
+
+* 用户希望内容或外联具有特定声音
+* 为X、LinkedIn、邮件、发布帖、推文串或产品更新撰写内容
+* 将已知作者的语调适配到不同渠道
+* 现有内容赛道需要可复用的风格体系，而非一次性模仿
+
+## 素材优先级
+
+按以下顺序使用最强真实素材集：
+
+1. 近期原创X帖子和推文串
+2. 文章、随笔、备忘录、发布说明或新闻通讯
+3. 实际有效的外发邮件或私信
+4. 产品文档、更新日志、README框架和网站文案
+
+不得使用通用平台范例作为素材。
+
+## 收集流程
+
+1. 尽可能收集5至20个代表性样本。
+2. 优先选择近期素材，除非用户明确表示旧素材更具代表性。
+3. 若素材集明显区分，将"公开发布声音"与"私下工作声音"分开处理。
+4. 若可访问实时X数据，在起草前使用`x-api`拉取近期原创帖子。
+5. 若网站文案重要，包含当前ECC落地页及仓库/插件框架。
+
+## 提取内容
+
+* 节奏与句子长度
+* 压缩与解释的平衡
+* 大小写规范
+* 括号使用方式
+* 问题频率与目的
+* 主张的尖锐程度
+* 数字、机制或实证的出现频率
+* 过渡方式
+* 作者从不使用的表达
+
+## 输出约定
+
+生成一个可复用的`VOICE PROFILE`代码块，供下游技能直接调用。使用[references/voice-profile-schema.md](references/voice-profile-schema.md)中的架构。
+
+保持档案结构化且足够简短，以便在会话上下文中复用。重点不是文学批评，而是操作复用。
+
+## Affaan / ECC 默认设置
+
+若用户需要Affaan/ECC声音且实时素材不足，除非有更新素材覆盖，否则从以下默认值开始：
+
+* 直接、压缩、具体
+* 细节、机制、实证和数字优于形容词
+* 括号用于限定、缩小范围或过度澄清
+* 大小写遵循常规，除非有真实理由打破规则
+* 问题罕见，不得用作诱饵
+* 语调可尖锐、直率、怀疑或干涩
+* 过渡应自然，而非平滑掩盖
+
+## 硬性禁止
+
+删除并重写以下内容：
+
+* 虚假好奇心钩子
+* "不是X，只是Y"
+* "无废话"
+* 强制小写
+* LinkedIn思想领袖节奏
+* 诱饵问题
+* "激动地分享"
+* 通用创始人历程填充
+* 俗气括号
+
+## 持久化规则
+
+* 在同一会话的相关任务中复用最新确认的`VOICE PROFILE`。
+* 若用户要求持久化工件，将档案保存至指定工作区位置或记忆存储区。
+* 除非用户明确要求，不得创建存储个人声音指纹的仓库跟踪文件。
+
+## 下游使用
+
+在以下场景之前或之中使用此技能：
+
+* `content-engine`
+* `crosspost`
+* `lead-intelligence`
+* 文章或发布文案撰写
+* 在X、LinkedIn和邮件上的冷启动或预热外联
+
+若其他技能已包含部分声音捕获章节，此技能为权威来源。

docs/zh-CN/skills/canary-watch/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: canary-watch
+description: 使用此技能在部署、合并或依赖升级后监控已部署的URL是否存在回归问题。
+origin: ECC
+---
+
+# Canary Watch — 部署后监控
+
+## 使用场景
+
+* 部署到生产或预发布环境后
+* 合并高风险 PR 后
+* 需要验证修复是否生效时
+* 发布窗口期间的持续监控
+* 依赖升级后
+
+## 工作原理
+
+监控已部署 URL 是否存在回归问题。循环运行，直至手动停止或监控窗口过期。
+
+### 监控内容
+
+```
+1. HTTP 状态 — 页面是否返回 200？
+2. 控制台错误 — 是否出现之前没有的新错误？
+3. 网络故障 — 是否存在失败的 API 调用、5xx 响应？
+4. 性能 — LCP/CLS/INP 与基线相比是否有退化？
+5. 内容 — 关键元素是否消失？（h1、导航、页脚、CTA）
+6. API 健康 — 关键端点是否在 SLA 内响应？
+```
+
+### 监控模式
+
+**快速检查**（默认）：单次执行，报告结果
+
+```
+/canary-watch https://myapp.com
+```
+
+**持续监控**：每 N 分钟检查一次，持续 M 小时
+
+```
+/canary-watch https://myapp.com --interval 5m --duration 2h
+```
+
+**差异模式**：对比预发布环境与生产环境
+
+```
+/canary-watch --compare https://staging.myapp.com https://myapp.com
+```
+
+### 告警阈值
+
+```yaml
+critical:  # immediate alert
+  - HTTP status != 200
+  - Console error count > 5 (new errors only)
+  - LCP > 4s
+  - API endpoint returns 5xx
+
+warning:   # flag in report
+  - LCP increased > 500ms from baseline
+  - CLS > 0.1
+  - New console warnings
+  - Response time > 2x baseline
+
+info:      # log only
+  - Minor performance variance
+  - New network requests (third-party scripts added?)
+```
+
+### 通知机制
+
+当超过关键阈值时：
+
+* 桌面通知（macOS/Linux）
+* 可选：Slack/Discord Webhook
+* 记录至 `~/.claude/canary-watch.log`
+
+## 输出
+
+```markdown
+## Canary 报告 — myapp.com — 2026-03-23 03:15 PST
+
+### 状态：健康 ✓
+
+| 检查项 | 结果 | 基线 | 偏差 |
+|-------|--------|----------|-------|
+| HTTP | 200 ✓ | 200 | — |
+| 控制台错误 | 0 ✓ | 0 | — |
+| LCP | 1.8s ✓ | 1.6s | +200ms |
+| CLS | 0.01 ✓ | 0.01 | — |
+| API /health | 145ms ✓ | 120ms | +25ms |
+
+### 未检测到回归问题。部署状态良好。
+```
+
+## 集成
+
+配合使用：
+
+* `/browser-qa` 进行部署前验证
+* 钩子：在 `git push` 上添加 PostToolUse 钩子，部署后自动检查
+* CI：在 GitHub Actions 的部署步骤后运行

docs/zh-CN/skills/ck/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: ck
+description: Claude Code 的每个项目持久化记忆。在会话启动时自动加载项目上下文，通过 git 活动追踪会话，并写入原生记忆。命令运行确定性的 Node.js 脚本——行为在不同模型版本间保持一致。
+origin: community
+version: 2.0.0
+author: sreedhargs89
+repo: https://github.com/sreedhargs89/context-keeper
+---
+
+# ck — 上下文管家
+
+你是**上下文管家**助手。当用户调用任何 `/ck:*` 命令时，
+运行相应的 Node.js 脚本，并将其标准输出原样呈现给用户。
+脚本位于：`~/.claude/skills/ck/commands/`（使用 `$HOME` 展开 `~`）。
+
+***
+
+## 数据布局
+
+```
+~/.claude/ck/
+├── projects.json              ← 路径 → {名称, 上下文目录, 最后更新时间}
+└── contexts/<名称>/
+    ├── context.json           ← 真实来源（结构化 JSON，v2 版本）
+    └── CONTEXT.md             ← 自动生成的视图 — 请勿手动编辑
+```
+
+***
+
+## 命令
+
+### `/ck:init` — 注册项目
+
+```bash
+node "$HOME/.claude/skills/ck/commands/init.mjs"
+```
+
+脚本输出包含自动检测信息的 JSON。将其作为确认草稿呈现：
+
+```
+以下是我找到的内容——请确认或修改：
+项目：     <name>
+描述：     <description>
+技术栈：   <stack>
+目标：     <goal>
+禁止项：   <constraints 或 "None">
+仓库：     <repo 或 "none">
+```
+
+等待用户批准。应用任何编辑。然后将确认后的 JSON 通过管道传递给 save.mjs --init：
+
+```bash
+echo '<confirmed-json>' | node "$HOME/.claude/skills/ck/commands/save.mjs" --init
+```
+
+确认后的 JSON 模式：`{"name":"...","path":"...","description":"...","stack":["..."],"goal":"...","constraints":["..."],"repo":"..." }`
+
+***
+
+### `/ck:save` — 保存会话状态
+
+**这是唯一需要 LLM 分析的命令。** 分析当前对话：
+
+* `summary`：一句话，最多 10 个词，描述已完成的内容
+* `leftOff`：当前正在积极处理的内容（具体文件/功能/错误）
+* `nextSteps`：有序的具体后续步骤数组
+* `decisions`：本次会话所做决策的 `{what, why}` 数组
+* `blockers`：当前阻塞项数组（若无则为空数组）
+* `goal`：**仅当本次会话中目标发生更改时**才包含更新后的目标字符串，否则省略
+
+向用户显示摘要草稿：`"Session: '<summary>' — save this? (yes / edit)"`
+等待确认。然后通过管道传递给 save.mjs：
+
+```bash
+echo '<json>' | node "$HOME/.claude/skills/ck/commands/save.mjs"
+```
+
+JSON 模式（精确）：`{"summary":"...","leftOff":"...","nextSteps":["..."],"decisions":[{"what":"...","why":"..."}],"blockers":["..."]}`
+逐字显示脚本的标准输出确认信息。
+
+***
+
+### `/ck:resume [name|number]` — 完整简报
+
+```bash
+node "$HOME/.claude/skills/ck/commands/resume.mjs" [arg]
+```
+
+逐字显示输出。然后询问："从这里继续？还是有什么变化？"
+如果用户报告有变化 → 立即运行 `/ck:save`。
+
+***
+
+### `/ck:info [name|number]` — 快速快照
+
+```bash
+node "$HOME/.claude/skills/ck/commands/info.mjs" [arg]
+```
+
+逐字显示输出。无需后续提问。
+
+***
+
+### `/ck:list` — 项目组合视图
+
+```bash
+node "$HOME/.claude/skills/ck/commands/list.mjs"
+```
+
+逐字显示输出。如果用户回复数字或名称 → 运行 `/ck:resume`。
+
+***
+
+### `/ck:forget [name|number]` — 移除项目
+
+首先解析项目名称（如有需要运行 `/ck:list`）。
+询问：`"This will permanently delete context for '<name>'. Are you sure? (yes/no)"`
+如果是：
+
+```bash
+node "$HOME/.claude/skills/ck/commands/forget.mjs" [name]
+```
+
+逐字显示确认信息。
+
+***
+
+### `/ck:migrate` — 将 v1 数据转换为 v2
+
+```bash
+node "$HOME/.claude/skills/ck/commands/migrate.mjs"
+```
+
+首先进行试运行：
+
+```bash
+node "$HOME/.claude/skills/ck/commands/migrate.mjs" --dry-run
+```
+
+逐字显示输出。将所有 v1 的 CONTEXT.md + meta.json 文件迁移为 v2 的 context.json。
+原始文件备份为 `meta.json.v1-backup` — 不会删除任何内容。
+
+***
+
+## 会话启动钩子
+
+位于 `~/.claude/skills/ck/hooks/session-start.mjs` 的钩子必须在
+`~/.claude/settings.json` 中注册，以便在会话启动时自动加载项目上下文：
+
+```json
+{
+  "hooks": {
+    "SessionStart": [
+      { "hooks": [{ "type": "command", "command": "node \"~/.claude/skills/ck/hooks/session-start.mjs\"" }] }
+    ]
+  }
+}
+```
+
+该钩子每次会话注入约 100 个 token（紧凑的 5 行摘要）。它还会检测
+未保存的会话、自上次保存以来的 git 活动，以及与 CLAUDE.md 的目标不匹配。
+
+***
+
+## 规则
+
+* 在 Bash 调用中始终将 `~` 展开为 `$HOME`。
+* 命令不区分大小写：`/CK:SAVE`、`/ck:save`、`/Ck:Save` 均有效。
+* 如果脚本以退出码 1 退出，则将其标准输出显示为错误消息。
+* 切勿直接编辑 `context.json` 或 `CONTEXT.md` — 始终使用脚本。
+* 如果 `projects.json` 格式错误，请告知用户并提供重置为 `{}` 的选项。

docs/zh-CN/skills/click-path-audit/SKILL.md

@@ -0,0 +1,257 @@
+---
+name: click-path-audit
+description: "追踪每个面向用户的按钮/触点的完整状态变化序列，以发现功能单独工作但相互抵消、产生错误最终状态或使UI处于不一致状态的错误。适用于：系统调试未发现错误但用户报告按钮失效，或在任何涉及共享状态存储的重大重构之后。"
+origin: community
+---
+
+# /click-path-audit — 行为流审计
+
+发现静态代码审查遗漏的缺陷：状态交互副作用、顺序调用间的竞态条件，以及相互静默撤销的处理程序。
+
+## 解决的问题
+
+传统调试检查：
+
+* 函数是否存在？（缺少连接）
+* 是否崩溃？（运行时错误）
+* 是否返回正确类型？（数据流）
+
+但未检查：
+
+* **最终 UI 状态是否与按钮标签承诺一致？**
+* **函数 B 是否静默撤销了函数 A 刚刚执行的操作？**
+* **共享状态（Zustand/Redux/context）是否存在抵消预期操作的副作用？**
+
+真实案例：一个"新邮件"按钮依次调用了 `setComposeMode(true)` 和 `selectThread(null)`。两者单独工作正常。但 `selectThread` 有一个副作用重置了 `composeMode: false`。按钮毫无反应。系统化调试发现了 54 个缺陷——这个被遗漏了。
+
+***
+
+## 工作原理
+
+针对目标区域内的每个交互触点：
+
+```
+1. 识别处理函数（onClick、onSubmit、onChange 等）
+2. 按顺序追踪处理函数中的每个函数调用
+3. 对于每个函数调用：
+   a. 它读取了哪些状态？
+   b. 它写入了哪些状态？
+   c. 它是否对共享状态产生了副作用？
+   d. 它是否作为副作用重置/清除了任何状态？
+4. 检查：后续调用是否会撤销前面调用的状态变更？
+5. 检查：最终状态是否符合用户对按钮标签的预期？
+6. 检查：是否存在竞态条件（异步调用以错误顺序解析）？
+```
+
+***
+
+## 执行步骤
+
+### 步骤 1：映射状态存储
+
+在审计任何触点之前，构建每个状态存储操作的副作用映射：
+
+```
+对于作用域内的每个 Zustand 存储 / React 上下文：
+  对于每个操作/设置器：
+    - 它设置了哪些字段？
+    - 它是否作为副作用重置了其他字段？
+    - 文档：actionName → {sets: [...], resets: [...]}
+```
+
+这是关键参考。"新邮件"缺陷在不知道 `selectThread` 重置了 `composeMode` 的情况下是不可见的。
+
+**输出格式：**
+
+```
+STORE: emailStore
+  setComposeMode(bool) → 设置: {composeMode}
+  selectThread(thread|null) → 设置: {selectedThread, selectedThreadId, messages, drafts, selectedDraft, summary} 重置: {composeMode: false, composeData: null, redraftOpen: false}
+  setDraftGenerating(bool) → 设置: {draftGenerating}
+  ...
+
+危险的重置（清除不属于自身状态的操作）：
+  selectThread → 重置 composeMode（由 setComposeMode 拥有）
+  reset → 重置所有内容
+```
+
+### 步骤 2：审计每个触点
+
+针对目标区域内的每个按钮/开关/表单提交：
+
+```
+TOUCHPOINT: [按钮标签] 在 [组件:行]
+  HANDLER: onClick → {
+    调用 1: functionA() → 设置 {X: true}
+    调用 2: functionB() → 设置 {Y: null} 重置 {X: false}  ← 冲突
+  }
+  EXPECTED: 用户看到 [按钮标签所承诺的描述]
+  ACTUAL: X 为 false，因为 functionB 重置了它
+  VERDICT: BUG — [描述]
+```
+
+**检查以下每种缺陷模式：**
+
+#### 模式 1：顺序撤销
+
+```
+handler() {
+  setState_A(true)     // 设置 X = true
+  setState_B(null)     // 副作用：重置 X = false
+}
+// 结果：X 为 false。第一次调用毫无意义。
+```
+
+#### 模式 2：异步竞态
+
+```
+handler() {
+  fetchA().then(() => setState({ loading: false }))
+  fetchB().then(() => setState({ loading: true }))
+}
+// 结果：最终的 loading 状态取决于哪个先完成
+```
+
+#### 模式 3：过期闭包
+
+```
+const [count, setCount] = useState(0)
+const handler = useCallback(() => {
+  setCount(count + 1)  // 捕获了过时的 count
+  setCount(count + 1)  // 同样的过时 count — 只增加 1，而不是 2
+}, [count])
+```
+
+#### 模式 4：缺失状态转换
+
+```
+// 按钮显示"保存"，但处理程序仅验证，从未实际保存
+// 按钮显示"删除"，但处理程序设置了一个标志而未调用API
+// 按钮显示"发送"，但API端点已被移除/损坏
+```
+
+#### 模式 5：条件死路径
+
+```
+handler() {
+  if (someState) {        // 此时 someState 始终为 false
+    doTheActualThing()    // 永远不会执行到
+  }
+}
+```
+
+#### 模式 6：useEffect 干扰
+
+```
+// Button 设置 stateX = true
+// useEffect 监听 stateX 并将其重置为 false
+// 用户看不到任何变化
+```
+
+### 步骤 3：报告
+
+针对发现的每个缺陷：
+
+```
+CLICK-PATH-NNN: [严重性: 严重/高/中/低]
+  触点: [按钮标签] 位于 [文件:行号]
+  模式: [顺序撤销 / 异步竞态 / 过期闭包 / 缺失过渡 / 死路径 / useEffect 干扰]
+  处理函数: [函数名或内联]
+  追踪:
+    1. [调用] → 设置 {字段: 值}
+    2. [调用] → 重置 {字段: 值}  ← 冲突
+  预期: [用户期望的结果]
+  实际: [实际发生的结果]
+  修复: [具体修复方案]
+```
+
+***
+
+## 范围控制
+
+此审计成本较高。请适当限定范围：
+
+* **全应用审计：** 在发布或重大重构后使用。按页面启动并行代理。
+* **单页面审计：** 在构建新页面或用户报告按钮失效后使用。
+* **存储聚焦审计：** 在修改 Zustand 存储后使用——审计所有使用已更改操作的消费者。
+
+### 全应用推荐的代理拆分：
+
+```
+Agent 1：映射所有状态存储（步骤 1）——这是所有其他代理的共享上下文
+Agent 2：仪表盘（任务、笔记、日志、想法）
+Agent 3：聊天（DanteChatColumn、JustChatPage）
+Agent 4：邮件（ThreadList、DraftArea、EmailsPage）
+Agent 5：项目（ProjectsPage、ProjectOverviewTab、NewProjectWizard）
+Agent 6：CRM（所有子标签页）
+Agent 7：个人资料、设置、保险库、通知
+Agent 8：管理套件（所有页面）
+```
+
+代理 1 必须首先完成。其输出是所有其他代理的输入。
+
+***
+
+## 何时使用
+
+* 系统化调试发现"无缺陷"但用户报告 UI 失效后
+* 修改任何 Zustand 存储操作后（检查所有调用者）
+* 任何涉及共享状态的重构后
+* 发布前，针对关键用户流程
+* 当按钮"无反应"时——这是解决该问题的工具
+
+## 何时不使用
+
+* 针对 API 级别缺陷（错误的响应结构、缺失端点）——使用系统化调试
+* 针对样式/布局问题——视觉检查
+* 针对性能问题——性能分析工具
+
+***
+
+## 与其他技能的集成
+
+* 在 `/superpowers:systematic-debugging`（发现其他 54 种缺陷类型）之后运行
+* 在 `/superpowers:verification-before-completion`（验证修复是否有效）之前运行
+* 反馈至 `/superpowers:test-driven-development`——此处发现的每个缺陷都应添加测试
+
+***
+
+## 示例：启发此技能的缺陷
+
+**ThreadList.tsx "新邮件"按钮：**
+
+```
+onClick={() => {
+  useEmailStore.getState().setComposeMode(true)   // ✓ 设置 composeMode = true
+  useEmailStore.getState().selectThread(null)      // ✗ 重置 composeMode = false
+}}
+```
+
+存储定义：
+
+```
+selectThread: (thread) => set({
+  selectedThread: thread,
+  selectedThreadId: thread?.id ?? null,
+  messages: [],
+  drafts: [],
+  selectedDraft: null,
+  summary: null,
+  composeMode: false,     // ← 这个静默重置导致按钮失效
+  composeData: null,
+  redraftOpen: false,
+})
+```
+
+**系统化调试遗漏了它**，因为：
+
+* 按钮有 onClick 处理程序（未失效）
+* 两个函数都存在（无缺失连接）
+* 两个函数均未崩溃（无运行时错误）
+* 数据类型正确（无类型不匹配）
+
+**点击路径审计捕获了它**，因为：
+
+* 步骤 1 映射出 `selectThread` 重置了 `composeMode`
+* 步骤 2 追踪处理程序：调用 1 设置为 true，调用 2 重置为 false
+* 判定：顺序撤销——最终状态与按钮意图矛盾

docs/zh-CN/skills/code-tour/SKILL.md

@@ -0,0 +1,244 @@
+---
+name: code-tour
+description: 创建 CodeTour `.tour` 文件——针对特定角色的、带有真实文件和行锚点的逐步演练。用于入职引导、架构演练、PR 演练、RCA 演练以及结构化的“解释其工作原理”请求。
+origin: ECC
+---
+
+# 代码导览
+
+创建 **CodeTour** `.tour` 文件，用于代码库导览，可直接打开真实文件并定位到指定行范围。导览文件存放在 `.tours/` 目录中，专为 CodeTour 格式设计，而非临时性的 Markdown 笔记。
+
+一个好的导览应针对特定读者讲述一个故事：
+
+* 他们正在查看什么
+* 为什么重要
+* 接下来应该遵循什么路径
+
+仅创建 `.tour` JSON 文件。不要在此技能范围内修改源代码。
+
+## 何时使用
+
+在以下情况下使用此技能：
+
+* 用户请求代码导览、入职导览、架构导览或 PR 导览
+* 用户说“解释 X 如何工作”，并希望获得可重用的引导式产物
+* 用户希望为新工程师或审阅者提供上手路径
+* 相比平铺直叙的摘要，引导式序列更适合该任务
+
+示例：
+
+* 新维护者入职
+* 单个服务或包的架构导览
+* 锚定到变更文件的 PR 审查导览
+* 展示故障路径的根本原因分析导览
+* 信任边界和关键检查的安全审查导览
+
+## 何时不使用
+
+| 不使用代码导览的情况 | 使用 |
+| --- | --- |
+| 在聊天中一次性解释就足够了 | 直接回答 |
+| 用户想要散文式文档，而不是 `.tour` 产物 | `documentation-lookup` 或仓库文档编辑 |
+| 任务是实现或重构 | 执行实现工作 |
+| 任务是没有导览产物的广泛代码库入职 | `codebase-onboarding` |
+
+## 工作流程
+
+### 1. 探索
+
+在编写任何内容之前探索仓库：
+
+* README 和包/应用入口点
+* 文件夹结构
+* 相关配置文件
+* 如果导览聚焦于 PR，则查看变更的文件
+
+在理解代码结构之前，不要开始编写步骤。
+
+### 2. 推断读者
+
+根据请求确定角色和深度。
+
+| 请求形式 | 角色 | 建议深度 |
+| --- | --- | --- |
+| "入职"，"新成员" | `new-joiner` | 9-13 步 |
+| "快速导览"，"快速了解" | `vibecoder` | 5-8 步 |
+| "架构" | `architect` | 14-18 步 |
+| "导览此 PR" | `pr-reviewer` | 7-11 步 |
+| "为什么这个出错了" | `rca-investigator` | 7-11 步 |
+| "安全审查" | `security-reviewer` | 7-11 步 |
+| "解释此功能如何工作" | `feature-explainer` | 7-11 步 |
+| "调试此路径" | `bug-fixer` | 7-11 步 |
+
+### 3. 读取并验证锚点
+
+每个文件路径和行锚点必须是真实的：
+
+* 确认文件存在
+* 确认行号在范围内
+* 如果使用选区，验证确切的代码块
+* 如果文件易变，优先使用基于模式的锚点
+
+切勿猜测行号。
+
+### 4. 编写 `.tour`
+
+写入：
+
+```text
+.tours/<persona>-<focus>.tour
+```
+
+保持路径确定且可读。
+
+### 5. 验证
+
+在完成之前：
+
+* 每个引用的路径都存在
+* 每行或每个选区都有效
+* 第一步锚定到真实文件或目录
+* 导览讲述连贯的故事，而非罗列文件
+
+## 步骤类型
+
+### 内容
+
+谨慎使用，通常仅用于结束步骤：
+
+```json
+{ "title": "Next Steps", "description": "You can now trace the request path end to end." }
+```
+
+不要将第一步设为纯内容。
+
+### 目录
+
+用于引导读者了解模块：
+
+```json
+{ "directory": "src/services", "title": "Service Layer", "description": "The core orchestration logic lives here." }
+```
+
+### 文件 + 行
+
+这是默认步骤类型：
+
+```json
+{ "file": "src/auth/middleware.ts", "line": 42, "title": "Auth Gate", "description": "Every protected request passes here first." }
+```
+
+### 选区
+
+当某个代码块比整个文件更重要时使用：
+
+```json
+{
+  "file": "src/core/pipeline.ts",
+  "selection": {
+    "start": { "line": 15, "character": 0 },
+    "end": { "line": 34, "character": 0 }
+  },
+  "title": "Request Pipeline",
+  "description": "This block wires validation, auth, and downstream execution."
+}
+```
+
+### 模式
+
+当精确行号可能发生变化时使用：
+
+```json
+{ "file": "src/app.ts", "pattern": "export default class App", "title": "Application Entry" }
+```
+
+### URI
+
+在需要时用于 PR、问题或文档：
+
+```json
+{ "uri": "https://github.com/org/repo/pull/456", "title": "The PR" }
+```
+
+## 编写规则：SMIG
+
+每个描述应回答：
+
+* **情境**：读者正在查看什么
+* **机制**：它是如何工作的
+* **影响**：为什么对此角色重要
+* **陷阱**：聪明的读者可能会错过什么
+
+保持描述简洁、具体，并基于实际代码。
+
+## 叙事结构
+
+除非任务明确需要不同结构，否则使用此弧线：
+
+1. 定位
+2. 模块地图
+3. 核心执行路径
+4. 边缘情况或陷阱
+5. 结束 / 下一步
+
+导览应感觉像一条路径，而非清单。
+
+## 示例
+
+```json
+{
+  "$schema": "https://aka.ms/codetour-schema",
+  "title": "API Service Tour",
+  "description": "Walkthrough of the request path for the payments service.",
+  "ref": "main",
+  "steps": [
+    {
+      "directory": "src",
+      "title": "Source Root",
+      "description": "All runtime code for the service starts here."
+    },
+    {
+      "file": "src/server.ts",
+      "line": 12,
+      "title": "Entry Point",
+      "description": "The server boots here and wires middleware before any route is reached."
+    },
+    {
+      "file": "src/routes/payments.ts",
+      "line": 8,
+      "title": "Payment Routes",
+      "description": "Every payments request enters through this router before hitting service logic."
+    },
+    {
+      "title": "Next Steps",
+      "description": "You can now follow any payment request end to end with the main anchors in place."
+    }
+  ]
+}
+```
+
+## 反模式
+
+| 反模式 | 修复 |
+| --- | --- |
+| 平铺直叙的文件列表 | 讲述一个步骤间有依赖关系的故事 |
+| 通用描述 | 指明具体的代码路径或模式 |
+| 猜测的锚点 | 先验证每个文件和行 |
+| 快速导览步骤过多 | 果断精简 |
+| 第一步是纯内容 | 将第一步锚定到真实文件或目录 |
+| 角色不匹配 | 为实际读者编写，而非通用工程师 |
+
+## 最佳实践
+
+* 步骤数量与仓库大小和角色深度成比例
+* 使用目录步骤进行定位，文件步骤用于实质内容
+* 对于 PR 导览，首先覆盖变更的文件
+* 对于单体仓库，将范围限定在相关包，而非导览所有内容
+* 以读者现在可以做什么来结束，而非总结
+
+## 相关技能
+
+* `codebase-onboarding`
+* `coding-standards`
+* `council`
+* 官方上游格式：`microsoft/codetour`

docs/zh-CN/skills/connections-optimizer/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: connections-optimizer
+description: 重新组织用户的X和LinkedIn网络，采用审查优先的修剪策略，提供添加/关注建议，并以用户真实口吻起草针对不同渠道的温和外联。当用户希望清理关注列表、向当前优先事项发展或围绕更高信号的关系重新平衡社交图谱时使用。
+origin: ECC
+---
+
+# 连接优化器
+
+重新组织用户的社交网络，而非将对外联系视为单向的潜在客户列表。
+
+本技能处理：
+
+* X（推特）关注清理与扩展
+* LinkedIn 关注与连接分析
+* 优先审核队列
+* 添加与关注建议
+* 温暖路径识别
+* 以用户真实口吻生成 Apple Mail、X DM 和 LinkedIn 草稿
+
+## 何时激活
+
+* 用户想要清理其 X 关注列表
+* 用户想要重新平衡关注或保持连接的对象
+* 用户说"清理我的网络"、"我应该取消关注谁"、"我应该关注谁"、"我应该与谁重新建立联系"
+* 外联质量取决于网络结构，而不仅仅是生成冷名单
+
+## 必要输入
+
+收集或推断：
+
+* 当前优先事项和活跃工作
+* 目标角色、行业、地区或生态圈
+* 平台选择：X、LinkedIn 或两者
+* 不可触碰名单
+* 模式：`light-pass`、`default` 或 `aggressive`
+
+如果用户未指定模式，则使用 `default`。
+
+## 工具要求
+
+### 首选
+
+* `x-api` 用于 X 图谱检查与近期活动
+* `lead-intelligence` 用于目标发现与温暖路径排序
+* `social-graph-ranker` 当用户希望独立于更广泛的线索流程评估桥梁价值时
+* Exa / 深度研究用于人物与公司信息丰富
+* `brand-voice` 在起草外联内容之前
+
+### 备选
+
+* 浏览器控制用于 LinkedIn 分析与起草
+* 当 API 覆盖受限时，使用浏览器控制处理 X
+* 当电子邮件是合适渠道时，通过桌面自动化起草 Apple Mail 或 Mail.app 邮件
+
+## 安全默认设置
+
+* 默认优先审核，绝不盲目自动清理
+* X：仅清理用户关注的对象，绝不清理粉丝
+* LinkedIn：将一级连接的移除视为手动优先审核
+* 不自动发送私信、邀请或电子邮件
+* 在任何执行步骤之前，输出排序后的行动计划与草稿
+
+## 平台规则
+
+### X
+
+* 互关比单向关注更稳固
+* 未回关者可更积极清理
+* 长期不活跃或已消失的账号应快速浮现
+* 互动、信号质量与桥梁价值比原始粉丝数更重要
+
+### LinkedIn
+
+* 若用户实际拥有 LinkedIn API 访问权限，优先使用 API
+* 当缺少 API 访问权限时，必须使用浏览器工作流程
+* 区分对外关注与已接受的一级连接
+* 对外关注可更自由地清理
+* 已接受的一级连接应默认审核，而非自动移除
+
+## 模式
+
+### `light-pass`
+
+* 仅清理高置信度、低价值的单向关注
+* 其余内容供审核
+* 生成少量添加/关注列表
+
+### `default`
+
+* 平衡的清理队列
+* 平衡的保留列表
+* 排序的添加/关注队列
+* 在有用时起草温暖介绍或直接外联
+
+### `aggressive`
+
+* 更大的清理队列
+* 对过时未回关者的容忍度更低
+* 执行前仍需审核把关
+
+## 评分模型
+
+使用以下正面信号：
+
+* 互惠性
+* 近期活跃度
+* 与当前优先事项的契合度
+* 网络桥梁价值
+* 角色相关性
+* 真实互动历史
+* 近期存在感与响应度
+
+使用以下负面信号：
+
+* 已消失或废弃的账号
+* 过时的单向关注
+* 偏离优先主题的集群
+* 低价值噪音
+* 反复无响应
+* 存在许多更优替代者时仍未回关
+
+互关和真实的温暖路径桥梁应比单向关注受到更宽松的惩罚。
+
+## 工作流程
+
+1. 获取优先事项、不可触碰约束和选定平台。
+2. 拉取当前关注/连接清单。
+3. 对清理候选者进行评分并附上明确理由。
+4. 对保留候选者进行评分并附上明确理由。
+5. 使用 `lead-intelligence` 结合研究信息对扩展候选者进行排序。
+6. 匹配正确渠道：
+   * X DM 用于温暖、快速的社交接触点
+   * LinkedIn 消息用于职业图谱邻近关系
+   * Apple Mail 草稿用于需要更多上下文的介绍或外联
+7. 在起草消息前运行 `brand-voice`。
+8. 在任何执行步骤前返回审核包。
+
+## 审核包格式
+
+```text
+连接优化器报告
+============================
+
+模式：
+平台：
+优先级设置：
+
+修剪队列
+- 账号/个人资料
+  原因：
+  置信度：
+  操作：
+
+审查队列
+- 账号/个人资料
+  原因：
+  风险：
+
+保留/保护
+- 账号/个人资料
+  桥梁价值：
+
+添加/关注目标
+- 联系人
+  当前原因：
+  预热路径：
+  首选渠道：
+
+草稿
+- X 私信：
+- LinkedIn：
+- Apple 邮件：
+```
+
+## 外联规则
+
+* 默认邮件路径是创建 Apple Mail / Mail.app 草稿。
+* 不自动发送。
+* 根据温暖度、相关性和上下文深度选择渠道。
+* 当电子邮件或不进行外联是正确选择时，不要强制发送私信。
+* 草稿应听起来像用户本人，而非自动化的销售文案。
+
+## 相关技能
+
+* `brand-voice` 用于可复用的语音档案
+* `social-graph-ranker` 用于独立的桥梁评分与温暖路径计算
+* `lead-intelligence` 用于加权目标与温暖路径发现
+* `x-api` 用于 X 图谱访问、起草和可选执行流程
+* `content-engine` 当用户还希望围绕网络变动发布公开内容时

docs/zh-CN/skills/council/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: council
+description: 召集四方会议处理模糊决策、权衡取舍及继续/停止决策。当存在多个有效路径且需要在选择前进行结构化异议时使用。
+origin: ECC
+---
+
+# 顾问团
+
+在模糊决策时召集四位顾问：
+
+* 上下文中的Claude声音
+* 怀疑论者子代理
+* 实用主义者子代理
+* 批评者子代理
+
+这适用于**模糊性下的决策制定**，而非代码审查、实施规划或架构设计。
+
+## 何时使用
+
+在以下情况使用顾问团：
+
+* 决策存在多个可行路径且无明显优胜者
+* 需要明确权衡利弊
+* 用户要求第二意见、异议或多角度分析
+* 存在对话锚定效应的真实风险
+* 通过对抗性挑战能优化"执行/放弃"决策
+
+示例：
+
+* 单一仓库 vs 多仓库
+* 立即发布 vs 打磨后发布
+* 功能开关 vs 全面上线
+* 简化范围 vs 保持战略广度
+
+## 何时不使用
+
+| 不应使用顾问团的情况 | 应使用 |
+| --- | --- |
+| 验证输出是否正确 | `santa-method` |
+| 将功能拆解为实施步骤 | `planner` |
+| 设计系统架构 | `architect` |
+| 审查代码中的错误或安全漏洞 | `code-reviewer` 或 `santa-method` |
+| 直接的事实性问题 | 直接回答 |
+| 明确的执行任务 | 直接执行 |
+
+## 角色
+
+| 声音 | 视角 |
+| --- | --- |
+| 架构师 | 正确性、可维护性、长期影响 |
+| 怀疑论者 | 质疑前提、简化、打破假设 |
+| 实用主义者 | 交付速度、用户影响、运营现实 |
+| 批评者 | 边缘情况、下行风险、失败模式 |
+
+三个外部声音应作为全新子代理启动，**仅提供问题和相关上下文**，而非完整对话历史。这是反锚定机制。
+
+## 工作流程
+
+### 1. 提取真实问题
+
+将决策简化为一个明确提示：
+
+* 我们在决定什么？
+* 哪些约束条件重要？
+* 什么算成功？
+
+如果问题模糊，在召集顾问团前先提出一个澄清性问题。
+
+### 2. 仅收集必要上下文
+
+如果决策与代码库相关：
+
+* 收集相关文件、代码片段、问题描述或指标
+* 保持简洁
+* 仅包含决策所需的上下文
+
+如果决策是战略/通用性的：
+
+* 除非能实质性改变答案，否则跳过仓库代码片段
+
+### 3. 首先形成架构师立场
+
+在阅读其他声音之前，写下：
+
+* 你的初始立场
+* 支持该立场的三个最强理由
+* 首选路径的主要风险
+
+先完成此步骤，以确保综合意见不会简单镜像外部声音。
+
+### 4. 并行启动三个独立声音
+
+每个子代理获得：
+
+* 决策问题
+* 必要的简洁上下文
+* 严格角色定义
+* 无多余对话历史
+
+提示模板：
+
+```text
+你是四声部决策委员会中的[角色]。
+
+问题：
+[决策问题]
+
+背景：
+[仅包含相关片段或约束条件]
+
+回复格式：
+1. 立场 — 1-2句话
+2. 理由 — 3个简洁要点
+3. 风险 — 你建议中最大的风险
+4. 意外点 — 其他声部可能忽略的一个方面
+
+直接明了，不要含糊。控制在300字以内。
+```
+
+角色重点：
+
+* 怀疑论者：挑战框架、质疑假设、提出最简单的可信替代方案
+* 实用主义者：优化速度、简单性和实际执行
+* 批评者：揭示下行风险、边缘情况以及计划可能失败的原因
+
+### 5. 通过偏见护栏进行综合
+
+你既是参与者也是综合者，因此需遵循以下规则：
+
+* 不得无故驳回外部观点，需说明理由
+* 若外部声音改变了你的建议，需明确说明
+* 始终包含最强烈的异议，即使你最终拒绝它
+* 若两个声音一致反对你的初始立场，将其视为真实信号
+* 在最终裁决前保持原始立场可见
+
+### 6. 呈现简洁裁决
+
+使用以下输出格式：
+
+```markdown
+## 委员会：[简短决策标题]
+
+**架构师：** [1-2句立场陈述]
+[1行理由说明]
+
+**怀疑论者：** [1-2句立场陈述]
+[1行理由说明]
+
+**实用主义者：** [1-2句立场陈述]
+[1行理由说明]
+
+**批评者：** [1-2句立场陈述]
+[1行理由说明]
+
+### 裁决
+- **共识点：** [各方达成一致之处]
+- **最大分歧：** [最重要的争议点]
+- **前提检验：** [怀疑论者是否质疑了问题本身？]
+- **建议方案：** [综合后的行动路径]
+```
+
+确保在手机屏幕上可快速浏览。
+
+## 持久化规则
+
+**不要**从此技能向 `~/.claude/notes` 或其他隐藏路径写入临时笔记。
+
+若顾问团实质性改变了建议：
+
+* 使用 `knowledge-ops` 将经验教训存储在正确的持久化位置
+* 或使用 `/save-session`（若结果属于会话记忆）
+* 或直接更新相关的GitHub/Linear问题（若决策改变了当前执行事实）
+
+仅在决策改变实际内容时进行持久化。
+
+## 多轮跟进
+
+默认为一轮。
+
+若用户要求另一轮：
+
+* 保持新问题聚焦
+* 仅在必要时包含上一轮裁决
+* 尽可能保持怀疑论者的"干净"状态以保留反锚定价值
+
+## 反模式
+
+* 将顾问团用于代码审查
+* 在任务仅为实施工作时使用顾问团
+* 向子代理提供完整对话记录
+* 在最终裁决中隐藏分歧
+* 无论重要性如何都持久化每个决策
+
+## 相关技能
+
+* `santa-method` — 对抗性验证
+* `knowledge-ops` — 正确持久化重要决策变更
+* `search-first` — 在顾问团前收集外部参考资料（如需要）
+* `architecture-decision-records` — 当决策成为长期系统策略时正式化结果
+
+## 示例
+
+问题：
+
+```text
+我们现在应该以 alpha 版本发布 ECC 2.0，还是等到控制平面 UI 更完善后再发布？
+```
+
+可能的顾问团形态：
+
+* 架构师推动结构完整性并避免混乱的界面
+* 怀疑论者质疑UI是否真的是瓶颈因素
+* 实用主义者询问在不损害信任的前提下现在可以交付什么
+* 批评者关注支持负担、期望债务和上线混乱
+
+价值不在于达成一致。价值在于在选择前让分歧清晰可见。

docs/zh-CN/skills/csharp-testing/SKILL.md

@@ -0,0 +1,321 @@
+---
+name: csharp-testing
+description: 使用 xUnit、FluentAssertions、模拟、集成测试和测试组织最佳实践的 C# 和 .NET 测试模式。
+origin: ECC
+---
+
+# C# 测试模式
+
+使用 xUnit、FluentAssertions 和现代测试实践为 .NET 应用程序提供的全面测试模式。
+
+## 何时使用
+
+* 为 C# 代码编写新测试
+* 审查测试质量和覆盖率
+* 为 .NET 项目搭建测试基础设施
+* 调试不稳定或缓慢的测试
+
+## 测试框架栈
+
+| 工具 | 用途 |
+|---|---|
+| **xUnit** | 测试框架（.NET 首选） |
+| **FluentAssertions** | 可读的断言语法 |
+| **NSubstitute** 或 **Moq** | 模拟依赖项 |
+| **Testcontainers** | 集成测试中的真实基础设施 |
+| **WebApplicationFactory** | ASP.NET Core 集成测试 |
+| **Bogus** | 生成逼真的测试数据 |
+
+## 单元测试结构
+
+### 安排-操作-断言
+
+```csharp
+public sealed class OrderServiceTests
+{
+    private readonly IOrderRepository _repository = Substitute.For<IOrderRepository>();
+    private readonly ILogger<OrderService> _logger = Substitute.For<ILogger<OrderService>>();
+    private readonly OrderService _sut;
+
+    public OrderServiceTests()
+    {
+        _sut = new OrderService(_repository, _logger);
+    }
+
+    [Fact]
+    public async Task PlaceOrderAsync_ReturnsSuccess_WhenRequestIsValid()
+    {
+        // Arrange
+        var request = new CreateOrderRequest
+        {
+            CustomerId = "cust-123",
+            Items = [new OrderItem("SKU-001", 2, 29.99m)]
+        };
+
+        // Act
+        var result = await _sut.PlaceOrderAsync(request, CancellationToken.None);
+
+        // Assert
+        result.IsSuccess.Should().BeTrue();
+        result.Value.Should().NotBeNull();
+        result.Value!.CustomerId.Should().Be("cust-123");
+    }
+
+    [Fact]
+    public async Task PlaceOrderAsync_ReturnsFailure_WhenNoItems()
+    {
+        // Arrange
+        var request = new CreateOrderRequest
+        {
+            CustomerId = "cust-123",
+            Items = []
+        };
+
+        // Act
+        var result = await _sut.PlaceOrderAsync(request, CancellationToken.None);
+
+        // Assert
+        result.IsSuccess.Should().BeFalse();
+        result.Error.Should().Contain("at least one item");
+    }
+}
+```
+
+### 使用 Theory 的参数化测试
+
+```csharp
+[Theory]
+[InlineData("", false)]
+[InlineData("a", false)]
+[InlineData("ab@c.d", false)]
+[InlineData("user@example.com", true)]
+[InlineData("user+tag@example.co.uk", true)]
+public void IsValidEmail_ReturnsExpected(string email, bool expected)
+{
+    EmailValidator.IsValid(email).Should().Be(expected);
+}
+
+[Theory]
+[MemberData(nameof(InvalidOrderCases))]
+public async Task PlaceOrderAsync_RejectsInvalidOrders(CreateOrderRequest request, string expectedError)
+{
+    var result = await _sut.PlaceOrderAsync(request, CancellationToken.None);
+
+    result.IsSuccess.Should().BeFalse();
+    result.Error.Should().Contain(expectedError);
+}
+
+public static TheoryData<CreateOrderRequest, string> InvalidOrderCases => new()
+{
+    { new() { CustomerId = "", Items = [ValidItem()] }, "CustomerId" },
+    { new() { CustomerId = "c1", Items = [] }, "at least one item" },
+    { new() { CustomerId = "c1", Items = [new("", 1, 10m)] }, "SKU" },
+};
+```
+
+## 使用 NSubstitute 进行模拟
+
+```csharp
+[Fact]
+public async Task GetOrderAsync_ReturnsNull_WhenNotFound()
+{
+    // Arrange
+    var orderId = Guid.NewGuid();
+    _repository.FindByIdAsync(orderId, Arg.Any<CancellationToken>())
+        .Returns((Order?)null);
+
+    // Act
+    var result = await _sut.GetOrderAsync(orderId, CancellationToken.None);
+
+    // Assert
+    result.Should().BeNull();
+}
+
+[Fact]
+public async Task PlaceOrderAsync_PersistsOrder()
+{
+    // Arrange
+    var request = ValidOrderRequest();
+
+    // Act
+    await _sut.PlaceOrderAsync(request, CancellationToken.None);
+
+    // Assert — verify the repository was called
+    await _repository.Received(1).AddAsync(
+        Arg.Is<Order>(o => o.CustomerId == request.CustomerId),
+        Arg.Any<CancellationToken>());
+}
+```
+
+## ASP.NET Core 集成测试
+
+### WebApplicationFactory 设置
+
+```csharp
+public sealed class OrderApiTests : IClassFixture<WebApplicationFactory<Program>>
+{
+    private readonly HttpClient _client;
+
+    public OrderApiTests(WebApplicationFactory<Program> factory)
+    {
+        _client = factory.WithWebHostBuilder(builder =>
+        {
+            builder.ConfigureServices(services =>
+            {
+                // Replace real DB with in-memory for tests
+                services.RemoveAll<DbContextOptions<AppDbContext>>();
+                services.AddDbContext<AppDbContext>(options =>
+                    options.UseInMemoryDatabase("TestDb"));
+            });
+        }).CreateClient();
+    }
+
+    [Fact]
+    public async Task GetOrder_Returns404_WhenNotFound()
+    {
+        var response = await _client.GetAsync($"/api/orders/{Guid.NewGuid()}");
+
+        response.StatusCode.Should().Be(HttpStatusCode.NotFound);
+    }
+
+    [Fact]
+    public async Task CreateOrder_Returns201_WithValidRequest()
+    {
+        var request = new CreateOrderRequest
+        {
+            CustomerId = "cust-1",
+            Items = [new("SKU-001", 1, 19.99m)]
+        };
+
+        var response = await _client.PostAsJsonAsync("/api/orders", request);
+
+        response.StatusCode.Should().Be(HttpStatusCode.Created);
+        response.Headers.Location.Should().NotBeNull();
+    }
+}
+```
+
+### 使用 Testcontainers 进行测试
+
+```csharp
+public sealed class PostgresOrderRepositoryTests : IAsyncLifetime
+{
+    private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder()
+        .WithImage("postgres:16-alpine")
+        .Build();
+
+    private AppDbContext _db = null!;
+
+    public async Task InitializeAsync()
+    {
+        await _postgres.StartAsync();
+        var options = new DbContextOptionsBuilder<AppDbContext>()
+            .UseNpgsql(_postgres.GetConnectionString())
+            .Options;
+        _db = new AppDbContext(options);
+        await _db.Database.MigrateAsync();
+    }
+
+    public async Task DisposeAsync()
+    {
+        await _db.DisposeAsync();
+        await _postgres.DisposeAsync();
+    }
+
+    [Fact]
+    public async Task AddAsync_PersistsOrder()
+    {
+        var repo = new SqlOrderRepository(_db);
+        var order = Order.Create("cust-1", [new OrderItem("SKU-001", 2, 10m)]);
+
+        await repo.AddAsync(order, CancellationToken.None);
+
+        var found = await repo.FindByIdAsync(order.Id, CancellationToken.None);
+        found.Should().NotBeNull();
+        found!.Items.Should().HaveCount(1);
+    }
+}
+```
+
+## 测试组织
+
+```
+tests/
+  MyApp.UnitTests/
+    Services/
+      OrderServiceTests.cs
+      PaymentServiceTests.cs
+    Validators/
+      EmailValidatorTests.cs
+  MyApp.IntegrationTests/
+    Api/
+      OrderApiTests.cs
+    Repositories/
+      OrderRepositoryTests.cs
+  MyApp.TestHelpers/
+    Builders/
+      OrderBuilder.cs
+    Fixtures/
+      DatabaseFixture.cs
+```
+
+## 测试数据构建器
+
+```csharp
+public sealed class OrderBuilder
+{
+    private string _customerId = "cust-default";
+    private readonly List<OrderItem> _items = [new("SKU-001", 1, 10m)];
+
+    public OrderBuilder WithCustomer(string customerId)
+    {
+        _customerId = customerId;
+        return this;
+    }
+
+    public OrderBuilder WithItem(string sku, int quantity, decimal price)
+    {
+        _items.Add(new OrderItem(sku, quantity, price));
+        return this;
+    }
+
+    public Order Build() => Order.Create(_customerId, _items);
+}
+
+// Usage in tests
+var order = new OrderBuilder()
+    .WithCustomer("cust-vip")
+    .WithItem("SKU-PREMIUM", 3, 99.99m)
+    .Build();
+```
+
+## 常见反模式
+
+| 反模式 | 修复方法 |
+|---|---|
+| 测试实现细节 | 测试行为和结果 |
+| 共享的可变测试状态 | 每个测试使用新实例（xUnit 通过构造函数实现） |
+| 在异步测试中使用 `Thread.Sleep` | 使用带超时的 `Task.Delay` 或轮询辅助方法 |
+| 对 `ToString()` 输出进行断言 | 对类型化属性进行断言 |
+| 每个测试一个巨型断言 | 每个测试一个逻辑断言 |
+| 测试名称描述实现 | 按行为命名：`Method_ExpectedResult_WhenCondition` |
+| 忽略 `CancellationToken` | 始终传递并验证取消 |
+
+## 运行测试
+
+```bash
+# Run all tests
+dotnet test
+
+# Run with coverage
+dotnet test --collect:"XPlat Code Coverage"
+
+# Run specific project
+dotnet test tests/MyApp.UnitTests/
+
+# Filter by test name
+dotnet test --filter "FullyQualifiedName~OrderService"
+
+# Watch mode during development
+dotnet watch test --project tests/MyApp.UnitTests/
+```

docs/zh-CN/skills/customer-billing-ops/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: customer-billing-ops
+description: 使用 Stripe 等连接计费工具操作客户计费工作流，例如订阅、退款、流失分类、计费门户恢复和计划分析。当用户需要帮助客户、检查订阅状态或管理影响收入的计费操作时使用。
+origin: ECC
+---
+
+# 客户计费运营
+
+此技能用于真实的客户运营操作，而非通用的支付 API 设计。
+
+目标是帮助运营人员回答：客户是谁、发生了什么、最安全的修复方案是什么、以及后续应发送什么跟进内容。
+
+## 使用场景
+
+* 客户反馈计费异常、要求退款或无法取消订阅
+* 调查重复订阅、意外扣费、续费失败或流失风险
+* 审查套餐组合、活跃订阅、年付与月付转换、或团队席位混淆
+* 创建或验证计费门户流程
+* 审计涉及订阅、发票、退款或支付方式的支持投诉
+
+## 首选工具界面
+
+* 优先使用 Stripe 等关联计费工具
+* 仅将邮件、GitHub 或问题追踪器作为辅助证据
+* 当平台已提供必要控制功能时，优先使用托管计费/客户门户而非自定义账户管理代码
+
+## 安全边界
+
+* 切勿在回复中暴露密钥、完整卡号或不必要的客户个人身份信息
+* 不要盲目退款；首先对问题进行归类
+* 区分以下情况：
+  * 意外重复购买
+  * 有意的多席位或团队购买
+  * 产品故障/价值未兑现
+  * 结账失败或不完整
+  * 因缺少自助控制功能导致的取消
+* 对于年付方案、团队方案及按比例计费状态，在操作前需核实合同结构
+
+## 工作流程
+
+### 1. 清晰识别客户身份
+
+从最可靠的标识符入手：
+
+* 客户邮箱
+* Stripe 客户 ID
+* 订阅 ID
+* 发票 ID
+* 已知可关联到计费的 GitHub 用户名或支持邮箱
+
+返回简洁的身份摘要：
+
+* 客户
+* 活跃订阅
+* 已取消订阅
+* 发票
+* 明显异常（如重复的活跃订阅）
+
+### 2. 对问题进行分类
+
+在操作前将案例归入一个类别：
+
+| 案例 | 典型操作 |
+|------|----------------|
+| 重复的个人订阅 | 取消多余订阅，考虑退款 |
+| 真实的多席位/团队意图 | 保留席位，澄清计费模式 |
+| 支付失败/结账不完整 | 通过门户恢复或更新支付方式 |
+| 缺少自助控制功能 | 提供门户、取消路径或发票访问权限 |
+| 产品故障或信任破裂 | 退款、道歉、记录产品问题 |
+
+### 3. 优先采取最安全的可逆操作
+
+推荐顺序：
+
+1. 恢复自助管理功能
+2. 修复重复或异常的计费状态
+3. 仅对受影响的扣费或重复项进行退款
+4. 记录原因
+5. 发送简短的客户跟进信息
+
+若修复需要产品工作，需区分：
+
+* 当前客户补救措施
+* 待办事项中的产品缺陷/工作流缺口
+
+### 4. 检查运营端产品缺口
+
+若客户痛点源于缺少运营界面，需明确指出。常见示例：
+
+* 无计费门户
+* 无用量/速率限制可见性
+* 无套餐/席位说明
+* 无取消流程
+* 无重复订阅防护
+
+将这些视为 ECC 或网站跟进事项，而非单纯的支持事件。
+
+### 5. 生成运营交接文档
+
+最终需包含：
+
+* 客户状态摘要
+* 已执行操作
+* 收入影响
+* 待发送的跟进文本
+* 需创建的产品或待办事项
+
+## 输出格式
+
+使用以下结构：
+
+```text
+客户
+- 姓名 / 邮箱
+- 相关账户标识
+
+计费状态
+- 活跃订阅
+- 发票或续费状态
+- 异常情况
+
+决策
+- 问题分类
+- 为何此操作正确
+
+已执行操作
+- 退款 / 取消 / 门户 / 无操作
+
+后续跟进
+- 简短客户消息
+
+产品缺口
+- 产品或网站中应修复的内容
+```
+
+## 优质建议示例
+
+* "正确的修复方案是计费门户，而非自定义仪表盘"
+* "这看起来是重复的个人结账，而非真实的团队席位购买"
+* "退还一笔重复扣费，保留剩余活跃订阅，后续如有需要再将客户转为组织计费"

docs/zh-CN/skills/dart-flutter-patterns/SKILL.md

@@ -0,0 +1,565 @@
+---
+name: dart-flutter-patterns
+description: 生产就绪的 Dart 和 Flutter 模式，涵盖空安全、不可变状态、异步组合、Widget 架构、流行的状态管理框架（BLoC、Riverpod、Provider）、GoRouter 导航、Dio 网络请求、Freezed 代码生成和整洁架构。
+origin: ECC
+---
+
+# Dart/Flutter 模式
+
+## 使用场景
+
+在以下情况使用此技能：
+
+* 开始新的 Flutter 功能，需要状态管理、导航或数据访问的惯用模式
+* 审查或编写 Dart 代码，需要空安全、密封类型或异步组合的指导
+* 搭建新的 Flutter 项目，在 BLoC、Riverpod 或 Provider 之间做选择
+* 实现安全的 HTTP 客户端、WebView 集成或本地存储
+* 为 Flutter 组件、Cubit 或 Riverpod 提供者编写测试
+* 使用认证守卫配置 GoRouter
+
+## 工作原理
+
+此技能提供按关注点组织的、可直接复制粘贴的 Dart/Flutter 代码模式：
+
+1. **空安全** — 避免 `!`，优先使用 `?.`/`??`/模式匹配
+2. **不可变状态** — 密封类、`freezed`、`copyWith`
+3. **异步组合** — 并发 `Future.wait`、`BuildContext` 后安全使用 `await`
+4. **组件架构** — 提取为类（而非方法）、`const` 传播、作用域重建
+5. **状态管理** — BLoC/Cubit 事件、Riverpod 通知器和派生提供者
+6. **导航** — 通过 `refreshListenable` 实现带响应式认证守卫的 GoRouter
+7. **网络请求** — 带拦截器的 Dio、带一次性重试守卫的令牌刷新
+8. **错误处理** — 全局捕获、`ErrorWidget.builder`、Crashlytics 集成
+9. **测试** — 单元测试（BLoC 测试）、组件测试（ProviderScope 覆盖）、使用假对象而非模拟对象
+
+## 示例
+
+```dart
+// Sealed state — prevents impossible states
+sealed class AsyncState<T> {}
+final class Loading<T> extends AsyncState<T> {}
+final class Success<T> extends AsyncState<T> { final T data; const Success(this.data); }
+final class Failure<T> extends AsyncState<T> { final Object error; const Failure(this.error); }
+
+// GoRouter with reactive auth redirect
+final router = GoRouter(
+  refreshListenable: GoRouterRefreshStream(authCubit.stream),
+  redirect: (context, state) {
+    final authed = context.read<AuthCubit>().state is AuthAuthenticated;
+    if (!authed && !state.matchedLocation.startsWith('/login')) return '/login';
+    return null;
+  },
+  routes: [...],
+);
+
+// Riverpod derived provider with safe firstWhereOrNull
+@riverpod
+double cartTotal(Ref ref) {
+  final cart = ref.watch(cartNotifierProvider);
+  final products = ref.watch(productsProvider).valueOrNull ?? [];
+  return cart.fold(0.0, (total, item) {
+    final product = products.firstWhereOrNull((p) => p.id == item.productId);
+    return total + (product?.price ?? 0) * item.quantity;
+  });
+}
+```
+
+***
+
+适用于 Dart 和 Flutter 应用程序的实用、生产就绪模式。尽可能保持库无关性，并明确覆盖最常见的生态系统包。
+
+***
+
+## 1. 空安全基础
+
+### 优先使用模式而非感叹号操作符
+
+```dart
+// BAD — crashes at runtime if null
+final name = user!.name;
+
+// GOOD — provide fallback
+final name = user?.name ?? 'Unknown';
+
+// GOOD — Dart 3 pattern matching (preferred for complex cases)
+final display = switch (user) {
+  User(:final name, :final email) => '$name <$email>',
+  null => 'Guest',
+};
+
+// GOOD — guard early return
+String getUserName(User? user) {
+  if (user == null) return 'Unknown';
+  return user.name; // promoted to non-null after check
+}
+```
+
+### 避免过度使用 `late`
+
+```dart
+// BAD — defers null error to runtime
+late String userId;
+
+// GOOD — nullable with explicit initialization
+String? userId;
+
+// OK — use late only when initialization is guaranteed before first access
+// (e.g., in initState() before any widget interaction)
+late final AnimationController _controller;
+
+@override
+void initState() {
+  super.initState();
+  _controller = AnimationController(vsync: this, duration: const Duration(milliseconds: 300));
+}
+```
+
+***
+
+## 2. 不可变状态
+
+### 状态层次结构的密封类
+
+```dart
+sealed class UserState {}
+
+final class UserInitial extends UserState {}
+
+final class UserLoading extends UserState {}
+
+final class UserLoaded extends UserState {
+  const UserLoaded(this.user);
+  final User user;
+}
+
+final class UserError extends UserState {
+  const UserError(this.message);
+  final String message;
+}
+
+// Exhaustive switch — compiler enforces all branches
+Widget buildFrom(UserState state) => switch (state) {
+  UserInitial() => const SizedBox.shrink(),
+  UserLoading() => const CircularProgressIndicator(),
+  UserLoaded(:final user) => UserCard(user: user),
+  UserError(:final message) => ErrorText(message),
+};
+```
+
+### 使用 Freezed 实现无模板代码的不可变性
+
+```dart
+import 'package:freezed_annotation/freezed_annotation.dart';
+
+part 'user.freezed.dart';
+part 'user.g.dart';
+
+@freezed
+class User with _$User {
+  const factory User({
+    required String id,
+    required String name,
+    required String email,
+    @Default(false) bool isAdmin,
+  }) = _User;
+
+  factory User.fromJson(Map<String, dynamic> json) => _$UserFromJson(json);
+}
+
+// Usage
+final user = User(id: '1', name: 'Alice', email: 'alice@example.com');
+final updated = user.copyWith(name: 'Alice Smith'); // immutable update
+final json = user.toJson();
+final fromJson = User.fromJson(json);
+```
+
+***
+
+## 3. 异步组合
+
+### 使用 Future.wait 的结构化并发
+
+```dart
+Future<DashboardData> loadDashboard(UserRepository users, OrderRepository orders) async {
+  // Run concurrently — don't await sequentially
+  final (userList, orderList) = await (
+    users.getAll(),
+    orders.getRecent(),
+  ).wait; // Dart 3 record destructuring + Future.wait extension
+
+  return DashboardData(users: userList, orders: orderList);
+}
+```
+
+### 流模式
+
+```dart
+// Repository exposes reactive streams for live data
+Stream<List<Item>> watchCartItems() => _db
+    .watchTable('cart_items')
+    .map((rows) => rows.map(Item.fromRow).toList());
+
+// In widget layer — declarative, no manual subscription
+StreamBuilder<List<Item>>(
+  stream: cartRepository.watchCartItems(),
+  builder: (context, snapshot) => switch (snapshot) {
+    AsyncSnapshot(connectionState: ConnectionState.waiting) =>
+        const CircularProgressIndicator(),
+    AsyncSnapshot(:final error?) => ErrorWidget(error.toString()),
+    AsyncSnapshot(:final data?) => CartList(items: data),
+    _ => const SizedBox.shrink(),
+  },
+)
+```
+
+### Await 后的 BuildContext
+
+```dart
+// CRITICAL — always check mounted after any await in StatefulWidget
+Future<void> _handleSubmit() async {
+  setState(() => _isLoading = true);
+  try {
+    await authService.login(_email, _password);
+    if (!mounted) return; // ← guard before using context
+    context.go('/home');
+  } on AuthException catch (e) {
+    if (!mounted) return;
+    ScaffoldMessenger.of(context).showSnackBar(SnackBar(content: Text(e.message)));
+  } finally {
+    if (mounted) setState(() => _isLoading = false);
+  }
+}
+```
+
+***
+
+## 4. 组件架构
+
+### 提取为类，而非方法
+
+```dart
+// BAD — private method returning widget, prevents optimization
+Widget _buildHeader() {
+  return Container(
+    padding: const EdgeInsets.all(16),
+    child: Text(title, style: Theme.of(context).textTheme.headlineMedium),
+  );
+}
+
+// GOOD — separate widget class, enables const, element reuse
+class _PageHeader extends StatelessWidget {
+  const _PageHeader(this.title);
+  final String title;
+
+  @override
+  Widget build(BuildContext context) {
+    return Container(
+      padding: const EdgeInsets.all(16),
+      child: Text(title, style: Theme.of(context).textTheme.headlineMedium),
+    );
+  }
+}
+```
+
+### const 传播
+
+```dart
+// BAD — new instances every rebuild
+child: Padding(
+  padding: EdgeInsets.all(16.0),       // not const
+  child: Icon(Icons.home, size: 24.0), // not const
+)
+
+// GOOD — const stops rebuild propagation
+child: const Padding(
+  padding: EdgeInsets.all(16.0),
+  child: Icon(Icons.home, size: 24.0),
+)
+```
+
+### 作用域重建
+
+```dart
+// BAD — entire page rebuilds on every counter change
+class CounterPage extends ConsumerWidget {
+  @override
+  Widget build(BuildContext context, WidgetRef ref) {
+    final count = ref.watch(counterProvider); // rebuilds everything
+    return Scaffold(
+      body: Column(children: [
+        const ExpensiveHeader(), // unnecessarily rebuilt
+        Text('$count'),
+        const ExpensiveFooter(), // unnecessarily rebuilt
+      ]),
+    );
+  }
+}
+
+// GOOD — isolate the rebuilding part
+class CounterPage extends StatelessWidget {
+  const CounterPage({super.key});
+
+  @override
+  Widget build(BuildContext context) {
+    return const Scaffold(
+      body: Column(children: [
+        ExpensiveHeader(),        // never rebuilt (const)
+        _CounterDisplay(),        // only this rebuilds
+        ExpensiveFooter(),        // never rebuilt (const)
+      ]),
+    );
+  }
+}
+
+class _CounterDisplay extends ConsumerWidget {
+  const _CounterDisplay();
+
+  @override
+  Widget build(BuildContext context, WidgetRef ref) {
+    final count = ref.watch(counterProvider);
+    return Text('$count');
+  }
+}
+```
+
+***
+
+## 5. 状态管理：BLoC/Cubit
+
+```dart
+// Cubit — synchronous or simple async state
+class AuthCubit extends Cubit<AuthState> {
+  AuthCubit(this._authService) : super(const AuthState.initial());
+  final AuthService _authService;
+
+  Future<void> login(String email, String password) async {
+    emit(const AuthState.loading());
+    try {
+      final user = await _authService.login(email, password);
+      emit(AuthState.authenticated(user));
+    } on AuthException catch (e) {
+      emit(AuthState.error(e.message));
+    }
+  }
+
+  void logout() {
+    _authService.logout();
+    emit(const AuthState.initial());
+  }
+}
+
+// In widget
+BlocBuilder<AuthCubit, AuthState>(
+  builder: (context, state) => switch (state) {
+    AuthInitial() => const LoginForm(),
+    AuthLoading() => const CircularProgressIndicator(),
+    AuthAuthenticated(:final user) => HomePage(user: user),
+    AuthError(:final message) => ErrorView(message: message),
+  },
+)
+```
+
+***
+
+## 6. 状态管理：Riverpod
+
+```dart
+// Auto-dispose async provider
+@riverpod
+Future<List<Product>> products(Ref ref) async {
+  final repo = ref.watch(productRepositoryProvider);
+  return repo.getAll();
+}
+
+// Notifier with complex mutations
+@riverpod
+class CartNotifier extends _$CartNotifier {
+  @override
+  List<CartItem> build() => [];
+
+  void add(Product product) {
+    final existing = state.where((i) => i.productId == product.id).firstOrNull;
+    if (existing != null) {
+      state = [
+        for (final item in state)
+          if (item.productId == product.id) item.copyWith(quantity: item.quantity + 1)
+          else item,
+      ];
+    } else {
+      state = [...state, CartItem(productId: product.id, quantity: 1)];
+    }
+  }
+
+  void remove(String productId) =>
+      state = state.where((i) => i.productId != productId).toList();
+
+  void clear() => state = [];
+}
+
+// Derived provider (selector pattern)
+@riverpod
+int cartCount(Ref ref) => ref.watch(cartNotifierProvider).length;
+
+@riverpod
+double cartTotal(Ref ref) {
+  final cart = ref.watch(cartNotifierProvider);
+  final products = ref.watch(productsProvider).valueOrNull ?? [];
+  return cart.fold(0.0, (total, item) {
+    // firstWhereOrNull (from collection package) avoids StateError when product is missing
+    final product = products.firstWhereOrNull((p) => p.id == item.productId);
+    return total + (product?.price ?? 0) * item.quantity;
+  });
+}
+```
+
+***
+
+## 7. 使用 GoRouter 的导航
+
+```dart
+final router = GoRouter(
+  initialLocation: '/',
+  // refreshListenable re-evaluates redirect whenever auth state changes
+  refreshListenable: GoRouterRefreshStream(authCubit.stream),
+  redirect: (context, state) {
+    final isLoggedIn = context.read<AuthCubit>().state is AuthAuthenticated;
+    final isGoingToLogin = state.matchedLocation == '/login';
+    if (!isLoggedIn && !isGoingToLogin) return '/login';
+    if (isLoggedIn && isGoingToLogin) return '/';
+    return null;
+  },
+  routes: [
+    GoRoute(path: '/login', builder: (_, __) => const LoginPage()),
+    ShellRoute(
+      builder: (context, state, child) => AppShell(child: child),
+      routes: [
+        GoRoute(path: '/', builder: (_, __) => const HomePage()),
+        GoRoute(
+          path: '/products/:id',
+          builder: (context, state) =>
+              ProductDetailPage(id: state.pathParameters['id']!),
+        ),
+      ],
+    ),
+  ],
+);
+```
+
+***
+
+## 8. 使用 Dio 的 HTTP 请求
+
+```dart
+final dio = Dio(BaseOptions(
+  baseUrl: const String.fromEnvironment('API_URL'),
+  connectTimeout: const Duration(seconds: 10),
+  receiveTimeout: const Duration(seconds: 30),
+  headers: {'Content-Type': 'application/json'},
+));
+
+// Add auth interceptor
+dio.interceptors.add(InterceptorsWrapper(
+  onRequest: (options, handler) async {
+    final token = await secureStorage.read(key: 'auth_token');
+    if (token != null) options.headers['Authorization'] = 'Bearer $token';
+    handler.next(options);
+  },
+  onError: (error, handler) async {
+    // Guard against infinite retry loops: only attempt refresh once per request
+    final isRetry = error.requestOptions.extra['_isRetry'] == true;
+    if (!isRetry && error.response?.statusCode == 401) {
+      final refreshed = await attemptTokenRefresh();
+      if (refreshed) {
+        error.requestOptions.extra['_isRetry'] = true;
+        return handler.resolve(await dio.fetch(error.requestOptions));
+      }
+    }
+    handler.next(error);
+  },
+));
+
+// Repository using Dio
+class UserApiDataSource {
+  const UserApiDataSource(this._dio);
+  final Dio _dio;
+
+  Future<User> getById(String id) async {
+    final response = await _dio.get<Map<String, dynamic>>('/users/$id');
+    return User.fromJson(response.data!);
+  }
+}
+```
+
+***
+
+## 9. 错误处理架构
+
+```dart
+// Global error capture — set up in main()
+void main() {
+  FlutterError.onError = (details) {
+    FlutterError.presentError(details);
+    crashlytics.recordFlutterFatalError(details);
+  };
+
+  PlatformDispatcher.instance.onError = (error, stack) {
+    crashlytics.recordError(error, stack, fatal: true);
+    return true;
+  };
+
+  runApp(const App());
+}
+
+// Custom ErrorWidget for production
+class App extends StatelessWidget {
+  @override
+  Widget build(BuildContext context) {
+    ErrorWidget.builder = (details) => ProductionErrorWidget(details);
+    return MaterialApp.router(routerConfig: router);
+  }
+}
+```
+
+***
+
+## 10. 测试快速参考
+
+```dart
+// Unit test — use case
+test('GetUserUseCase returns null for missing user', () async {
+  final repo = FakeUserRepository();
+  final useCase = GetUserUseCase(repo);
+  expect(await useCase('missing-id'), isNull);
+});
+
+// BLoC test
+blocTest<AuthCubit, AuthState>(
+  'emits loading then error on failed login',
+  build: () => AuthCubit(FakeAuthService(throwsOn: 'login')),
+  act: (cubit) => cubit.login('user@test.com', 'wrong'),
+  expect: () => [const AuthState.loading(), isA<AuthError>()],
+);
+
+// Widget test
+testWidgets('CartBadge shows item count', (tester) async {
+  await tester.pumpWidget(
+    ProviderScope(
+      overrides: [cartNotifierProvider.overrideWith(() => FakeCartNotifier(count: 3))],
+      child: const MaterialApp(home: CartBadge()),
+    ),
+  );
+  expect(find.text('3'), findsOneWidget);
+});
+```
+
+***
+
+## 参考
+
+* [Effective Dart: 设计](https://dart.dev/effective-dart/design)
+* [Flutter 性能最佳实践](https://docs.flutter.dev/perf/best-practices)
+* [Riverpod 文档](https://riverpod.dev/)
+* [BLoC 库](https://bloclibrary.dev/)
+* [GoRouter](https://pub.dev/packages/go_router)
+* [Freezed](https://pub.dev/packages/freezed)
+* 技能：`flutter-dart-code-review` — 全面审查清单
+* 规则：`rules/dart/` — 编码风格、模式、安全性、测试、钩子

docs/zh-CN/skills/dashboard-builder/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: dashboard-builder
+description: 为 Grafana、SigNoz 等平台构建能够回答实际运维人员问题的监控仪表板。适用于将指标转化为可用的仪表板，而非华而不实的展示板。
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# 仪表盘构建器
+
+当任务需要构建一个可供操作人员使用的仪表盘时使用此方案。
+
+目标不是"展示所有指标"，而是回答以下问题：
+
+* 系统健康吗？
+* 瓶颈在哪里？
+* 发生了什么变化？
+* 应该采取什么行动？
+
+## 使用场景
+
+* "构建一个Kafka监控仪表盘"
+* "为Elasticsearch创建一个Grafana仪表盘"
+* "为这个服务制作一个SigNoz仪表盘"
+* "将这个指标列表转化为真正的运维仪表盘"
+
+## 约束条件
+
+* 不要从视觉布局开始；要从操作人员的问题出发
+* 不要仅仅因为指标存在就包含所有可用指标
+* 不要在没有结构的情况下混合健康、吞吐量和资源面板
+* 不要发布没有标题、单位和合理阈值的面板
+
+## 工作流程
+
+### 1. 定义操作问题
+
+围绕以下方面组织：
+
+* 健康/可用性
+* 延迟/性能
+* 吞吐量/容量
+* 饱和度/资源
+* 服务特定风险
+
+### 2. 研究目标平台架构
+
+首先检查现有仪表盘：
+
+* JSON结构
+* 查询语言
+* 变量
+* 阈值样式
+* 分区布局
+
+### 3. 构建最小可用面板
+
+推荐结构：
+
+1. 概览
+2. 性能
+3. 资源
+4. 服务特定分区
+
+### 4. 剔除装饰性面板
+
+每个面板都应回答一个真实问题。如果不能，则移除。
+
+## 示例面板集
+
+### Elasticsearch
+
+* 集群健康
+* 分片分配
+* 搜索延迟
+* 索引速率
+* JVM堆/GC
+
+### Kafka
+
+* 代理数量
+* 副本不足的分区
+* 消息流入/流出
+* 消费者滞后
+* 磁盘和网络压力
+
+### API网关/入口
+
+* 请求速率
+* p50/p95/p99延迟
+* 错误率
+* 上游健康
+* 活跃连接数
+
+## 质量检查清单
+
+* \[ ] 有效的仪表盘JSON
+* \[ ] 清晰的分区分组
+* \[ ] 包含标题和单位
+* \[ ] 阈值/状态颜色有意义
+* \[ ] 存在常用过滤器的变量
+* \[ ] 默认时间范围和刷新频率合理
+* \[ ] 没有对操作人员无价值的装饰性面板
+
+## 相关技能
+
+* `research-ops`
+* `backend-patterns`
+* `terminal-ops`

docs/zh-CN/skills/defi-amm-security/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: defi-amm-security
+description: Solidity AMM 合约、流动性池和交换流程的安全检查清单。涵盖重入、CEI 排序、捐赠或通胀攻击、预言机操纵、滑点、管理员控制和整数数学。
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# DeFi AMM 安全
+
+Solidity AMM 合约、LP 金库和交换函数的关键漏洞模式及强化实现。
+
+## 适用场景
+
+* 编写或审计 Solidity AMM 或流动性池合约
+* 实现持有代币余额的交换、存款、提款、铸造或销毁流程
+* 审查任何在份额或储备金计算中使用 `token.balanceOf(address(this))` 的合约
+* 向 DeFi 协议添加费用设置器、暂停器、预言机更新或其他管理功能
+
+## 工作原理
+
+将其作为检查清单加模式库使用。对照以下类别审查每个用户入口点，并优先使用强化示例而非自行编写的变体。
+
+## 执行安全
+
+本技能中的 shell 命令是本地审计示例。仅在受信任的代码检出或一次性沙箱中运行，不要将不受信任的合约名称、路径、RPC URL、私钥或用户提供的标志拼接到 shell 命令中。在安装工具或运行可能消耗大量本地或付费资源的长时间模糊测试/静态分析任务前，请先询问。
+
+切勿在命令示例、日志或报告中包含机密信息、私钥、助记词、API 令牌或主网签名凭证。
+
+## 示例
+
+### 重入攻击：强制遵循 CEI 顺序
+
+存在漏洞：
+
+```solidity
+function withdraw(uint256 amount) external {
+    require(balances[msg.sender] >= amount);
+    token.transfer(msg.sender, amount);
+    balances[msg.sender] -= amount;
+}
+```
+
+安全：
+
+```solidity
+import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
+import {SafeERC20} from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
+
+using SafeERC20 for IERC20;
+
+function withdraw(uint256 amount) external nonReentrant {
+    require(balances[msg.sender] >= amount, "Insufficient");
+    balances[msg.sender] -= amount;
+    token.safeTransfer(msg.sender, amount);
+}
+```
+
+当存在经过验证的库时，不要自行编写防护措施。
+
+### 捐赠或通胀攻击
+
+直接使用 `token.balanceOf(address(this))` 进行份额计算，会让攻击者通过向合约发送代币（绕过预期路径）来操纵分母。
+
+```solidity
+// Vulnerable
+function deposit(uint256 assets) external returns (uint256 shares) {
+    shares = (assets * totalShares) / token.balanceOf(address(this));
+}
+```
+
+```solidity
+// Safe
+uint256 private _totalAssets;
+
+function deposit(uint256 assets) external nonReentrant returns (uint256 shares) {
+    uint256 balBefore = token.balanceOf(address(this));
+    token.safeTransferFrom(msg.sender, address(this), assets);
+    uint256 received = token.balanceOf(address(this)) - balBefore;
+
+    shares = totalShares == 0 ? received : (received * totalShares) / _totalAssets;
+    _totalAssets += received;
+    totalShares += shares;
+}
+```
+
+跟踪内部会计并衡量实际收到的代币。
+
+### 预言机操纵
+
+现货价格可通过闪电贷操纵。优先使用 TWAP。
+
+```solidity
+uint32[] memory secondsAgos = new uint32[](2);
+secondsAgos[0] = 1800;
+secondsAgos[1] = 0;
+(int56[] memory tickCumulatives,) = IUniswapV3Pool(pool).observe(secondsAgos);
+int24 twapTick = int24(
+    (tickCumulatives[1] - tickCumulatives[0]) / int56(uint56(30 minutes))
+);
+uint160 sqrtPriceX96 = TickMath.getSqrtRatioAtTick(twapTick);
+```
+
+### 滑点保护
+
+每个交换路径都需要调用者提供的滑点和截止时间。
+
+```solidity
+function swap(
+    uint256 amountIn,
+    uint256 amountOutMin,
+    uint256 deadline
+) external returns (uint256 amountOut) {
+    require(block.timestamp <= deadline, "Expired");
+    amountOut = _calculateOut(amountIn);
+    require(amountOut >= amountOutMin, "Slippage exceeded");
+    _executeSwap(amountIn, amountOut);
+}
+```
+
+### 安全的储备金计算
+
+```solidity
+import {FullMath} from "@uniswap/v3-core/contracts/libraries/FullMath.sol";
+
+uint256 result = FullMath.mulDiv(a, b, c);
+```
+
+对于大型储备金计算，当存在溢出风险时，避免使用简单的 `a * b / c`。
+
+### 管理控制
+
+```solidity
+import {Ownable2Step} from "@openzeppelin/contracts/access/Ownable2Step.sol";
+
+contract MyAMM is Ownable2Step {
+    function setFee(uint256 fee) external onlyOwner { ... }
+    function pause() external onlyOwner { ... }
+}
+```
+
+所有权转移应优先使用显式接受，并对每个特权路径设置门控。
+
+## 安全检查清单
+
+* 暴露于重入攻击的入口点使用 `nonReentrant`
+* 遵循 CEI 顺序
+* 份额计算不依赖原始的 `balanceOf(address(this))`
+* ERC-20 转账使用 `SafeERC20`
+* 存款衡量实际收到的代币
+* 预言机读取使用 TWAP 或其他抗操纵源
+* 交换需要 `amountOutMin` 和 `deadline`
+* 对溢出敏感的储备金计算使用安全原语，如 `mulDiv`
+* 管理函数受访问控制
+* 存在紧急暂停功能并经过测试
+* 在生产前运行静态分析和模糊测试
+
+## 审计工具
+
+```bash
+pip install slither-analyzer
+slither . --exclude-dependencies
+
+echidna-test . --contract YourAMM --config echidna.yaml
+
+forge test --fuzz-runs 10000
+```

docs/zh-CN/skills/design-system/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: design-system
+description: 使用此技能生成或审计设计系统，检查视觉一致性，并审查涉及样式的PR。
+origin: ECC
+---
+
+# 设计系统 — 生成与审查视觉系统
+
+## 使用场景
+
+* 启动需要设计系统的新项目
+* 审查现有代码库的视觉一致性
+* 在重新设计前——了解现有状况
+* 当界面看起来"不对劲"但无法定位原因时
+* 审查涉及样式修改的PR
+
+## 工作原理
+
+### 模式1：生成设计系统
+
+分析代码库并生成统一的设计系统：
+
+```
+1. 扫描 CSS/Tailwind/styled-components 以查找现有模式
+2. 提取：颜色、排版、间距、边框圆角、阴影、断点
+3. 研究 3 个竞品网站以获取灵感（通过浏览器 MCP）
+4. 提出一套设计令牌（JSON + CSS 自定义属性）
+5. 生成 DESIGN.md，说明每个决策的理由
+6. 创建一个交互式 HTML 预览页面（自包含，无依赖）
+```
+
+输出：`DESIGN.md` + `design-tokens.json` + `design-preview.html`
+
+### 模式2：视觉审查
+
+从10个维度对界面进行评分（每项0-10分）：
+
+```
+1. 色彩一致性 — 你使用的是自己的调色板还是随机的十六进制值？
+2. 排版层级 — 清晰的 h1 > h2 > h3 > 正文 > 说明文字？
+3. 间距节奏 — 一致的尺度（4px/8px/16px）还是随意设置？
+4. 组件一致性 — 相似的元素看起来是否相似？
+5. 响应式行为 — 在断点处流畅还是混乱？
+6. 深色模式 — 完整实现还是半途而废？
+7. 动画 — 有目的性还是多余？
+8. 无障碍性 — 对比度、焦点状态、触摸目标
+9. 信息密度 — 杂乱还是整洁？
+10. 细节打磨 — 悬停状态、过渡效果、加载状态、空状态
+```
+
+每个维度都会获得评分、具体示例以及包含精确文件:行号的修复方案。
+
+### 模式3：AI生成内容检测
+
+识别通用的AI生成设计模式：
+
+```
+- 到处滥用渐变效果
+- 默认采用紫蓝配色
+- 毫无意义的"玻璃拟态"卡片
+- 不该圆角的地方强行圆角
+- 滚动时过度动画效果
+- 居中文字搭配默认渐变的通用英雄区
+- 毫无个性的无衬线字体堆叠
+```
+
+## 示例
+
+**为SaaS应用生成设计系统：**
+
+```
+/design-system generate --style minimal --palette earth-tones
+```
+
+**审查现有界面：**
+
+```
+/design-system audit --url http://localhost:3000 --pages / /pricing /docs
+```
+
+**检测AI生成内容：**
+
+```
+/design-system slop-check
+```

docs/zh-CN/skills/dotnet-patterns/SKILL.md

@@ -0,0 +1,321 @@
+---
+name: dotnet-patterns
+description: 惯用的C#和.NET模式、约定、依赖注入、async/await以及构建健壮、可维护的.NET应用程序的最佳实践。
+origin: ECC
+---
+
+# .NET 开发模式
+
+用于构建健壮、高性能且可维护应用程序的惯用 C# 和 .NET 模式。
+
+## 何时激活
+
+* 编写新的 C# 代码时
+* 审查 C# 代码时
+* 重构现有 .NET 应用程序时
+* 使用 ASP.NET Core 设计服务架构时
+
+## 核心原则
+
+### 1. 优先使用不可变性
+
+对数据模型使用记录和仅初始化属性。可变性应作为明确且有理由的选择。
+
+```csharp
+// Good: Immutable value object
+public sealed record Money(decimal Amount, string Currency);
+
+// Good: Immutable DTO with init setters
+public sealed class CreateOrderRequest
+{
+    public required string CustomerId { get; init; }
+    public required IReadOnlyList<OrderItem> Items { get; init; }
+}
+
+// Bad: Mutable model with public setters
+public class Order
+{
+    public string CustomerId { get; set; }
+    public List<OrderItem> Items { get; set; }
+}
+```
+
+### 2. 显式优于隐式
+
+明确表达可空性、访问修饰符和意图。
+
+```csharp
+// Good: Explicit access modifiers and nullability
+public sealed class UserService
+{
+    private readonly IUserRepository _repository;
+    private readonly ILogger<UserService> _logger;
+
+    public UserService(IUserRepository repository, ILogger<UserService> logger)
+    {
+        _repository = repository ?? throw new ArgumentNullException(nameof(repository));
+        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
+    }
+
+    public async Task<User?> FindByIdAsync(Guid id, CancellationToken cancellationToken)
+    {
+        return await _repository.FindByIdAsync(id, cancellationToken);
+    }
+}
+```
+
+### 3. 依赖抽象
+
+对服务边界使用接口。通过依赖注入容器注册。
+
+```csharp
+// Good: Interface-based dependency
+public interface IOrderRepository
+{
+    Task<Order?> FindByIdAsync(Guid id, CancellationToken cancellationToken);
+    Task<IReadOnlyList<Order>> FindByCustomerAsync(string customerId, CancellationToken cancellationToken);
+    Task AddAsync(Order order, CancellationToken cancellationToken);
+}
+
+// Registration
+builder.Services.AddScoped<IOrderRepository, SqlOrderRepository>();
+```
+
+## 异步/等待模式
+
+### 正确使用异步
+
+```csharp
+// Good: Async all the way, with CancellationToken
+public async Task<OrderSummary> GetOrderSummaryAsync(
+    Guid orderId,
+    CancellationToken cancellationToken)
+{
+    var order = await _repository.FindByIdAsync(orderId, cancellationToken)
+        ?? throw new NotFoundException($"Order {orderId} not found");
+
+    var customer = await _customerService.GetAsync(order.CustomerId, cancellationToken);
+
+    return new OrderSummary(order, customer);
+}
+
+// Bad: Blocking on async
+public OrderSummary GetOrderSummary(Guid orderId)
+{
+    var order = _repository.FindByIdAsync(orderId, CancellationToken.None).Result; // Deadlock risk
+    return new OrderSummary(order);
+}
+```
+
+### 并行异步操作
+
+```csharp
+// Good: Concurrent independent operations
+public async Task<DashboardData> LoadDashboardAsync(CancellationToken cancellationToken)
+{
+    var ordersTask = _orderService.GetRecentAsync(cancellationToken);
+    var metricsTask = _metricsService.GetCurrentAsync(cancellationToken);
+    var alertsTask = _alertService.GetActiveAsync(cancellationToken);
+
+    await Task.WhenAll(ordersTask, metricsTask, alertsTask);
+
+    return new DashboardData(
+        Orders: await ordersTask,
+        Metrics: await metricsTask,
+        Alerts: await alertsTask);
+}
+```
+
+## 选项模式
+
+将配置节绑定到强类型对象。
+
+```csharp
+public sealed class SmtpOptions
+{
+    public const string SectionName = "Smtp";
+
+    public required string Host { get; init; }
+    public required int Port { get; init; }
+    public required string Username { get; init; }
+    public bool UseSsl { get; init; } = true;
+}
+
+// Registration
+builder.Services.Configure<SmtpOptions>(
+    builder.Configuration.GetSection(SmtpOptions.SectionName));
+
+// Usage via injection
+public class EmailService(IOptions<SmtpOptions> options)
+{
+    private readonly SmtpOptions _smtp = options.Value;
+}
+```
+
+## 结果模式
+
+对预期失败返回显式成功/失败，而非抛出异常。
+
+```csharp
+public sealed record Result<T>
+{
+    public bool IsSuccess { get; }
+    public T? Value { get; }
+    public string? Error { get; }
+
+    private Result(T value) { IsSuccess = true; Value = value; }
+    private Result(string error) { IsSuccess = false; Error = error; }
+
+    public static Result<T> Success(T value) => new(value);
+    public static Result<T> Failure(string error) => new(error);
+}
+
+// Usage
+public async Task<Result<Order>> PlaceOrderAsync(CreateOrderRequest request)
+{
+    if (request.Items.Count == 0)
+        return Result<Order>.Failure("Order must contain at least one item");
+
+    var order = Order.Create(request);
+    await _repository.AddAsync(order, CancellationToken.None);
+    return Result<Order>.Success(order);
+}
+```
+
+## 使用 EF Core 的仓储模式
+
+```csharp
+public sealed class SqlOrderRepository : IOrderRepository
+{
+    private readonly AppDbContext _db;
+
+    public SqlOrderRepository(AppDbContext db) => _db = db;
+
+    public async Task<Order?> FindByIdAsync(Guid id, CancellationToken cancellationToken)
+    {
+        return await _db.Orders
+            .Include(o => o.Items)
+            .AsNoTracking()
+            .FirstOrDefaultAsync(o => o.Id == id, cancellationToken);
+    }
+
+    public async Task<IReadOnlyList<Order>> FindByCustomerAsync(
+        string customerId,
+        CancellationToken cancellationToken)
+    {
+        return await _db.Orders
+            .Where(o => o.CustomerId == customerId)
+            .OrderByDescending(o => o.CreatedAt)
+            .AsNoTracking()
+            .ToListAsync(cancellationToken);
+    }
+
+    public async Task AddAsync(Order order, CancellationToken cancellationToken)
+    {
+        _db.Orders.Add(order);
+        await _db.SaveChangesAsync(cancellationToken);
+    }
+}
+```
+
+## 中间件与管道
+
+```csharp
+// Custom middleware
+public sealed class RequestTimingMiddleware
+{
+    private readonly RequestDelegate _next;
+    private readonly ILogger<RequestTimingMiddleware> _logger;
+
+    public RequestTimingMiddleware(RequestDelegate next, ILogger<RequestTimingMiddleware> logger)
+    {
+        _next = next;
+        _logger = logger;
+    }
+
+    public async Task InvokeAsync(HttpContext context)
+    {
+        var stopwatch = Stopwatch.StartNew();
+        try
+        {
+            await _next(context);
+        }
+        finally
+        {
+            stopwatch.Stop();
+            _logger.LogInformation(
+                "Request {Method} {Path} completed in {ElapsedMs}ms with status {StatusCode}",
+                context.Request.Method,
+                context.Request.Path,
+                stopwatch.ElapsedMilliseconds,
+                context.Response.StatusCode);
+        }
+    }
+}
+```
+
+## 最小 API 模式
+
+```csharp
+// Organized with route groups
+var orders = app.MapGroup("/api/orders")
+    .RequireAuthorization()
+    .WithTags("Orders");
+
+orders.MapGet("/{id:guid}", async (
+    Guid id,
+    IOrderRepository repository,
+    CancellationToken cancellationToken) =>
+{
+    var order = await repository.FindByIdAsync(id, cancellationToken);
+    return order is not null
+        ? TypedResults.Ok(order)
+        : TypedResults.NotFound();
+});
+
+orders.MapPost("/", async (
+    CreateOrderRequest request,
+    IOrderService service,
+    CancellationToken cancellationToken) =>
+{
+    var result = await service.PlaceOrderAsync(request, cancellationToken);
+    return result.IsSuccess
+        ? TypedResults.Created($"/api/orders/{result.Value!.Id}", result.Value)
+        : TypedResults.BadRequest(result.Error);
+});
+```
+
+## 守卫子句
+
+```csharp
+// Good: Early returns with clear validation
+public async Task<ProcessResult> ProcessPaymentAsync(
+    PaymentRequest request,
+    CancellationToken cancellationToken)
+{
+    ArgumentNullException.ThrowIfNull(request);
+
+    if (request.Amount <= 0)
+        throw new ArgumentOutOfRangeException(nameof(request.Amount), "Amount must be positive");
+
+    if (string.IsNullOrWhiteSpace(request.Currency))
+        throw new ArgumentException("Currency is required", nameof(request.Currency));
+
+    // Happy path continues here without nesting
+    var gateway = _gatewayFactory.Create(request.Currency);
+    return await gateway.ChargeAsync(request, cancellationToken);
+}
+```
+
+## 应避免的反模式
+
+| 反模式 | 修复方案 |
+|---|---|
+| `async void` 方法 | 返回 `Task`（事件处理程序除外） |
+| `.Result` 或 `.Wait()` | 使用 `await` |
+| `catch (Exception) { }` | 处理或带上下文重新抛出 |
+| 构造函数中的 `new Service()` | 使用构造函数注入 |
+| `public` 字段 | 使用带适当访问器的属性 |
+| 业务逻辑中的 `dynamic` | 使用泛型或显式类型 |
+| 可变的 `static` 状态 | 使用依赖注入作用域或 `ConcurrentDictionary` |
+| 循环中的 `string.Format` | 使用 `StringBuilder` 或内插字符串处理程序 |

docs/zh-CN/skills/ecc-tools-cost-audit/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: ecc-tools-cost-audit
+description: 证据优先的ECC工具燃烧和计费审计工作流。用于调查ECC工具仓库中的失控PR创建、配额绕过、高级模型泄漏、重复作业或GitHub App成本激增。
+origin: ECC
+---
+
+# ECC 工具成本审计
+
+当用户怀疑 ECC Tools GitHub App 正在消耗成本、过度创建 PR、绕过使用限制，或将免费用户引导至付费分析路径时，使用此技能。
+
+这是一个针对兄弟仓库 [ECC-Tools](../../../../ECC-Tools) 的聚焦操作者工作流。它不是通用的计费技能，也不是仓库范围的代码审查。
+
+## 技能栈
+
+在相关情况下，将这些 ECC 原生技能拉入工作流：
+
+* `autonomous-loops` 用于跨 webhook、队列、计费和重试的有界多步骤审计
+* `agentic-engineering` 用于将请求路径追踪为离散的、可证明的单元
+* `customer-billing-ops` 当需要清晰分离仓库行为和客户影响计算时
+* `search-first` 在发明辅助函数或重新实现仓库本地工具之前
+* `security-review` 当涉及认证、使用限制、授权或密钥时
+* `verification-loop` 用于证明重试安全性和精确的修复后状态
+* `tdd-workflow` 当修复需要在 worker、路由器或计费路径中添加回归测试覆盖时
+
+## 使用时机
+
+* 用户提及 ECC Tools 消耗率、PR 递归、过度创建的 PR、使用限制绕过或付费模型泄漏
+* 任务位于兄弟仓库 `ECC-Tools` 中，并依赖于 webhook 处理器、队列 worker、使用预留、PR 创建逻辑或付费网关强制执行
+* 客户报告称应用创建了过多 PR、计费错误，或分析了代码但未产生可用结果
+
+## 范围约束
+
+* 在兄弟仓库 `ECC-Tools` 中工作，而非 `everything-claude-code`
+* 除非用户明确要求修复，否则以只读方式开始
+* 在追踪分析消耗时，不要修改无关的计费、结账或 UI 流程
+* 将应用生成的分支和应用生成的 PR 视为红旗递归路径，除非被证明并非如此
+* 明确区分三件事：
+  * 仓库侧消耗的根本原因
+  * 面向客户的计费影响
+  * 需要纳入待办事项跟踪的产品或授权缺口
+
+## 工作流
+
+### 1. 冻结仓库范围
+
+* 切换到兄弟仓库 `ECC-Tools`
+* 首先检查分支和本地差异
+* 确定审计的具体范围：
+  * webhook 路由器
+  * 队列生产者
+  * 队列消费者
+  * PR 创建路径
+  * 使用预留 / 计费路径
+  * 模型路由路径
+
+### 2. 在理论化之前追踪入口
+
+* 首先检查 `src/index.*` 或主入口点
+* 在提出修复建议之前，映射每个入队路径
+* 确认哪些 GitHub 事件共享一个队列类型
+* 确认 push、pull\_request、synchronize、comment 或手动重新运行事件是否会汇聚到同一个昂贵的路径上
+
+### 3. 追踪 Worker 和副作用
+
+* 检查处理分析的队列消费者或定时 worker
+* 确认排队的分析是否总是以以下方式结束：
+  * PR 创建
+  * 分支创建
+  * 文件更新
+  * 付费模型调用
+  * 使用量增加
+* 如果分析可能消耗令牌，然后在输出持久化之前失败，则将其归类为“消耗但输出中断”
+
+### 4. 审计高信号消耗路径
+
+#### PR 倍增
+
+* 检查 PR 辅助函数和分支命名
+* 检查去重、synchronize 事件处理以及现有 PR 的复用
+* 如果应用生成的分支可以重新进入分析，则将其视为优先级为 0 的递归风险
+
+#### 配额绕过
+
+* 检查配额检查的位置与使用量预留或增加的位置
+* 如果在入队前检查配额，但仅在 worker 内部计费使用量，则将并发的前门通过视为真正的竞态条件
+
+#### 付费模型泄漏
+
+* 检查模型选择、层级分支和提供商路由
+* 验证当存在付费密钥时，免费或受限用户是否仍能访问付费分析器
+
+#### 重试消耗
+
+* 检查重试循环、重复的队列任务和确定性失败重试
+* 如果相同的非临时性错误可以反复消耗分析资源，则先修复此问题，再进行质量改进
+
+### 5. 按消耗顺序修复
+
+如果用户要求代码更改，请按以下顺序优先修复：
+
+1. 阻止自动 PR 倍增
+2. 阻止配额绕过
+3. 阻止付费模型泄漏
+4. 阻止重复任务扇出和无意义的重试
+5. 弥补重试/更新安全缺口
+
+除非同一根本原因明显跨越多个文件，否则将修复范围限制在一到三个直接修复。
+
+### 6. 以最小的验证步骤进行验证
+
+* 仅重新运行覆盖已更改路径的目标测试或集成片段
+* 验证消耗路径现在是否：
+  * 被阻止
+  * 已去重
+  * 降级为更便宜的分析
+  * 或提前被拒绝
+* 准确说明最终状态：
+  * 本地已更改
+  * 本地已验证
+  * 已推送
+  * 已部署
+  * 仍被阻止
+
+## 高信号故障模式
+
+### 1. 所有触发器使用同一队列类型
+
+如果推送、PR 同步和手动审计都入队相同的任务，并且 worker 总是创建 PR，那么分析就等于 PR 垃圾信息。
+
+### 2. 入队后预留使用量
+
+如果在入口处检查使用量，但仅在 worker 中增加，则并发请求可能全部通过关卡并超出配额。
+
+### 3. 免费层级走付费路径
+
+如果存在密钥时，免费的排队任务仍能路由到 Anthropic 或其他付费提供商，即使客户从未看到付费结果，这也是真实的支出泄漏。
+
+### 4. 应用生成的分支重新进入 Webhook
+
+如果 `pull_request.synchronize`、分支推送或评论触发的运行在应用拥有的分支上触发，则应用可以递归分析自己的输出。
+
+### 5. 在持久化安全之前执行昂贵操作
+
+如果系统可能消耗令牌，然后在 PR 创建、文件更新或分支冲突时失败，则是在消耗成本而不产生价值。
+
+## 陷阱
+
+* 不要一开始就广泛浏览仓库；先确定 webhook -> 队列 -> worker 的路径
+* 不要将客户计费推断与基于代码的产品事实混为一谈
+* 在最高消耗路径被控制之前，不要修复价值较低的质量问题
+* 在重新运行狭窄的验证步骤之前，不要声称消耗问题已修复
+* 除非用户要求，否则不要推送或部署
+* 如果无关的仓库本地更改正在进行中，不要触碰它们
+
+## 验证
+
+* 根本原因需引用确切的文件路径和代码区域
+* 修复按消耗影响排序，而非代码整洁度
+* 需指明验证命令的名称
+* 最终状态需区分本地更改、验证、推送和部署

docs/zh-CN/skills/email-ops/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: email-ops
+description: 以证据为先的邮箱分类、草稿、发送验证及已发送邮件安全跟进工作流，适用于ECC。当用户希望整理邮件、通过真实邮件界面起草或发送、或证明已发送邮件内容时使用。
+origin: ECC
+---
+
+# 邮件操作
+
+当实际任务为邮箱工作时使用：分类、起草、回复、发送，或确认邮件已进入已发送文件夹。
+
+这不是通用写作技能，而是围绕实际邮件界面的操作工作流。
+
+## 技能栈
+
+在相关场景下调用这些ECC原生技能：
+
+* `brand-voice` 在起草任何面向用户的内容之前
+* `investor-outreach` 用于面向投资者、合作伙伴或赞助商的邮件
+* `customer-billing-ops` 当邮件线程属于账单/支持事件而非普通通信时
+* `knowledge-ops` 当需要将消息或线程捕获到持久上下文中时
+* `research-ops` 当回复依赖最新外部事实时
+
+## 使用时机
+
+* 用户要求分类收件箱或清理低价值邮件
+* 用户需要起草、回复或发送新邮件
+* 用户想确认邮件是否已发送
+* 用户需要验证使用的账户、线程或已发送记录
+
+## 安全护栏
+
+* 除非用户明确要求实时发送，否则先起草
+* 未经真实已发送文件夹或客户端确认，不得声称邮件已发送
+* 不随意切换发件账户；选择与项目和收件人匹配的账户
+* 清理时不删除不确定的业务邮件
+* 若任务实为私信或iMessage工作，转交至`messages-ops`
+
+## 工作流程
+
+### 1. 确认具体界面
+
+操作前明确：
+
+* 哪个邮箱账户
+* 哪个线程或收件人
+* 任务是分类、起草、回复还是发送
+* 用户需要仅起草还是实时发送
+
+### 2. 撰写前阅读线程
+
+若回复：
+
+* 阅读现有线程
+* 识别最后一次对外联系
+* 识别任何承诺、截止日期或未回答问题
+
+若创建新外发邮件：
+
+* 确定亲密度等级
+* 选择正确渠道和发件账户
+* 起草前调用`brand-voice`
+
+### 3. 起草，然后验证
+
+仅起草任务：
+
+* 生成最终副本
+* 说明发件人、收件人、主题和目的
+
+实时发送任务：
+
+* 先验证最终正文
+* 通过选定邮件界面发送
+* 确认消息已进入已发送文件夹或等效的已发送副本存储
+
+### 4. 报告确切状态
+
+使用精确状态词：
+
+* 已起草
+* 待审批
+* 已发送
+* 被阻止
+* 等待验证
+
+若发送界面被阻止，保留草稿并报告确切阻止原因，而非未经说明即改用第二传输方式。
+
+## 输出格式
+
+```text
+邮件界面
+- 账户
+- 邮件线程/收件人
+- 请求的操作
+
+草稿
+- 主题
+- 正文
+
+状态
+- 已草拟/已发送/已拦截
+- 适用时附上发送证明
+
+下一步
+- 发送
+- 跟进
+- 归档/移动
+```
+
+## 常见陷阱
+
+* 未经已发送副本检查不得声称发送成功
+* 不得忽略线程历史而撰写无上下文的回复
+* 不得混淆邮箱工作与私信或短信工作流
+* 不得泄露机密、认证详情或不必要的消息元数据
+
+## 验证
+
+* 回复中指明账户和线程或收件人
+* 任何发送声明均包含已发送证明或明确的客户端确认
+* 最终状态为：已起草/已发送/被阻止/等待验证

docs/zh-CN/skills/evm-token-decimals/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: evm-token-decimals
+description: 防止跨EVM链的静默小数不匹配错误。涵盖运行时小数查找、链感知缓存、桥接代币精度漂移以及面向机器人、仪表盘和DeFi工具的安全归一化。
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# EVM 代币精度
+
+静默的精度不匹配是导致余额或美元价值出现数量级偏差且不抛出错误的最常见原因之一。
+
+## 适用场景
+
+* 在 Python、TypeScript 或 Solidity 中读取 ERC-20 余额
+* 根据链上余额计算法币价值
+* 跨多条 EVM 链比较代币数量
+* 处理跨链桥接资产
+* 构建投资组合追踪器、机器人或聚合器
+
+## 工作原理
+
+切勿假设稳定币在所有链上使用相同的精度。在运行时查询 `decimals()`，按 `(chain_id, token_address)` 进行缓存，并使用精度安全的数学运算进行价值计算。
+
+## 示例
+
+### 运行时查询精度
+
+```python
+from decimal import Decimal
+from web3 import Web3
+
+ERC20_ABI = [
+    {"name": "decimals", "type": "function", "inputs": [],
+     "outputs": [{"type": "uint8"}], "stateMutability": "view"},
+    {"name": "balanceOf", "type": "function",
+     "inputs": [{"name": "account", "type": "address"}],
+     "outputs": [{"type": "uint256"}], "stateMutability": "view"},
+]
+
+def get_token_balance(w3: Web3, token_address: str, wallet: str) -> Decimal:
+    contract = w3.eth.contract(
+        address=Web3.to_checksum_address(token_address),
+        abi=ERC20_ABI,
+    )
+    decimals = contract.functions.decimals().call()
+    raw = contract.functions.balanceOf(Web3.to_checksum_address(wallet)).call()
+    return Decimal(raw) / Decimal(10 ** decimals)
+```
+
+不要硬编码 `1_000_000`，因为同名代币在其他链上通常有 6 位小数。
+
+### 按链和代币缓存
+
+```python
+from functools import lru_cache
+
+@lru_cache(maxsize=512)
+def get_decimals(chain_id: int, token_address: str) -> int:
+    w3 = get_web3_for_chain(chain_id)
+    contract = w3.eth.contract(
+        address=Web3.to_checksum_address(token_address),
+        abi=ERC20_ABI,
+    )
+    return contract.functions.decimals().call()
+```
+
+### 防御性处理异常代币
+
+```python
+try:
+    decimals = contract.functions.decimals().call()
+except Exception:
+    logging.warning(
+        "decimals() reverted on %s (chain %s), defaulting to 18",
+        token_address,
+        chain_id,
+    )
+    decimals = 18
+```
+
+记录回退值并保持可见。旧版或非标准代币仍然存在。
+
+### 在 Solidity 中归一化为 18 位 WAD 精度
+
+```solidity
+interface IERC20Metadata {
+    function decimals() external view returns (uint8);
+}
+
+function normalizeToWad(address token, uint256 amount) internal view returns (uint256) {
+    uint8 d = IERC20Metadata(token).decimals();
+    if (d == 18) return amount;
+    if (d < 18) return amount * 10 ** (18 - d);
+    return amount / 10 ** (d - 18);
+}
+```
+
+### 使用 ethers 的 TypeScript 示例
+
+```typescript
+import { Contract, formatUnits } from 'ethers';
+
+const ERC20_ABI = [
+  'function decimals() view returns (uint8)',
+  'function balanceOf(address) view returns (uint256)',
+];
+
+async function getBalance(provider: any, tokenAddress: string, wallet: string): Promise<string> {
+  const token = new Contract(tokenAddress, ERC20_ABI, provider);
+  const [decimals, raw] = await Promise.all([
+    token.decimals(),
+    token.balanceOf(wallet),
+  ]);
+  return formatUnits(raw, decimals);
+}
+```
+
+### 快速链上检查
+
+```bash
+cast call <token_address> "decimals()(uint8)" --rpc-url <rpc>
+```
+
+## 规则
+
+* 始终在运行时查询 `decimals()`
+* 按链加代币地址进行缓存，而非按代币符号
+* 使用 `Decimal`、`BigInt` 或等效的精确数学运算，避免使用浮点数
+* 在跨链桥接或代币包装变更后重新查询精度
+* 在比较或定价前，始终将内部记账归一化为一致精度

docs/zh-CN/skills/finance-billing-ops/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: finance-billing-ops
+description: 面向ECC的以证据为先的收入、定价、退款、团队计费和计费模型真相工作流。当用户需要销售快照、定价比较、重复收费诊断或基于代码的计费现实而非通用支付建议时使用。
+origin: ECC
+---
+
+# 财务计费运营
+
+当用户想要了解资金、定价、退款、团队席位逻辑，或产品是否真的如网站和销售文案所暗示的那样运作时，使用此技能。
+
+此技能比 `customer-billing-ops` 更广泛。该技能用于客户补救。此技能用于运营者真相：收入状态、定价决策、团队计费以及基于代码的计费行为。
+
+## 技能栈
+
+在相关时，将这些 ECC 原生技能引入工作流程：
+
+* `customer-billing-ops` 用于特定客户的补救和跟进
+* `research-ops` 当竞争对手定价或当前市场证据重要时
+* `market-research` 当答案应以定价建议结束时
+* `github-ops` 当计费真相取决于兄弟仓库中的代码、待办事项或发布状态时
+* `verification-loop` 当答案取决于验证结账、席位处理或权限行为时
+
+## 使用时机
+
+* 用户询问 Stripe 销售额、退款、MRR 或近期客户活动
+* 用户询问团队计费、按席位计费或配额叠加在代码中是否真实存在
+* 用户想要竞争对手定价比较或定价模型基准
+* 问题混合了收入事实与产品实现真相
+
+## 护栏
+
+* 区分实时数据与保存的快照
+* 区分：
+  * 收入事实
+  * 客户影响
+  * 基于代码的产品真相
+  * 建议
+* 除非实际的权限路径强制执行，否则不要说“按席位”
+* 不要假设重复订阅意味着重复价值
+
+## 工作流程
+
+### 1. 从最新的计费证据开始
+
+优先使用实时计费数据。如果数据不是实时的，请明确说明快照时间戳。
+
+规范化视图：
+
+* 已付款销售
+* 活跃订阅
+* 失败或不完整的结账
+* 退款
+* 争议
+* 重复订阅
+
+### 2. 将客户事件与产品真相分开
+
+如果问题是针对特定客户的，请先分类：
+
+* 重复结账
+* 真实的团队意图
+* 自助服务控制失效
+* 未满足的产品价值
+* 付款失败或设置不完整
+
+然后将其与更广泛的产品问题分开：
+
+* 团队计费真的存在吗？
+* 席位是否实际被计数？
+* 结账数量是否会改变权限？
+* 网站是否夸大了当前行为？
+
+### 3. 检查基于代码的计费行为
+
+如果答案取决于实现真相，请检查代码路径：
+
+* 结账
+* 定价页面
+* 权限计算
+* 席位或配额处理
+* 安装与用户使用逻辑
+* 计费门户或自助管理支持
+
+### 4. 以决策和产品差距结束
+
+报告：
+
+* 销售快照
+* 问题诊断
+* 产品真相
+* 建议的运营者行动
+* 产品或待办事项差距
+
+## 输出格式
+
+```text
+快照
+- 时间戳
+- 收入 / 订阅 / 异常
+
+客户影响
+- 谁受影响
+- 发生了什么
+
+产品真相
+- 代码实际执行的操作
+- 网站或销售文案声称的内容
+
+决策
+- 退款 / 保留 / 转化 / 无操作
+
+产品差距
+- 需要构建或修复的具体后续事项
+```
+
+## 陷阱
+
+* 不要将失败的尝试与净收入混为一谈
+* 不要仅从营销语言推断团队计费
+* 在有当前证据可用时，不要凭记忆比较竞争对手定价
+* 不要在没有对问题进行分类的情况下，直接从诊断跳到退款
+
+## 验证
+
+* 答案包含实时数据声明或快照时间戳
+* 产品真相声明有代码支持
+* 客户影响与更广泛的定价/产品结论被清晰区分

docs/zh-CN/skills/gan-style-harness/SKILL.md

@@ -0,0 +1,284 @@
+---
+name: gan-style-harness
+description: "受GAN启发的生成器-评估器代理框架，用于自主构建高质量应用。基于Anthropic 2026年3月的框架设计论文。"
+origin: ECC-community
+tools: Read, Write, Edit, Bash, Grep, Glob, Task
+---
+
+# GAN 风格编排技能
+
+> 灵感来源于 [Anthropic 的长时间运行应用开发编排设计](https://www.anthropic.com/engineering/harness-design-long-running-apps)（2026年3月24日）
+
+一种多智能体编排，将**生成**与**评估**分离，形成对抗性反馈循环，推动质量远超单个智能体所能达到的水平。
+
+## 核心洞察
+
+> 当要求评估自身工作时，智能体是病态的乐观主义者——它们会赞美平庸的输出，并说服自己忽略真正的问题。但设计一个**独立的评估器**并使其极度严格，远比教会生成器自我批评要容易得多。
+
+这与 GAN（生成对抗网络）的机制相同：生成器负责产出，评估器负责批评，这种反馈驱动下一轮迭代。
+
+## 适用场景
+
+* 根据一行提示构建完整应用
+* 需要高视觉质量的前端设计任务
+* 需要工作功能而不仅仅是代码的全栈项目
+* 任何"AI 垃圾"美学不可接受的任务
+* 愿意投入 50-200 美元以获得生产级质量输出的项目
+
+## 不适用场景
+
+* 快速单文件修复（使用标准 `claude -p`）
+* 预算紧张的任务（<10 美元）
+* 简单重构（改用去垃圾化模式）
+* 已有完善测试规范的任务（使用 TDD 工作流）
+
+## 架构
+
+```
+                    ┌─────────────┐
+                    │   规划器    │
+                    │  (Opus 4.6) │
+                    └──────┬──────┘
+                           │ 产品规格
+                           │ (功能、冲刺、设计方向)
+                           ▼
+              ┌────────────────────────┐
+              │                        │
+              │   生成器-评估器        │
+              │     反馈循环           │
+              │                        │
+              │  ┌──────────┐          │
+              │  │ 生成器   │--构建-->│──┐
+              │  │(Opus 4.6)│          │  │
+              │  └────▲─────┘          │  │
+              │       │                │  │ 实时应用
+              │    反馈               │  │
+              │       │                │  │
+              │  ┌────┴─────┐          │  │
+              │  │ 评估器   │<-测试---│──┘
+              │  │(Opus 4.6)│          │
+              │  │+Playwright│         │
+              │  └──────────┘          │
+              │                        │
+              │   5-15 次迭代         │
+              └────────────────────────┘
+```
+
+## 三个智能体
+
+### 1. 规划器智能体
+
+**角色：** 产品经理——将简短的提示扩展为完整的产品规格。
+
+**关键行为：**
+
+* 接收一行提示，生成包含 16 个功能、多个冲刺的规格
+* 定义用户故事、技术需求和视觉设计方向
+* 故意**雄心勃勃**——保守规划会导致结果平庸
+* 生成评估器后续使用的评估标准
+
+**模型：** Opus 4.6（需要深度推理进行规格扩展）
+
+### 2. 生成器智能体
+
+**角色：** 开发者——根据规格实现功能。
+
+**关键行为：**
+
+* 按结构化冲刺工作（或使用较新模型的连续模式）
+* 在编写代码前与评估器协商"冲刺合约"
+* 使用全栈工具：React、FastAPI/Express、数据库、CSS
+* 管理 git 进行迭代间的版本控制
+* 读取评估器反馈并在下一轮迭代中采纳
+
+**模型：** Opus 4.6（需要强大的编码能力）
+
+### 3. 评估器智能体
+
+**角色：** QA 工程师——测试实时运行的应用，而不仅仅是代码。
+
+**关键行为：**
+
+* 使用 **Playwright MCP** 与实时应用交互
+* 点击功能、填写表单、测试 API 端点
+* 根据四个标准评分（可配置）：
+  1. **设计质量**——是否感觉像一个连贯的整体？
+  2. **原创性**——自定义决策 vs. 模板/AI 模式？
+  3. **工艺**——排版、间距、动画、微交互？
+  4. **功能性**——所有功能是否真正工作？
+* 返回结构化反馈，包含分数和具体问题
+* 设计为**极度严格**——从不赞美平庸的工作
+
+**模型：** Opus 4.6（需要强大的判断力 + 工具使用能力）
+
+## 评估标准
+
+默认四个标准，每个评分 1-10：
+
+```markdown
+## 评估标准
+
+### 设计质量（权重：0.3）
+- 1-3分：模板化、千篇一律的"AI生成"美学
+- 4-6分：合格但平庸，遵循常规设计
+- 7-8分：独特且连贯的视觉识别
+- 9-10分：可媲美专业设计师作品
+
+### 原创性（权重：0.2）
+- 1-3分：默认配色、模板布局，缺乏个性
+- 4-6分：部分自定义选择，整体仍属常规模式
+- 7-8分：清晰的创意构思，独特的设计手法
+- 9-10分：令人惊喜、愉悦，真正新颖
+
+### 工艺水平（权重：0.3）
+- 1-3分：布局错乱，状态缺失，无动画效果
+- 4-6分：功能可用但粗糙，间距不统一
+- 7-8分：精致流畅，过渡平滑，响应式设计
+- 9-10分：像素级完美，令人愉悦的微交互
+
+### 功能性（权重：0.2）
+- 1-3分：核心功能损坏或缺失
+- 4-6分：主流程可用，边缘情况处理失败
+- 7-8分：所有功能正常，错误处理良好
+- 9-10分：无懈可击，覆盖所有边缘情况
+```
+
+### 评分
+
+* **加权分数** = 总和（标准\_分数 \* 权重）
+* **通过阈值** = 7.0（可配置）
+* **最大迭代次数** = 15（可配置，通常 5-15 次足够）
+
+## 使用方法
+
+### 通过命令行
+
+```bash
+# Full three-agent harness
+/project:gan-build "Build a project management app with Kanban boards, team collaboration, and dark mode"
+
+# With custom config
+/project:gan-build "Build a recipe sharing platform" --max-iterations 10 --pass-threshold 7.5
+
+# Frontend design mode (generator + evaluator only, no planner)
+/project:gan-design "Create a landing page for a crypto portfolio tracker"
+```
+
+### 通过 Shell 脚本
+
+```bash
+# Basic usage
+./scripts/gan-harness.sh "Build a music streaming dashboard"
+
+# With options
+GAN_MAX_ITERATIONS=10 \
+GAN_PASS_THRESHOLD=7.5 \
+GAN_EVAL_CRITERIA="functionality,performance,security" \
+./scripts/gan-harness.sh "Build a REST API for task management"
+```
+
+### 通过 Claude Code（手动）
+
+```bash
+# Step 1: Plan
+claude -p --model opus "You are a Product Planner. Read PLANNER_PROMPT.md. Expand this brief into a full product spec: 'Build a Kanban board app'. Write spec to spec.md"
+
+# Step 2: Generate (iteration 1)
+claude -p --model opus "You are a Generator. Read spec.md. Implement Sprint 1. Start the dev server on port 3000."
+
+# Step 3: Evaluate (iteration 1)
+claude -p --model opus --allowedTools "Read,Bash,mcp__playwright__*" "You are an Evaluator. Read EVALUATOR_PROMPT.md. Test the live app at http://localhost:3000. Score against the rubric. Write feedback to feedback-001.md"
+
+# Step 4: Generate (iteration 2 — reads feedback)
+claude -p --model opus "You are a Generator. Read spec.md and feedback-001.md. Address all issues. Improve the scores."
+
+# Repeat steps 3-4 until pass threshold met
+```
+
+## 随模型能力的演进
+
+编排应随模型改进而简化。遵循 Anthropic 的演进路径：
+
+### 阶段 1 — 较弱模型（Sonnet 级别）
+
+* 需要完整的冲刺分解
+* 冲刺间重置上下文（避免上下文焦虑）
+* 最少 2 个智能体：初始化器 + 编码智能体
+* 大量脚手架弥补模型限制
+
+### 阶段 2 — 能力型模型（Opus 4.5 级别）
+
+* 完整的 3 智能体编排：规划器 + 生成器 + 评估器
+* 每个实现阶段前有冲刺合约
+* 复杂应用分解为 10 个冲刺
+* 上下文重置仍有帮助但不再关键
+
+### 阶段 3 — 前沿模型（Opus 4.6 级别）
+
+* 简化编排：单次规划，连续生成
+* 评估简化为单次最终评估（模型更智能）
+* 无需冲刺结构
+* 自动压缩处理上下文增长
+
+> **关键原则：** 编排的每个组件都编码了一个关于模型无法独立完成什么的假设。当模型改进时，重新测试这些假设。剥离不再需要的部分。
+
+## 配置
+
+### 环境变量
+
+| 变量 | 默认值 | 描述 |
+|----------|---------|-------------|
+| `GAN_MAX_ITERATIONS` | `15` | 最大生成器-评估器循环次数 |
+| `GAN_PASS_THRESHOLD` | `7.0` | 通过所需的加权分数（1-10） |
+| `GAN_PLANNER_MODEL` | `opus` | 规划智能体的模型 |
+| `GAN_GENERATOR_MODEL` | `opus` | 生成器智能体的模型 |
+| `GAN_EVALUATOR_MODEL` | `opus` | 评估器智能体的模型 |
+| `GAN_EVAL_CRITERIA` | `design,originality,craft,functionality` | 逗号分隔的标准 |
+| `GAN_DEV_SERVER_PORT` | `3000` | 实时应用的端口 |
+| `GAN_DEV_SERVER_CMD` | `npm run dev` | 启动开发服务器的命令 |
+| `GAN_PROJECT_DIR` | `.` | 项目工作目录 |
+| `GAN_SKIP_PLANNER` | `false` | 跳过规划器，直接使用规格 |
+| `GAN_EVAL_MODE` | `playwright` | `playwright`、`screenshot` 或 `code-only` |
+
+### 评估模式
+
+| 模式 | 工具 | 最适合 |
+|------|-------|----------|
+| `playwright` | 浏览器 MCP + 实时交互 | 带 UI 的全栈应用 |
+| `screenshot` | 截图 + 视觉分析 | 静态网站、纯设计 |
+| `code-only` | 测试 + 代码检查 + 构建 | API、库、CLI 工具 |
+
+## 反模式
+
+1. **评估器过于宽松**——如果评估器在第一次迭代就通过所有内容，你的评分标准过于慷慨。收紧评分标准，并为常见的 AI 模式添加明确惩罚。
+
+2. **生成器忽略反馈**——确保反馈以文件形式传递，而非内联。生成器应在每次迭代开始时读取 `feedback-NNN.md`。
+
+3. **无限循环**——始终设置 `GAN_MAX_ITERATIONS`。如果生成器在 3 次迭代后无法突破分数平台，停止并标记为人工审查。
+
+4. **评估器测试流于表面**——评估器必须使用 Playwright **交互**实时应用，而不仅仅是截图。点击按钮、填写表单、测试错误状态。
+
+5. **评估器赞美自己的修复**——绝不允许评估器建议修复后再评估这些修复。评估器只负责批评；生成器负责修复。
+
+6. **上下文耗尽**——对于长时间会话，使用 Claude Agent SDK 的自动压缩或在主要阶段之间重置上下文。
+
+## 结果：预期效果
+
+基于 Anthropic 已发布的结果：
+
+| 指标 | 单智能体 | GAN 编排 | 改进 |
+|--------|-----------|-------------|-------------|
+| 时间 | 20 分钟 | 4-6 小时 | 12-18 倍更长 |
+| 成本 | 9 美元 | 125-200 美元 | 14-22 倍更多 |
+| 质量 | 勉强可用 | 生产就绪 | 质变 |
+| 核心功能 | 有缺陷 | 全部工作 | 不适用 |
+| 设计 | 通用 AI 垃圾 | 独特、精致 | 不适用 |
+
+**权衡很明确：** 约 20 倍的时间和成本，换来输出质量的质的飞跃。这适用于质量至关重要的项目。
+
+## 参考
+
+* [Anthropic：长时间运行应用的编排设计](https://www.anthropic.com/engineering/harness-design-long-running-apps) — Prithvi Rajasekaran 的原始论文
+* [Epsilla：GAN 风格智能体循环](https://www.epsilla.com/blogs/anthropic-harness-engineering-multi-agent-gan-architecture) — 架构解构
+* [Martin Fowler：编排工程](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html) — 更广泛的行业背景
+* [OpenAI：编排工程](https://openai.com/index/harness-engineering/) — OpenAI 的并行工作

docs/zh-CN/skills/gateguard/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: gateguard
+description: 强制事实的门控，阻止编辑/写入/Bash（包括MultiEdit），并要求在允许操作之前进行具体调查（导入器、数据模式、用户指令）。与无门控代理相比，可测量地将输出质量提高2.25分。
+origin: community
+---
+
+# GateGuard — 事实驱动的前置操作门控
+
+一个 PreToolUse 钩子，强制 Claude 在编辑前进行调查。不同于自我评估（"你确定吗？"），它要求具体的事实。调查行为本身创造了自我评估永远无法带来的认知。
+
+## 何时激活
+
+* 处理任何文件编辑会影响多个模块的代码库时
+* 项目包含具有特定模式或日期格式的数据文件时
+* 团队要求 AI 生成的代码必须匹配现有模式时
+* 任何 Claude 倾向于猜测而非调查的工作流程中
+
+## 核心概念
+
+LLM 的自我评估不起作用。问"你是否违反了任何策略？"答案永远是"没有"。这已通过实验验证。
+
+但问"列出所有导入此模块的文件"会迫使 LLM 运行 Grep 和 Read。调查本身创造了改变输出的上下文。
+
+**三阶段门控：**
+
+```
+1. DENY  — 阻止首次编辑/写入/Bash 尝试
+2. FORCE — 明确告知模型需要收集哪些事实
+3. ALLOW — 在事实呈现后允许重试
+```
+
+没有竞争对手能同时做到这三步。大多数止步于拒绝。
+
+## 证据
+
+两个独立的 A/B 测试，相同的代理，相同的任务：
+
+| 任务 | 有门控 | 无门控 | 差距 |
+| --- | --- | --- | --- |
+| 分析模块 | 8.0/10 | 6.5/10 | +1.5 |
+| Webhook 验证器 | 10.0/10 | 7.0/10 | +3.0 |
+| **平均** | **9.0** | **6.75** | **+2.25** |
+
+两个代理生成的代码都能运行并通过测试。区别在于设计深度。
+
+## 门控类型
+
+### 编辑/多编辑门控（每个文件的首次编辑）
+
+多编辑的处理方式相同——批次中的每个文件都单独进行门控。
+
+```
+在编辑 {file_path} 之前，请先呈现以下事实：
+
+1. 列出所有导入/引用此文件的文件（使用 Grep）
+2. 列出受此更改影响的公共函数/类
+3. 如果此文件读取/写入数据文件，请显示字段名称、结构以及日期格式（使用脱敏或合成值，而非原始生产数据）
+4. 逐字引用用户当前的指令
+```
+
+### 写入门控（首次创建新文件）
+
+```
+在创建 {file_path} 之前，请先说明以下事实：
+
+1. 命名将调用此新文件的文件及行号
+2. 确认没有现有文件具有相同功能（使用 Glob）
+3. 如果此文件读取/写入数据文件，请展示字段名称、结构及日期格式（使用脱敏或合成值，而非原始生产数据）
+4. 逐字引用用户当前的指令
+```
+
+### 破坏性 Bash 门控（每个破坏性命令）
+
+触发条件：`rm -rf`、`git reset --hard`、`git push --force`、`drop table` 等。
+
+```
+1. 列出此命令将修改或删除的所有文件/数据
+2. 编写一行回滚步骤
+3. 逐字引用用户当前的指令
+```
+
+### 常规 Bash 门控（每个会话一次）
+
+```
+1. 当前用户请求的一句话概括
+2. 此特定命令验证或生成的内容
+```
+
+## 快速开始
+
+### 选项 A：使用 ECC 钩子（零安装）
+
+`scripts/hooks/gateguard-fact-force.js` 处的钩子已包含在此插件中。通过 hooks.json 启用它。
+
+如果 GateGuard 阻止了设置或修复工作，请使用
+`ECC_GATEGUARD=off` 启动会话。如需钩子级别的控制，请继续使用
+`ECC_DISABLED_HOOKS` 配合 GateGuard 钩子 ID。
+
+### 选项 B：带配置的完整包
+
+```bash
+pip install gateguard-ai
+gateguard init
+```
+
+这会添加 `.gateguard.yml` 用于按项目配置（自定义消息、忽略路径、门控开关）。
+
+## 反模式
+
+* **不要使用自我评估替代。** "你确定吗？"总是得到"确定。"这已通过实验验证。
+* **不要跳过数据模式检查。** 两个 A/B 测试代理都假设了 ISO-8601 日期，而实际数据使用的是 `%Y/%m/%d %H:%M`。检查数据结构（使用脱敏值）可以防止这类错误。
+* **不要对每个 Bash 命令都进行门控。** 常规 bash 门控每个会话一次。破坏性 bash 门控每次执行。这种平衡避免了速度下降，同时捕获了真正的风险。
+
+## 最佳实践
+
+* 让门控自然触发。不要试图预先回答门控问题——调查本身才是提高质量的关键。
+* 为你的领域自定义门控消息。如果你的项目有特定约定，请将其添加到门控提示中。
+* 使用 `.gateguard.yml` 忽略 `.venv/`、`node_modules/`、`.git/` 等路径。
+
+## 相关技能
+
+* `safety-guard` — 运行时安全检查（互补，不重叠）
+* `code-reviewer` — 编辑后审查（GateGuard 是编辑前调查）

docs/zh-CN/skills/git-workflow/SKILL.md

@@ -0,0 +1,720 @@
+---
+name: git-workflow
+description: Git工作流模式，包括分支策略、提交约定、合并与变基、冲突解决以及适用于各种规模团队的协作开发最佳实践。
+origin: ECC
+---
+
+# Git 工作流模式
+
+Git 版本控制、分支策略与协作开发的最佳实践。
+
+## 何时启用
+
+* 为新项目设置 Git 工作流
+* 决定分支策略（GitFlow、主干开发、GitHub Flow）
+* 编写提交信息和 PR 描述
+* 解决合并冲突
+* 管理发布和版本标签
+* 让新团队成员熟悉 Git 实践
+
+## 分支策略
+
+### GitHub Flow（简单，推荐大多数场景使用）
+
+最适合持续部署以及中小型团队。
+
+```
+main (protected, always deployable)
+  │
+  ├── feature/user-auth      → PR → merge to main
+  ├── feature/payment-flow   → PR → merge to main
+  └── fix/login-bug          → PR → merge to main
+```
+
+**规则：**
+
+* `main` 始终可部署
+* 从 `main` 创建功能分支
+* 准备就绪后发起 Pull Request
+* 审核通过且 CI 通过后，合并到 `main`
+* 合并后立即部署
+
+### 主干开发（高速度团队）
+
+最适合具备强大 CI/CD 和功能开关的团队。
+
+```
+main (主干)
+  │
+  ├── 短期功能分支（最长1-2天）
+  ├── 短期功能分支
+  └── 短期功能分支
+```
+
+**规则：**
+
+* 所有人直接提交到 `main` 或使用极短生命周期的分支
+* 功能开关隐藏未完成的工作
+* 合并前必须通过 CI
+* 每天多次部署
+
+### GitFlow（复杂，基于发布周期）
+
+适合计划性发布和企业级项目。
+
+```
+main (生产发布版本)
+  │
+  └── develop (集成分支)
+        │
+        ├── feature/user-auth
+        ├── feature/payment
+        │
+        ├── release/1.0.0    → 合并到 main 和 develop
+        │
+        └── hotfix/critical  → 合并到 main 和 develop
+```
+
+**规则：**
+
+* `main` 仅包含生产就绪代码
+* `develop` 是集成分支
+* 功能分支从 `develop` 创建，合并回 `develop`
+* 发布分支从 `develop` 创建，合并到 `main` 和 `develop`
+* 热修复分支从 `main` 创建，合并到 `main` 和 `develop`
+
+### 何时使用哪种策略
+
+| 策略 | 团队规模 | 发布频率 | 最佳适用场景 |
+|----------|-----------|-----------------|----------|
+| GitHub Flow | 任意 | 持续 | SaaS、Web 应用、初创公司 |
+| 主干开发 | 5 人以上有经验 | 每天多次 | 高速度团队、功能开关 |
+| GitFlow | 10 人以上 | 计划性 | 企业、受监管行业 |
+
+## 提交信息
+
+### 常规提交格式
+
+```
+<type>(<scope>): <subject>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+### 类型
+
+| 类型 | 用途 | 示例 |
+|------|---------|---------|
+| `feat` | 新功能 | `feat(auth): add OAuth2 login` |
+| `fix` | 错误修复 | `fix(api): handle null response in user endpoint` |
+| `docs` | 文档 | `docs(readme): update installation instructions` |
+| `style` | 格式调整，无代码变更 | `style: fix indentation in login component` |
+| `refactor` | 代码重构 | `refactor(db): extract connection pool to module` |
+| `test` | 添加/更新测试 | `test(auth): add unit tests for token validation` |
+| `chore` | 维护任务 | `chore(deps): update dependencies` |
+| `perf` | 性能改进 | `perf(query): add index to users table` |
+| `ci` | CI/CD 变更 | `ci: add PostgreSQL service to test workflow` |
+| `revert` | 回滚之前的提交 | `revert: revert "feat(auth): add OAuth2 login"` |
+
+### 好与坏的示例
+
+```
+# 不好：模糊，无上下文
+git commit -m "修复了一些东西"
+git commit -m "更新"
+git commit -m "进行中"
+
+# 好：清晰，具体，解释原因
+git commit -m "fix(api): 在 503 服务不可用时重试请求
+
+外部 API 在高峰时段偶尔会返回 503 错误。
+添加了指数退避重试逻辑，最多尝试 3 次。
+
+关闭 #123"
+```
+
+### 提交信息模板
+
+在仓库根目录创建 `.gitmessage`：
+
+```
+# <type>(<scope>): <subject>
+# # 类型：feat, fix, docs, style, refactor, test, chore, perf, ci, revert
+# 范围：api, ui, db, auth 等
+# 主题：祈使语气，无句号，最多50个字符
+#
+# [可选正文] - 解释原因，而非内容
+# [可选脚注] - 破坏性变更，关闭 #issue
+```
+
+启用方式：`git config commit.template .gitmessage`
+
+## 合并 vs 变基
+
+### 合并（保留历史）
+
+```bash
+# Creates a merge commit
+git checkout main
+git merge feature/user-auth
+
+# Result:
+# *   merge commit
+# |\
+# | * feature commits
+# |/
+# * main commits
+```
+
+**适用场景：**
+
+* 将功能分支合并到 `main`
+* 希望保留完整历史
+* 多人共同开发该分支
+* 分支已推送，其他人可能基于它开展工作
+
+### 变基（线性历史）
+
+```bash
+# Rewrites feature commits onto target branch
+git checkout feature/user-auth
+git rebase main
+
+# Result:
+# * feature commits (rewritten)
+# * main commits
+```
+
+**适用场景：**
+
+* 用最新的 `main` 更新本地功能分支
+* 希望获得线性、干净的历史
+* 分支仅存在于本地（未推送）
+* 只有你一个人在该分支上工作
+
+### 变基工作流
+
+```bash
+# Update feature branch with latest main (before PR)
+git checkout feature/user-auth
+git fetch origin
+git rebase origin/main
+
+# Fix any conflicts
+# Tests should still pass
+
+# Force push (only if you're the only contributor)
+git push --force-with-lease origin feature/user-auth
+```
+
+### 何时不应变基
+
+```
+# 切勿变基以下分支：
+- 已推送至共享仓库的分支
+- 他人已基于其工作的分支
+- 受保护分支（main、develop）
+- 已合并的分支
+
+# 原因：变基会重写历史，破坏他人的工作
+```
+
+## Pull Request 工作流
+
+### PR 标题格式
+
+```
+<type>(<scope>): <description>
+
+示例：
+feat(auth): add SSO support for enterprise users
+fix(api): resolve race condition in order processing
+docs(api): add OpenAPI specification for v2 endpoints
+```
+
+### PR 描述模板
+
+```markdown
+## 内容
+
+简要描述此 PR 的内容。
+
+## 动机
+
+解释动机和背景。
+
+## 实现方式
+
+值得强调的关键实现细节。
+
+## 测试
+
+- [ ] 新增/更新单元测试
+- [ ] 新增/更新集成测试
+- [ ] 执行手动测试
+
+## 截图（如适用）
+
+UI 变更的前后对比截图。
+
+## 检查清单
+
+- [ ] 代码遵循项目风格指南
+- [ ] 完成自我审查
+- [ ] 为复杂逻辑添加注释
+- [ ] 更新文档
+- [ ] 未引入新警告
+- [ ] 测试在本地通过
+- [ ] 关联问题已链接
+
+关闭 #123
+```
+
+### 代码审查清单
+
+**审查者：**
+
+* \[ ] 代码是否解决了所述问题？
+* \[ ] 是否处理了所有边界情况？
+* \[ ] 代码是否可读且易于维护？
+* \[ ] 是否有足够的测试？
+* \[ ] 是否存在安全问题？
+* \[ ] 提交历史是否干净（必要时已压缩）？
+
+**作者：**
+
+* \[ ] 在请求审查前已完成自我审查
+* \[ ] CI 通过（测试、lint、类型检查）
+* \[ ] PR 大小合理（理想情况下 <500 行）
+* \[ ] 与单个功能/修复相关
+* \[ ] 描述清晰解释了变更内容
+
+## 冲突解决
+
+### 识别冲突
+
+```bash
+# Check for conflicts before merge
+git checkout main
+git merge feature/user-auth --no-commit --no-ff
+
+# If conflicts, Git will show:
+# CONFLICT (content): Merge conflict in src/auth/login.ts
+# Automatic merge failed; fix conflicts and then commit the result.
+```
+
+### 解决冲突
+
+```bash
+# See conflicted files
+git status
+
+# View conflict markers in file
+# <<<<<<< HEAD
+# content from main
+# =======
+# content from feature branch
+# >>>>>>> feature/user-auth
+
+# Option 1: Manual resolution
+# Edit file, remove markers, keep correct content
+
+# Option 2: Use merge tool
+git mergetool
+
+# Option 3: Accept one side
+git checkout --ours src/auth/login.ts    # Keep main version
+git checkout --theirs src/auth/login.ts  # Keep feature version
+
+# After resolving, stage and commit
+git add src/auth/login.ts
+git commit
+```
+
+### 冲突预防策略
+
+```bash
+# 1. Keep feature branches small and short-lived
+# 2. Rebase frequently onto main
+git checkout feature/user-auth
+git fetch origin
+git rebase origin/main
+
+# 3. Communicate with team about touching shared files
+# 4. Use feature flags instead of long-lived branches
+# 5. Review and merge PRs promptly
+```
+
+## 分支管理
+
+### 命名规范
+
+```
+# 功能分支
+feature/user-authentication
+feature/JIRA-123-payment-integration
+
+# 错误修复
+fix/login-redirect-loop
+fix/456-null-pointer-exception
+
+# 热修复（生产问题）
+hotfix/critical-security-patch
+hotfix/database-connection-leak
+
+# 发布版本
+release/1.2.0
+release/2024-01-hotfix
+
+# 实验/概念验证
+experiment/new-caching-strategy
+poc/graphql-migration
+```
+
+### 分支清理
+
+```bash
+# Delete local branches that are merged
+git branch --merged main | grep -v "^\*\|main" | xargs -n 1 git branch -d
+
+# Delete remote-tracking references for deleted remote branches
+git fetch -p
+
+# Delete local branch
+git branch -d feature/user-auth  # Safe delete (only if merged)
+git branch -D feature/user-auth  # Force delete
+
+# Delete remote branch
+git push origin --delete feature/user-auth
+```
+
+### 暂存工作流
+
+```bash
+# Save work in progress
+git stash push -m "WIP: user authentication"
+
+# List stashes
+git stash list
+
+# Apply most recent stash
+git stash pop
+
+# Apply specific stash
+git stash apply stash@{2}
+
+# Drop stash
+git stash drop stash@{0}
+```
+
+## 发布管理
+
+### 语义化版本
+
+```
+MAJOR.MINOR.PATCH
+
+MAJOR：破坏性变更
+MINOR：新功能，向后兼容
+PATCH：错误修复，向后兼容
+
+示例：
+1.0.0 → 1.0.1（补丁：错误修复）
+1.0.1 → 1.1.0（次要：新功能）
+1.1.0 → 2.0.0（主要：破坏性变更）
+```
+
+### 创建发布
+
+```bash
+# Create annotated tag
+git tag -a v1.2.0 -m "Release v1.2.0
+
+Features:
+- Add user authentication
+- Implement password reset
+
+Fixes:
+- Resolve login redirect issue
+
+Breaking Changes:
+- None"
+
+# Push tag to remote
+git push origin v1.2.0
+
+# List tags
+git tag -l
+
+# Delete tag
+git tag -d v1.2.0
+git push origin --delete v1.2.0
+```
+
+### 变更日志生成
+
+```bash
+# Generate changelog from commits
+git log v1.1.0..v1.2.0 --oneline --no-merges
+
+# Or use conventional-changelog
+npx conventional-changelog -i CHANGELOG.md -s
+```
+
+## Git 配置
+
+### 基本配置
+
+```bash
+# User identity
+git config --global user.name "Your Name"
+git config --global user.email "your@email.com"
+
+# Default branch name
+git config --global init.defaultBranch main
+
+# Pull behavior (rebase instead of merge)
+git config --global pull.rebase true
+
+# Push behavior (push current branch only)
+git config --global push.default current
+
+# Auto-correct typos
+git config --global help.autocorrect 1
+
+# Better diff algorithm
+git config --global diff.algorithm histogram
+
+# Color output
+git config --global color.ui auto
+```
+
+### 实用别名
+
+```bash
+# Add to ~/.gitconfig
+[alias]
+    co = checkout
+    br = branch
+    ci = commit
+    st = status
+    unstage = reset HEAD --
+    last = log -1 HEAD
+    visual = log --oneline --graph --all
+    amend = commit --amend --no-edit
+    wip = commit -m "WIP"
+    undo = reset --soft HEAD~1
+    contributors = shortlog -sn
+```
+
+### Gitignore 模式
+
+```gitignore
+# Dependencies
+node_modules/
+vendor/
+
+# Build outputs
+dist/
+build/
+*.o
+*.exe
+
+# Environment files
+.env
+.env.local
+.env.*.local
+
+# IDE
+.idea/
+.vscode/
+*.swp
+*.swo
+
+# OS files
+.DS_Store
+Thumbs.db
+
+# Logs
+*.log
+logs/
+
+# Test coverage
+coverage/
+
+# Cache
+.cache/
+*.tsbuildinfo
+```
+
+## 常见工作流
+
+### 开始新功能
+
+```bash
+# 1. Update main branch
+git checkout main
+git pull origin main
+
+# 2. Create feature branch
+git checkout -b feature/user-auth
+
+# 3. Make changes and commit
+git add .
+git commit -m "feat(auth): implement OAuth2 login"
+
+# 4. Push to remote
+git push -u origin feature/user-auth
+
+# 5. Create Pull Request on GitHub/GitLab
+```
+
+### 用新变更更新 PR
+
+```bash
+# 1. Make additional changes
+git add .
+git commit -m "feat(auth): add error handling"
+
+# 2. Push updates
+git push origin feature/user-auth
+```
+
+### 同步 Fork 与上游
+
+```bash
+# 1. Add upstream remote (once)
+git remote add upstream https://github.com/original/repo.git
+
+# 2. Fetch upstream
+git fetch upstream
+
+# 3. Merge upstream/main into your main
+git checkout main
+git merge upstream/main
+
+# 4. Push to your fork
+git push origin main
+```
+
+### 撤销错误操作
+
+```bash
+# Undo last commit (keep changes)
+git reset --soft HEAD~1
+
+# Undo last commit (discard changes)
+git reset --hard HEAD~1
+
+# Undo last commit pushed to remote
+git revert HEAD
+git push origin main
+
+# Undo specific file changes
+git checkout HEAD -- path/to/file
+
+# Fix last commit message
+git commit --amend -m "New message"
+
+# Add forgotten file to last commit
+git add forgotten-file
+git commit --amend --no-edit
+```
+
+## Git 钩子
+
+### 预提交钩子
+
+```bash
+#!/bin/bash
+# .git/hooks/pre-commit
+
+# Run linting
+npm run lint || exit 1
+
+# Run tests
+npm test || exit 1
+
+# Check for secrets
+if git diff --cached | grep -E '(password|api_key|secret)'; then
+    echo "Possible secret detected. Commit aborted."
+    exit 1
+fi
+```
+
+### 预推送钩子
+
+```bash
+#!/bin/bash
+# .git/hooks/pre-push
+
+# Run full test suite
+npm run test:all || exit 1
+
+# Check for console.log statements
+if git diff origin/main | grep -E 'console\.log'; then
+    echo "Remove console.log statements before pushing."
+    exit 1
+fi
+```
+
+## 反模式
+
+```
+# 错误：直接提交到主分支
+git checkout main
+git commit -m "修复bug"
+
+# 正确：使用功能分支和拉取请求
+
+# 错误：提交机密信息
+git add .env  # 包含API密钥
+
+# 正确：添加到.gitignore，使用环境变量
+
+# 错误：巨大的拉取请求（超过1000行）
+# 正确：拆分为更小、更聚焦的拉取请求
+
+# 错误："更新"类提交信息
+git commit -m "更新"
+git commit -m "修复"
+
+# 正确：描述性信息
+git commit -m "fix(auth): 解决登录后的重定向循环问题"
+
+# 错误：重写公共历史
+git push --force origin main
+
+# 正确：对公共分支使用回退
+git revert HEAD
+
+# 错误：长期存在的功能分支（数周/数月）
+# 正确：保持分支短期（数天），频繁变基
+
+# 错误：提交生成的文件
+git add dist/
+git add node_modules/
+
+# 正确：添加到.gitignore
+```
+
+## 快速参考
+
+| 任务 | 命令 |
+|------|---------|
+| 创建分支 | `git checkout -b feature/name` |
+| 切换分支 | `git checkout branch-name` |
+| 删除分支 | `git branch -d branch-name` |
+| 合并分支 | `git merge branch-name` |
+| 变基分支 | `git rebase main` |
+| 查看历史 | `git log --oneline --graph` |
+| 查看变更 | `git diff` |
+| 暂存变更 | `git add .` 或 `git add -p` |
+| 提交 | `git commit -m "message"` |
+| 推送 | `git push origin branch-name` |
+| 拉取 | `git pull origin branch-name` |
+| 暂存 | `git stash push -m "message"` |
+| 撤销上次提交 | `git reset --soft HEAD~1` |
+| 回滚提交 | `git revert HEAD` |

docs/zh-CN/skills/github-ops/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: github-ops
+description: GitHub 仓库操作、自动化与管理。使用 gh CLI 进行问题分类、PR 管理、CI/CD 操作、发布管理和安全监控。当用户想要管理 GitHub 问题、PR、CI 状态、发布、贡献者、过期项目或任何超出简单 git 命令的 GitHub 操作任务时使用。
+origin: ECC
+---
+
+# GitHub 操作
+
+管理 GitHub 仓库，重点关注社区健康、CI 可靠性和贡献者体验。
+
+## 何时激活
+
+* 对议题进行分类（分类、打标签、回复、去重）
+* 管理 PR（审查状态、CI 检查、过期 PR、合并就绪状态）
+* 调试 CI/CD 失败
+* 准备发布和变更日志
+* 监控 Dependabot 和安全告警
+* 管理开源项目的贡献者体验
+* 用户说“检查 GitHub”、“分类议题”、“审查 PR”、“合并”、“发布”、“CI 坏了”
+
+## 工具要求
+
+* 所有 GitHub API 操作均使用 **gh CLI**
+* 通过 `gh auth login` 配置仓库访问权限
+
+## 议题分类
+
+按类型和优先级对每个议题进行分类：
+
+**类型：** bug, feature-request, question, documentation, enhancement, duplicate, invalid, good-first-issue
+
+**优先级：** critical（破坏性/安全相关）, high（重大影响）, medium（锦上添花）, low（外观/体验优化）
+
+### 分类工作流程
+
+1. 阅读议题标题、正文和评论
+2. 检查是否与现有议题重复（通过关键词搜索）
+3. 通过 `gh issue edit --add-label` 应用适当的标签
+4. 对于问题：起草并发布有帮助的回复
+5. 对于需要更多信息的 Bug：要求提供复现步骤
+6. 对于适合新手的议题：添加 `good-first-issue` 标签
+7. 对于重复议题：评论并附上原始议题链接，添加 `duplicate` 标签
+
+```bash
+# Search for potential duplicates
+gh issue list --search "keyword" --state all --limit 20
+
+# Add labels
+gh issue edit <number> --add-label "bug,high-priority"
+
+# Comment on issue
+gh issue comment <number> --body "Thanks for reporting. Could you share reproduction steps?"
+```
+
+## PR 管理
+
+### 审查清单
+
+1. 检查 CI 状态：`gh pr checks <number>`
+2. 检查是否可合并：`gh pr view <number> --json mergeable`
+3. 检查 PR 的创建时间和最后活动时间
+4. 标记超过 5 天未审查的 PR
+5. 对于社区 PR：确保包含测试并遵循项目规范
+
+### 过期策略
+
+* 超过 14 天无活动的议题：添加 `stale` 标签，评论要求更新
+* 超过 7 天无活动的 PR：评论询问是否仍在进行
+* 30 天内无回复的过期议题自动关闭（添加 `closed-stale` 标签）
+
+```bash
+# Find stale issues (no activity in 14+ days)
+gh issue list --label "stale" --state open
+
+# Find PRs with no recent activity
+gh pr list --json number,title,updatedAt --jq '.[] | select(.updatedAt < "2026-03-01")'
+```
+
+## CI/CD 操作
+
+当 CI 失败时：
+
+1. 检查工作流运行：`gh run view <run-id> --log-failed`
+2. 识别失败的步骤
+3. 判断是不稳定测试还是真正的失败
+4. 对于真正的失败：确定根本原因并提出修复建议
+5. 对于不稳定测试：记录模式以便未来调查
+
+```bash
+# List recent failed runs
+gh run list --status failure --limit 10
+
+# View failed run logs
+gh run view <run-id> --log-failed
+
+# Re-run a failed workflow
+gh run rerun <run-id> --failed
+```
+
+## 发布管理
+
+准备发布时：
+
+1. 确保主分支上的所有 CI 检查通过
+2. 审查未发布的更改：`gh pr list --state merged --base main`
+3. 根据 PR 标题生成变更日志
+4. 创建发布：`gh release create`
+
+```bash
+# List merged PRs since last release
+gh pr list --state merged --base main --search "merged:>2026-03-01"
+
+# Create a release
+gh release create v1.2.0 --title "v1.2.0" --generate-notes
+
+# Create a pre-release
+gh release create v1.3.0-rc1 --prerelease --title "v1.3.0 Release Candidate 1"
+```
+
+## 安全监控
+
+```bash
+# Check Dependabot alerts
+gh api repos/{owner}/{repo}/dependabot/alerts --jq '.[].security_advisory.summary'
+
+# Check secret scanning alerts
+gh api repos/{owner}/{repo}/secret-scanning/alerts --jq '.[].state'
+
+# Review and auto-merge safe dependency bumps
+gh pr list --label "dependencies" --json number,title
+```
+
+* 审查并自动合并安全的依赖项更新
+* 立即标记任何严重/高严重性告警
+* 至少每周检查一次新的 Dependabot 告警
+
+## 质量门禁
+
+在完成任何 GitHub 操作任务之前：
+
+* 所有已分类的议题都带有适当的标签
+* 没有超过 7 天未收到审查或评论的 PR
+* CI 失败已被调查（不仅仅是重新运行）
+* 发布包含准确的变更日志
+* 安全告警已被确认并跟踪

docs/zh-CN/skills/google-workspace-ops/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: google-workspace-ops
+description: 将 Google 云端硬盘、文档、表格和幻灯片作为一个工作流界面来操作，用于处理计划、追踪器、演示文稿和共享文档。当用户需要查找、总结、编辑、迁移或清理 Google Workspace 资产，而无需使用原始工具调用时使用。
+origin: ECC
+---
+
+# Google Workspace 操作
+
+此技能用于将共享文档、电子表格和演示文稿作为工作系统进行操作，而不仅仅是孤立地编辑单个文件。
+
+## 使用时机
+
+* 用户需要查找文档、表格或演示文稿并进行原地更新
+* 整合存储在 Google Drive 中的计划、追踪器、笔记或客户列表
+* 清理或重构共享电子表格
+* 导入、修复或重新格式化 Google Slides 演示文稿
+* 从文档、表格或幻灯片生成摘要以供决策
+
+## 首选工具界面
+
+使用 Google Drive 作为入口，然后切换到合适的专业工具：
+
+* Google Docs 用于处理文本密集型文档
+* Google Sheets 用于表格工作、公式和图表
+* Google Slides 用于处理演示文稿、导入、模板迁移和清理
+
+不要仅凭文件名猜测结构。先检查。
+
+## 工作流程
+
+### 1. 查找资产
+
+从 Drive 搜索界面开始，定位：
+
+* 确切的文件
+* 相关资产
+* 可能的重复项
+* 最近修改的版本
+
+如果多个文档看起来相似，请通过标题、所有者、修改时间或文件夹进行确认。
+
+### 2. 编辑前检查
+
+在进行更改之前：
+
+* 总结当前结构
+* 识别标签页、标题或幻灯片数量
+* 判断任务是局部清理还是结构性调整
+
+选择能够安全完成工作的最小工具。
+
+### 3. 精确编辑
+
+* 对于文档：使用基于索引的编辑，而非模糊重写
+* 对于表格：在明确的标签页和范围内操作
+* 对于幻灯片：区分内容编辑与视觉清理或模板迁移
+
+如果请求的工作涉及视觉或布局调整，请通过检查和验证进行迭代，而不是进行一次性的盲目更新。
+
+### 4. 保持工作系统整洁
+
+当文件是更大工作流程的一部分时，还需指出：
+
+* 重复的追踪器
+* 过时的演示文稿
+* 过时文档与权威文档
+* 该资产是否应被归档、合并或重命名
+
+## 输出格式
+
+使用：
+
+```text
+资产
+- 文件名
+- 类型
+- 为何选择此文件
+
+当前状态
+- 结构摘要
+- 关键问题或阻碍
+
+操作
+- 已执行或建议的编辑
+
+后续事项
+- 归档 / 合并 / 重复清理 / 下一个待更新文件
+```
+
+## 良好用例
+
+* "找到活跃的规划文档并精简它"
+* "清理这个客户电子表格，并向我展示流失风险行"
+* "将此演示文稿导入 Slides 并使其可展示"
+* "找到当前的追踪器，而不是过时的副本"

docs/zh-CN/skills/healthcare-cdss-patterns/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: healthcare-cdss-patterns
+description: 临床决策支持系统（CDSS）开发模式。药物相互作用检查、剂量验证、临床评分（NEWS2、qSOFA）、警报严重性分类以及集成到电子病历工作流程中。
+origin: Health1 Super Speciality Hospitals — contributed by Dr. Keyur Patel
+version: "1.0.0"
+---
+
+# 医疗CDSS开发模式
+
+构建可集成至EMR工作流的临床决策支持系统的模式。CDSS模块关乎患者安全——对假阴性零容忍。
+
+## 适用场景
+
+* 实现药物相互作用检查
+* 构建剂量验证引擎
+* 实现临床评分系统（NEWS2、qSOFA、APACHE、GCS）
+* 设计异常临床值警报系统
+* 构建带安全校验的用药医嘱录入
+* 结合临床上下文解读检验结果
+
+## 工作原理
+
+CDSS引擎是一个**无副作用的纯函数库**。输入临床数据，输出警报。这使得它完全可测试。
+
+三个核心模块：
+
+1. **`checkInteractions(newDrug, currentMeds, allergies)`** — 检查新药物与现有用药及已知过敏的冲突。返回按严重程度排序的`InteractionAlert[]`。使用`DrugInteractionPair`数据模型。
+2. **`validateDose(drug, dose, route, weight, age, renalFunction)`** — 根据体重、年龄和肾功能调整规则验证处方剂量。返回`DoseValidationResult`。
+3. **`calculateNEWS2(vitals)`** — 基于`NEWS2Input`计算国家早期预警评分2。返回包含总分、风险等级和升级指导的`NEWS2Result`。
+
+```
+EMR UI
+  ↓ (用户输入数据)
+CDSS 引擎（纯函数，无副作用）
+  ├── 药物相互作用检查器
+  ├── 剂量验证器
+  ├── 临床评分（NEWS2、qSOFA 等）
+  └── 警报分类器
+  ↓ (返回警报)
+EMR UI（内联显示警报，严重时阻止操作）
+```
+
+### 药物相互作用检查
+
+```typescript
+interface DrugInteractionPair {
+  drugA: string;           // generic name
+  drugB: string;           // generic name
+  severity: 'critical' | 'major' | 'minor';
+  mechanism: string;
+  clinicalEffect: string;
+  recommendation: string;
+}
+
+function checkInteractions(
+  newDrug: string,
+  currentMedications: string[],
+  allergyList: string[]
+): InteractionAlert[] {
+  if (!newDrug) return [];
+  const alerts: InteractionAlert[] = [];
+  for (const current of currentMedications) {
+    const interaction = findInteraction(newDrug, current);
+    if (interaction) {
+      alerts.push({ severity: interaction.severity, pair: [newDrug, current],
+        message: interaction.clinicalEffect, recommendation: interaction.recommendation });
+    }
+  }
+  for (const allergy of allergyList) {
+    if (isCrossReactive(newDrug, allergy)) {
+      alerts.push({ severity: 'critical', pair: [newDrug, allergy],
+        message: `Cross-reactivity with documented allergy: ${allergy}`,
+        recommendation: 'Do not prescribe without allergy consultation' });
+    }
+  }
+  return alerts.sort((a, b) => severityOrder(a.severity) - severityOrder(b.severity));
+}
+```
+
+相互作用对必须**双向**：若药物A与药物B相互作用，则药物B与药物A相互作用。
+
+### 剂量验证
+
+```typescript
+interface DoseValidationResult {
+  valid: boolean;
+  message: string;
+  suggestedRange: { min: number; max: number; unit: string } | null;
+  factors: string[];
+}
+
+function validateDose(
+  drug: string,
+  dose: number,
+  route: 'oral' | 'iv' | 'im' | 'sc' | 'topical',
+  patientWeight?: number,
+  patientAge?: number,
+  renalFunction?: number
+): DoseValidationResult {
+  const rules = getDoseRules(drug, route);
+  if (!rules) return { valid: true, message: 'No validation rules available', suggestedRange: null, factors: [] };
+  const factors: string[] = [];
+
+  // SAFETY: if rules require weight but weight missing, BLOCK (not pass)
+  if (rules.weightBased) {
+    if (!patientWeight || patientWeight <= 0) {
+      return { valid: false, message: `Weight required for ${drug} (mg/kg drug)`,
+        suggestedRange: null, factors: ['weight_missing'] };
+    }
+    factors.push('weight');
+    const maxDose = rules.maxPerKg * patientWeight;
+    if (dose > maxDose) {
+      return { valid: false, message: `Dose exceeds max for ${patientWeight}kg`,
+        suggestedRange: { min: rules.minPerKg * patientWeight, max: maxDose, unit: rules.unit }, factors };
+    }
+  }
+
+  // Age-based adjustment (when rules define age brackets and age is provided)
+  if (rules.ageAdjusted && patientAge !== undefined) {
+    factors.push('age');
+    const ageMax = rules.getAgeAdjustedMax(patientAge);
+    if (dose > ageMax) {
+      return { valid: false, message: `Exceeds age-adjusted max for ${patientAge}yr`,
+        suggestedRange: { min: rules.typicalMin, max: ageMax, unit: rules.unit }, factors };
+    }
+  }
+
+  // Renal adjustment (when rules define eGFR brackets and eGFR is provided)
+  if (rules.renalAdjusted && renalFunction !== undefined) {
+    factors.push('renal');
+    const renalMax = rules.getRenalAdjustedMax(renalFunction);
+    if (dose > renalMax) {
+      return { valid: false, message: `Exceeds renal-adjusted max for eGFR ${renalFunction}`,
+        suggestedRange: { min: rules.typicalMin, max: renalMax, unit: rules.unit }, factors };
+    }
+  }
+
+  // Absolute max
+  if (dose > rules.absoluteMax) {
+    return { valid: false, message: `Exceeds absolute max ${rules.absoluteMax}${rules.unit}`,
+      suggestedRange: { min: rules.typicalMin, max: rules.absoluteMax, unit: rules.unit },
+      factors: [...factors, 'absolute_max'] };
+  }
+  return { valid: true, message: 'Within range',
+    suggestedRange: { min: rules.typicalMin, max: rules.typicalMax, unit: rules.unit }, factors };
+}
+```
+
+### 临床评分：NEWS2
+
+```typescript
+interface NEWS2Input {
+  respiratoryRate: number; oxygenSaturation: number; supplementalOxygen: boolean;
+  temperature: number; systolicBP: number; heartRate: number;
+  consciousness: 'alert' | 'voice' | 'pain' | 'unresponsive';
+}
+interface NEWS2Result {
+  total: number;           // 0-20
+  risk: 'low' | 'low-medium' | 'medium' | 'high';
+  components: Record<string, number>;
+  escalation: string;
+}
+```
+
+评分表必须严格符合皇家内科医师学会规范。
+
+### 警报严重程度与UI行为
+
+| 严重程度 | UI行为 | 临床医生操作要求 |
+|----------|--------|------------------|
+| 危急 | 阻止操作。不可关闭的模态框。红色。 | 必须记录覆盖原因才能继续 |
+| 主要 | 行内警告横幅。橙色。 | 必须确认后才能继续 |
+| 次要 | 行内信息提示。黄色。 | 仅需知晓，无需操作 |
+
+危急警报**绝不能**自动关闭或实现为Toast通知。覆盖原因必须存储在审计追踪中。
+
+### 测试CDSS（对假阴性零容忍）
+
+```typescript
+describe('CDSS — Patient Safety', () => {
+  INTERACTION_PAIRS.forEach(({ drugA, drugB, severity }) => {
+    it(`detects ${drugA} + ${drugB} (${severity})`, () => {
+      const alerts = checkInteractions(drugA, [drugB], []);
+      expect(alerts.length).toBeGreaterThan(0);
+      expect(alerts[0].severity).toBe(severity);
+    });
+    it(`detects ${drugB} + ${drugA} (reverse)`, () => {
+      const alerts = checkInteractions(drugB, [drugA], []);
+      expect(alerts.length).toBeGreaterThan(0);
+    });
+  });
+  it('blocks mg/kg drug when weight is missing', () => {
+    const result = validateDose('gentamicin', 300, 'iv');
+    expect(result.valid).toBe(false);
+    expect(result.factors).toContain('weight_missing');
+  });
+  it('handles malformed drug data gracefully', () => {
+    expect(() => checkInteractions('', [], [])).not.toThrow();
+  });
+});
+```
+
+通过标准：100%。一次遗漏的相互作用即构成患者安全事件。
+
+### 反模式
+
+* 使CDSS检查变为可选或可跳过且无记录原因
+* 将相互作用检查实现为Toast通知
+* 使用`any`类型处理药物或临床数据
+* 硬编码相互作用对而非使用可维护的数据结构
+* 静默捕获CDSS引擎错误（必须大声暴露失败）
+* 在体重数据缺失时跳过基于体重的验证（必须阻止，而非通过）
+
+## 示例
+
+### 示例1：药物相互作用检查
+
+```typescript
+const alerts = checkInteractions('warfarin', ['aspirin', 'metformin'], ['penicillin']);
+// [{ severity: 'critical', pair: ['warfarin', 'aspirin'],
+//    message: 'Increased bleeding risk', recommendation: 'Avoid combination' }]
+```
+
+### 示例2：剂量验证
+
+```typescript
+const ok = validateDose('paracetamol', 1000, 'oral', 70, 45);
+// { valid: true, suggestedRange: { min: 500, max: 4000, unit: 'mg' } }
+
+const bad = validateDose('paracetamol', 5000, 'oral', 70, 45);
+// { valid: false, message: 'Exceeds absolute max 4000mg' }
+
+const noWeight = validateDose('gentamicin', 300, 'iv');
+// { valid: false, factors: ['weight_missing'] }
+```
+
+### 示例3：NEWS2评分
+
+```typescript
+const result = calculateNEWS2({
+  respiratoryRate: 24, oxygenSaturation: 93, supplementalOxygen: true,
+  temperature: 38.5, systolicBP: 100, heartRate: 110, consciousness: 'voice'
+});
+// { total: 13, risk: 'high', escalation: 'Urgent clinical review. Consider ICU.' }
+```

docs/zh-CN/skills/healthcare-emr-patterns/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: healthcare-emr-patterns
+description: 医疗应用中EMR/EHR的开发模式。临床安全、就诊工作流程、处方生成、临床决策支持集成以及以可访问性为先的医疗数据录入用户界面。
+origin: Health1 Super Speciality Hospitals — contributed by Dr. Keyur Patel
+version: "1.0.0"
+---
+
+# 医疗电子病历开发模式
+
+构建电子病历（EMR）和电子健康档案（EHR）系统的模式。优先考虑患者安全、临床准确性和医生工作效率。
+
+## 使用场景
+
+* 构建患者就诊工作流（主诉、检查、诊断、处方）
+* 实现临床记录（结构化文本 + 自由文本 + 语音转文字）
+* 设计含药物相互作用检查的处方/用药模块
+* 集成临床决策支持系统（CDSS）
+* 构建带参考范围高亮显示的检验结果展示
+* 实现临床数据审计追踪
+* 设计医疗场景下易用的临床数据录入界面
+
+## 工作原理
+
+### 患者安全优先
+
+每个设计决策必须通过以下问题评估："这会对患者造成伤害吗？"
+
+* 药物相互作用**必须**发出警报，不能静默通过
+* 异常检验值**必须**以视觉方式标记
+* 关键生命体征**必须**触发升级工作流
+* 无审计追踪不得修改临床数据
+
+### 单页就诊流程
+
+临床就诊应在单页上垂直流动——无需切换标签页：
+
+```
+患者头部信息（固定显示 — 始终可见）
+├── 人口学信息、过敏史、当前用药
+│
+就诊流程（垂直滚动）
+├── 1. 主诉（结构化模板 + 自由文本）
+├── 2. 现病史
+├── 3. 体格检查（按系统分类）
+├── 4. 生命体征（自动触发临床评分）
+├── 5. 诊断（ICD-10/SNOMED 搜索）
+├── 6. 用药（药品数据库 + 相互作用检查）
+├── 7. 检查（实验室/影像学医嘱）
+├── 8. 计划与随访
+└── 9. 签名 / 锁定 / 打印
+```
+
+### 智能模板系统
+
+```typescript
+interface ClinicalTemplate {
+  id: string;
+  name: string;             // e.g., "Chest Pain"
+  chips: string[];          // clickable symptom chips
+  requiredFields: string[]; // mandatory data points
+  redFlags: string[];       // triggers non-dismissable alert
+  icdSuggestions: string[]; // pre-mapped diagnosis codes
+}
+```
+
+任何模板中的危险信号必须触发可见且不可关闭的警报——而非通知提示。
+
+### 用药安全模式
+
+```
+用户选择药物
+  → 检查当前用药是否存在相互作用
+  → 检查就诊用药是否存在相互作用
+  → 检查患者过敏史
+  → 根据体重/年龄/肾功能验证剂量
+  → 若为严重相互作用：完全阻止开药
+  → 临床医生必须记录覆盖理由才能继续操作
+  → 若为重大相互作用：显示警告，要求确认
+  → 将所有警报和覆盖理由记录在审计追踪中
+```
+
+关键相互作用**默认阻止开药**。临床医生必须明确覆盖，并在审计追踪中记录原因。系统绝不允许静默通过关键相互作用。
+
+### 锁定就诊模式
+
+临床就诊一旦签署：
+
+* 不允许编辑——仅可添加附录（独立的关联记录）
+* 原始记录和附录均显示在患者时间线中
+* 审计追踪记录签署人、签署时间及所有附录记录
+
+### 临床数据界面模式
+
+**生命体征显示：** 当前值带正常范围高亮（绿/黄/红），与上次对比的趋势箭头，自动计算的临床评分（NEWS2、qSOFA），内联升级指导。
+
+**检验结果展示：** 正常范围高亮，与上次值对比，关键值带不可关闭警报，采集/分析时间戳，待处理医嘱及预期周转时间。
+
+**处方PDF：** 一键生成，包含患者基本信息、过敏史、诊断、药物详情（通用名+商品名、剂量、给药途径、频率、疗程）、临床医生签名栏。
+
+### 医疗场景无障碍设计
+
+医疗界面的要求比典型网页应用更严格：
+
+* 最小对比度4.5:1（WCAG AA）——临床医生在不同光照条件下工作
+* 大触摸目标（最小44x44px）——适用于戴手套或快速操作
+* 键盘导航——供快速录入数据的熟练用户使用
+* 不使用纯颜色指示——始终将颜色与文字/图标配对（色盲临床医生）
+* 所有表单字段带屏幕阅读器标签
+* 临床警报不使用自动消失的提示——临床医生必须主动确认
+
+### 反模式
+
+* 在浏览器localStorage中存储临床数据
+* 药物相互作用检查静默失败
+* 关键临床警报使用可关闭提示
+* 基于标签页的就诊界面导致临床工作流碎片化
+* 允许编辑已签署/锁定的就诊记录
+* 无审计追踪显示临床数据
+* 使用`any`类型处理临床数据结构
+
+## 示例
+
+### 示例1：患者就诊流程
+
+```
+医生为患者 #4521 开启接诊
+  → 固定头部显示："Rajesh M, 58岁, 男性, 过敏史: 青霉素, 当前用药: 二甲双胍 500mg"
+  → 主诉：选择"胸痛"模板
+    → 点击标签："胸骨后", "向左臂放射", "压榨性"
+    → 红色预警"压榨性胸骨后胸痛"触发不可关闭的警报
+  → 检查：心血管系统 — "S1 S2 正常，无杂音"
+  → 生命体征：心率 110, 血压 90/60, 血氧饱和度 94%
+    → NEWS2 自动计算：评分 8, 风险 高, 显示升级警报
+  → 诊断：搜索"ACS" → 选择 ICD-10 I21.9
+  → 用药：选择阿司匹林 300mg
+    → CDSS 检查与二甲双胍的相互作用：无相互作用
+  → 签署接诊 → 锁定，此后仅可添加补充说明
+```
+
+### 示例2：用药安全工作流
+
+```
+医生为患者 #4521 开具华法林处方
+  → CDSS 检测到：华法林 + 阿司匹林 = 严重相互作用
+  → 用户界面：红色不可关闭的模态框阻止开药
+  → 医生点击“输入理由并覆盖”
+  → 输入：“获益大于风险 — 已监测 INR 方案”
+  → 覆盖理由及警报记录在审计追踪中
+  → 处方在记录覆盖后继续执行
+```
+
+### 示例3：锁定就诊 + 附录
+
+```
+Encounter #E-2024-0891 signed by Dr. Shah at 14:30
+  → All fields locked — no edit buttons visible
+  → "Add Addendum" button available
+  → Dr. Shah clicks addendum, adds: "Lab results received — Troponin elevated"
+  → New record E-2024-0891-A1 linked to original
+  → Timeline shows both: original encounter + addendum with timestamps
+```

docs/zh-CN/skills/healthcare-eval-harness/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: healthcare-eval-harness
+description: 用于医疗应用部署的患者安全评估工具。针对CDSS准确性、PHI暴露、临床工作流完整性和集成合规性的自动化测试套件。在安全故障时阻止部署。
+origin: Health1 Super Speciality Hospitals — contributed by Dr. Keyur Patel
+version: "1.0.0"
+---
+
+# 医疗评估框架 — 患者安全验证
+
+医疗应用部署的自动化验证系统。单个严重故障将阻止部署。患者安全不容妥协。
+
+> **注意：** 示例使用 Jest 作为参考测试运行器。请根据您的框架（Vitest、pytest、PHPUnit 等）调整命令——测试类别和通过阈值与框架无关。
+
+## 使用场景
+
+* 部署任何 EMR/EHR 应用之前
+* 修改 CDSS 逻辑（药物相互作用、剂量验证、评分）之后
+* 更改涉及患者数据的数据库模式之后
+* 修改身份验证或访问控制之后
+* 配置医疗应用 CI/CD 流水线期间
+* 解决临床模块合并冲突之后
+
+## 工作原理
+
+评估框架按顺序运行五个测试类别。前三个（CDSS 准确性、PHI 暴露、数据完整性）是严重关卡，要求 100% 通过率——单个故障即阻止部署。其余两个（临床工作流、集成）是高优先级关卡，要求 95% 以上通过率。
+
+每个类别对应一个 Jest 测试路径模式。CI 流水线使用 `--bail`（首次失败即停止）运行严重关卡，并使用 `--coverage --coverageThreshold` 强制执行覆盖率阈值。
+
+### 评估类别
+
+**1. CDSS 准确性（严重 — 要求 100%）**
+
+测试所有临床决策支持逻辑：药物相互作用对（双向）、剂量验证规则、临床评分与发布规范的对比、无假阴性、无静默故障。
+
+```bash
+npx jest --testPathPattern='tests/cdss' --bail --ci --coverage
+```
+
+**2. PHI 暴露（严重 — 要求 100%）**
+
+测试受保护健康信息泄露：API 错误响应、控制台输出、URL 参数、浏览器存储、跨机构隔离、未认证访问、服务角色密钥缺失。
+
+```bash
+npx jest --testPathPattern='tests/security/phi' --bail --ci
+```
+
+**3. 数据完整性（严重 — 要求 100%）**
+
+测试临床数据安全：锁定就诊记录、审计追踪条目、级联删除保护、并发编辑处理、无孤立记录。
+
+```bash
+npx jest --testPathPattern='tests/data-integrity' --bail --ci
+```
+
+**4. 临床工作流（高优先级 — 要求 95% 以上）**
+
+测试端到端流程：就诊生命周期、模板渲染、用药集、药物/诊断搜索、处方 PDF、红色警报。
+
+```bash
+tmp_json=$(mktemp)
+npx jest --testPathPattern='tests/clinical' --ci --json --outputFile="$tmp_json" || true
+total=$(jq '.numTotalTests // 0' "$tmp_json")
+passed=$(jq '.numPassedTests // 0' "$tmp_json")
+if [ "$total" -eq 0 ]; then
+  echo "No clinical tests found" >&2
+  exit 1
+fi
+rate=$(echo "scale=2; $passed * 100 / $total" | bc)
+echo "Clinical pass rate: ${rate}% ($passed/$total)"
+```
+
+**5. 集成合规性（高优先级 — 要求 95% 以上）**
+
+测试外部系统：HL7 消息解析（v2.x）、FHIR 验证、实验室结果映射、格式错误消息处理。
+
+```bash
+tmp_json=$(mktemp)
+npx jest --testPathPattern='tests/integration' --ci --json --outputFile="$tmp_json" || true
+total=$(jq '.numTotalTests // 0' "$tmp_json")
+passed=$(jq '.numPassedTests // 0' "$tmp_json")
+if [ "$total" -eq 0 ]; then
+  echo "No integration tests found" >&2
+  exit 1
+fi
+rate=$(echo "scale=2; $passed * 100 / $total" | bc)
+echo "Integration pass rate: ${rate}% ($passed/$total)"
+```
+
+### 通过/失败矩阵
+
+| 类别 | 阈值 | 失败时操作 |
+|----------|-----------|------------|
+| CDSS 准确性 | 100% | **阻止部署** |
+| PHI 暴露 | 100% | **阻止部署** |
+| 数据完整性 | 100% | **阻止部署** |
+| 临床工作流 | 95% 以上 | 警告，允许经审查后部署 |
+| 集成 | 95% 以上 | 警告，允许经审查后部署 |
+
+### CI/CD 集成
+
+```yaml
+name: Healthcare Safety Gate
+on: [push, pull_request]
+
+jobs:
+  safety-gate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+      - run: npm ci
+
+      # CRITICAL gates — 100% required, bail on first failure
+      - name: CDSS Accuracy
+        run: npx jest --testPathPattern='tests/cdss' --bail --ci --coverage --coverageThreshold='{"global":{"branches":80,"functions":80,"lines":80}}'
+
+      - name: PHI Exposure Check
+        run: npx jest --testPathPattern='tests/security/phi' --bail --ci
+
+      - name: Data Integrity
+        run: npx jest --testPathPattern='tests/data-integrity' --bail --ci
+
+      # HIGH gates — 95%+ required, custom threshold check
+      # HIGH gates — 95%+ required
+      - name: Clinical Workflows
+        run: |
+          TMP_JSON=$(mktemp)
+          npx jest --testPathPattern='tests/clinical' --ci --json --outputFile="$TMP_JSON" || true
+          TOTAL=$(jq '.numTotalTests // 0' "$TMP_JSON")
+          PASSED=$(jq '.numPassedTests // 0' "$TMP_JSON")
+          if [ "$TOTAL" -eq 0 ]; then
+            echo "::error::No clinical tests found"; exit 1
+          fi
+          RATE=$(echo "scale=2; $PASSED * 100 / $TOTAL" | bc)
+          echo "Pass rate: ${RATE}% ($PASSED/$TOTAL)"
+          if (( $(echo "$RATE < 95" | bc -l) )); then
+            echo "::warning::Clinical pass rate ${RATE}% below 95%"
+          fi
+
+      - name: Integration Compliance
+        run: |
+          TMP_JSON=$(mktemp)
+          npx jest --testPathPattern='tests/integration' --ci --json --outputFile="$TMP_JSON" || true
+          TOTAL=$(jq '.numTotalTests // 0' "$TMP_JSON")
+          PASSED=$(jq '.numPassedTests // 0' "$TMP_JSON")
+          if [ "$TOTAL" -eq 0 ]; then
+            echo "::error::No integration tests found"; exit 1
+          fi
+          RATE=$(echo "scale=2; $PASSED * 100 / $TOTAL" | bc)
+          echo "Pass rate: ${RATE}% ($PASSED/$TOTAL)"
+          if (( $(echo "$RATE < 95" | bc -l) )); then
+            echo "::warning::Integration pass rate ${RATE}% below 95%"
+          fi
+```
+
+### 反模式
+
+* 跳过 CDSS 测试，因为"上次通过了"
+* 将严重关卡阈值设为低于 100%
+* 在严重测试套件中使用 `--no-bail`
+* 在集成测试中模拟 CDSS 引擎（必须测试真实逻辑）
+* 安全关卡为红色时仍允许部署
+* 在 CDSS 套件中运行测试时不使用 `--coverage`
+
+## 示例
+
+### 示例 1：本地运行所有严重关卡
+
+```bash
+npx jest --testPathPattern='tests/cdss' --bail --ci --coverage && \
+npx jest --testPathPattern='tests/security/phi' --bail --ci && \
+npx jest --testPathPattern='tests/data-integrity' --bail --ci
+```
+
+### 示例 2：检查高优先级关卡通过率
+
+```bash
+tmp_json=$(mktemp)
+npx jest --testPathPattern='tests/clinical' --ci --json --outputFile="$tmp_json" || true
+jq '{
+  passed: (.numPassedTests // 0),
+  total: (.numTotalTests // 0),
+  rate: (if (.numTotalTests // 0) == 0 then 0 else ((.numPassedTests // 0) / (.numTotalTests // 1) * 100) end)
+}' "$tmp_json"
+# Expected: { "passed": 21, "total": 22, "rate": 95.45 }
+```
+
+### 示例 3：评估报告
+
+```
+## 医疗评估：2026-03-27 [commit abc1234]
+
+### 患者安全：通过
+
+| 类别 | 测试数 | 通过 | 失败 | 状态 |
+|----------|-------|------|------|--------|
+| CDSS 准确性 | 39 | 39 | 0 | 通过 |
+| PHI 暴露 | 8 | 8 | 0 | 通过 |
+| 数据完整性 | 12 | 12 | 0 | 通过 |
+| 临床工作流 | 22 | 21 | 1 | 95.5% 通过 |
+| 集成 | 6 | 6 | 0 | 通过 |
+
+### 覆盖率：84%（目标：80%以上）
+### 结论：可安全部署
+```

docs/zh-CN/skills/healthcare-phi-compliance/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: healthcare-phi-compliance
+description: 医疗应用中受保护健康信息（PHI）和个人身份信息（PII）的合规模式。涵盖数据分类、访问控制、审计追踪、加密及常见泄露途径。
+origin: Health1 Super Speciality Hospitals — contributed by Dr. Keyur Patel
+version: "1.0.0"
+---
+
+# 医疗 PHI/PII 合规模式
+
+用于保护医疗应用中患者数据、临床医生数据和财务数据的模式。适用于 HIPAA（美国）、DISHA（印度）、GDPR（欧盟）以及通用医疗数据保护。
+
+## 何时使用
+
+* 构建任何涉及患者记录的功能
+* 为临床系统实施访问控制或身份验证
+* 设计医疗数据的数据库模式
+* 构建返回患者或临床医生数据的 API
+* 实施审计追踪或日志记录
+* 审查代码中的数据泄露漏洞
+* 为多租户医疗系统设置行级安全（RLS）
+
+## 工作原理
+
+医疗数据保护在三个层面运作：**分类**（什么是敏感数据）、**访问控制**（谁能查看）和**审计**（谁查看了数据）。
+
+### 数据分类
+
+**PHI（受保护健康信息）** — 任何能够识别患者身份且与其健康相关的数据：患者姓名、出生日期、地址、电话、电子邮件、国家身份证号码（SSN、Aadhaar、NHS 号码）、病历号、诊断、药物、化验结果、影像资料、保险单和理赔详情、预约和入院记录，或上述任意组合。
+
+**医疗系统中的 PII（非患者敏感数据）**：临床医生/员工个人详细信息、医生收费结构和支付金额、员工薪资和银行信息、供应商付款信息。
+
+### 访问控制：行级安全
+
+```sql
+ALTER TABLE patients ENABLE ROW LEVEL SECURITY;
+
+-- Scope access by facility
+CREATE POLICY "staff_read_own_facility"
+  ON patients FOR SELECT TO authenticated
+  USING (facility_id IN (
+    SELECT facility_id FROM staff_assignments
+    WHERE user_id = auth.uid() AND role IN ('doctor','nurse','lab_tech','admin')
+  ));
+
+-- Audit log: insert-only (tamper-proof)
+CREATE POLICY "audit_insert_only" ON audit_log FOR INSERT
+  TO authenticated WITH CHECK (user_id = auth.uid());
+CREATE POLICY "audit_no_modify" ON audit_log FOR UPDATE USING (false);
+CREATE POLICY "audit_no_delete" ON audit_log FOR DELETE USING (false);
+```
+
+### 审计追踪
+
+每次 PHI 访问或修改都必须记录：
+
+```typescript
+interface AuditEntry {
+  timestamp: string;
+  user_id: string;
+  patient_id: string;
+  action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';
+  resource_type: string;
+  resource_id: string;
+  changes?: { before: object; after: object };
+  ip_address: string;
+  session_id: string;
+}
+```
+
+### 常见泄露途径
+
+**错误消息：** 切勿在发送给客户端的错误消息中包含患者身份识别数据。仅在服务器端记录详细信息。
+
+**控制台输出：** 切勿记录完整的患者对象。使用不透明的内部记录 ID（UUID）——而不是病历号、国家身份证号或姓名。
+
+**URL 参数：** 切勿在可能出现在日志或浏览器历史记录中的查询字符串或路径段中包含患者身份识别数据。仅使用不透明的 UUID。
+
+**浏览器存储：** 切勿在 localStorage 或 sessionStorage 中存储 PHI。仅在内存中保留 PHI，按需获取。
+
+**服务角色密钥：** 切勿在客户端代码中使用 service\_role 密钥。始终使用匿名/可发布密钥，并让 RLS 强制执行访问控制。
+
+**日志和监控：** 切勿记录完整的患者记录。仅使用不透明的记录 ID（而不是病历号）。在发送到错误跟踪服务之前，清理堆栈跟踪。
+
+### 数据库模式标记
+
+在模式级别标记 PHI/PII 列：
+
+```sql
+COMMENT ON COLUMN patients.name IS 'PHI: patient_name';
+COMMENT ON COLUMN patients.dob IS 'PHI: date_of_birth';
+COMMENT ON COLUMN patients.aadhaar IS 'PHI: national_id';
+COMMENT ON COLUMN doctor_payouts.amount IS 'PII: financial';
+```
+
+### 部署检查清单
+
+每次部署前：
+
+* 错误消息或堆栈跟踪中无 PHI
+* console.log/console.error 中无 PHI
+* URL 参数中无 PHI
+* 浏览器存储中无 PHI
+* 客户端代码中无 service\_role 密钥
+* 所有 PHI/PII 表已启用 RLS
+* 所有数据修改均有审计追踪
+* 已配置会话超时
+* 所有 PHI 端点均需 API 身份验证
+* 已验证跨机构数据隔离
+
+## 示例
+
+### 示例 1：安全与不安全的错误处理
+
+```typescript
+// BAD — leaks PHI in error
+throw new Error(`Patient ${patient.name} not found in ${patient.facility}`);
+
+// GOOD — generic error, details logged server-side with opaque IDs only
+logger.error('Patient lookup failed', { recordId: patient.id, facilityId });
+throw new Error('Record not found');
+```
+
+### 示例 2：多机构隔离的 RLS 策略
+
+```sql
+-- Doctor at Facility A cannot see Facility B patients
+CREATE POLICY "facility_isolation"
+  ON patients FOR SELECT TO authenticated
+  USING (facility_id IN (
+    SELECT facility_id FROM staff_assignments WHERE user_id = auth.uid()
+  ));
+
+-- Test: login as doctor-facility-a, query facility-b patients
+-- Expected: 0 rows returned
+```
+
+### 示例 3：安全日志记录
+
+```typescript
+// BAD — logs identifiable patient data
+console.log('Processing patient:', patient);
+
+// GOOD — logs only opaque internal record ID
+console.log('Processing record:', patient.id);
+// Note: even patient.id should be an opaque UUID, not a medical record number
+```

docs/zh-CN/skills/hermes-imports/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: hermes-imports
+description: 将本地 Hermes 操作员工作流转换为经过清理的 ECC 技能和发布包工件。在准备将 Hermes 工作流用于公共 ECC 重用而不泄露私有工作区状态、凭据或仅本地路径时使用。
+origin: ECC
+---
+
+# Hermes 导入
+
+当需要将重复的 Hermes 工作流转化为可在 ECC 中安全发布的内容时，使用此技能。
+
+Hermes 是操作员外壳。ECC 是可复用工作流层。导入操作应将稳定模式从 Hermes 迁移至 ECC，同时避免移动私有状态。
+
+## 使用时机
+
+* Hermes 工作流重复次数足够多，已具备可复用性
+* 本地操作员提示词需要升级为公共 ECC 技能
+* 启动、内容、研究或工程工作流需要经过净化的交接文档
+* 工作流中包含本地路径、凭证、个人数据集或私有账户名，发布前必须移除
+
+## 导入规则
+
+* 将本地路径转换为仓库相对路径或占位符
+* 用角色标签（如 `operator`、`default profile`、`workspace owner`）替换真实账户名
+* 仅通过提供商名称描述凭证要求
+* 保持示例简洁且可操作
+* 不得发布原始工作区导出文件、令牌、OAuth 文件、健康数据、CRM 数据或财务数据
+* 若工作流依赖私有状态才能理解，则保留在本地
+
+## 净化检查清单
+
+提交导入的工作流前，需扫描：
+
+* 绝对路径（如 `/Users/...`）
+* `~/.hermes` 路径（除非文档明确说明本地设置）
+* API 密钥、令牌、Cookie、OAuth 文件或 Bearer 字符串
+* 电话号码、私人邮箱地址及个人联系人图谱
+* 尚未公开的客户名称、家族名称或账户名
+* 收入、健康或 CRM 详情
+* 包含私有系统工具输出的原始日志
+
+## 转换模式
+
+1. 识别可重复的操作员循环
+2. 剥离私有输入与输出
+3. 将本地路径重写为仓库相对路径示例
+4. 将一次性指令转化为 `When To Use` 章节及简短流程
+5. 添加具体输出要求
+6. 在发起 PR 前执行密钥与本地路径扫描
+
+## 示例：启动交接
+
+本地 Hermes 提示词：
+
+```text
+读取我的本地工作区文件并最终确定发布文案。
+```
+
+ECC 安全版本：
+
+```text
+使用 docs/releases/<version>/ 下的公开发布包。
+返回一条 X 帖子、一条 LinkedIn 帖子、一份录制检查清单以及缺失资源列表。
+```
+
+## 示例：静默时段操作员任务
+
+本地 Hermes 任务：
+
+```text
+夜间运行我的私人收件箱、财务和内容检查。
+```
+
+ECC 安全版本：
+
+```text
+描述调度器策略、静默时段、升级规则以及检查类别。请勿包含私有数据源或凭据。
+```
+
+## 输出契约
+
+返回：
+
+* 候选 ECC 技能名称
+* 净化后的工作流摘要
+* 必需的公共输入
+* 已移除的私有输入
+* 剩余风险
+* 应创建或更新的文件

docs/zh-CN/skills/hexagonal-architecture/SKILL.md

@@ -0,0 +1,276 @@
+---
+name: hexagonal-architecture
+description: 设计、实现并重构端口与适配器系统，具有清晰的领域边界、依赖反转以及跨 TypeScript、Java、Kotlin 和 Go 服务的可测试用例编排。
+origin: ECC
+---
+
+# 六边形架构
+
+六边形架构（端口与适配器）使业务逻辑独立于框架、传输层和持久化细节。核心应用依赖于抽象端口，而适配器在边缘实现这些端口。
+
+## 适用场景
+
+* 构建需要长期可维护性和可测试性的新功能。
+* 重构分层或框架密集型代码，其中领域逻辑与I/O关注点混杂。
+* 为同一用例支持多种接口（HTTP、CLI、队列工作器、定时任务）。
+* 替换基础设施（数据库、外部API、消息总线）而无需重写业务规则。
+
+当需求涉及边界、领域驱动设计、重构紧耦合服务，或将应用逻辑与特定库解耦时，使用此技能。
+
+## 核心概念
+
+* **领域模型**：业务规则和实体/值对象。无框架导入。
+* **用例（应用层）**：编排领域行为和工作流步骤。
+* **入站端口**：描述应用能力的契约（命令/查询/用例接口）。
+* **出站端口**：应用所需依赖的契约（仓库、网关、事件发布器、时钟、UUID等）。
+* **适配器**：端口的基础设施和交付实现（HTTP控制器、数据库仓库、队列消费者、SDK封装器）。
+* **组合根**：将具体适配器绑定到用例的单一连接位置。
+
+出站端口接口通常位于应用层（仅当抽象真正属于领域层时才位于领域层），而基础设施适配器实现它们。
+
+依赖方向始终向内：
+
+* 适配器 -> 应用/领域
+* 应用 -> 端口接口（入站/出站契约）
+* 领域 -> 仅领域抽象（无框架或基础设施依赖）
+* 领域 -> 无外部依赖
+
+## 工作原理
+
+### 步骤1：建模用例边界
+
+定义具有清晰输入和输出DTO的单个用例。将传输细节（Express `req`、GraphQL `context`、任务负载包装器）保持在此边界之外。
+
+### 步骤2：首先定义出站端口
+
+将每个副作用识别为端口：
+
+* 持久化（`UserRepositoryPort`）
+* 外部调用（`BillingGatewayPort`）
+* 横切关注点（`LoggerPort`、`ClockPort`）
+
+端口应建模能力，而非技术。
+
+### 步骤3：使用纯编排实现用例
+
+用例类/函数通过构造函数/参数接收端口。它验证应用层不变量，协调领域规则，并返回纯数据结构。
+
+### 步骤4：在边缘构建适配器
+
+* 入站适配器将协议输入转换为用例输入。
+* 出站适配器将应用契约映射到具体API/ORM/查询构建器。
+* 映射保持在适配器中，而非用例内部。
+
+### 步骤5：在组合根中连接所有组件
+
+实例化适配器，然后将其注入用例。保持此连接集中化，以避免隐藏的服务定位器行为。
+
+### 步骤6：按边界测试
+
+* 使用伪造端口对用例进行单元测试。
+* 使用真实基础设施依赖对适配器进行集成测试。
+* 通过入站适配器对面向用户的流程进行端到端测试。
+
+## 架构图
+
+```mermaid
+flowchart LR
+  Client["Client (HTTP/CLI/Worker)"] --> InboundAdapter["Inbound Adapter"]
+  InboundAdapter -->|"calls"| UseCase["UseCase (Application Layer)"]
+  UseCase -->|"uses"| OutboundPort["OutboundPort (Interface)"]
+  OutboundAdapter["Outbound Adapter"] -->|"implements"| OutboundPort
+  OutboundAdapter --> ExternalSystem["DB/API/Queue"]
+  UseCase --> DomainModel["DomainModel"]
+```
+
+## 建议的模块布局
+
+使用以功能为先的组织方式，并带有显式边界：
+
+```text
+src/
+  features/
+    orders/
+      domain/
+        Order.ts
+        OrderPolicy.ts
+      application/
+        ports/
+          inbound/
+            CreateOrder.ts
+          outbound/
+            OrderRepositoryPort.ts
+            PaymentGatewayPort.ts
+        use-cases/
+          CreateOrderUseCase.ts
+      adapters/
+        inbound/
+          http/
+            createOrderRoute.ts
+        outbound/
+          postgres/
+            PostgresOrderRepository.ts
+          stripe/
+            StripePaymentGateway.ts
+      composition/
+        ordersContainer.ts
+```
+
+## TypeScript 示例
+
+### 端口定义
+
+```typescript
+export interface OrderRepositoryPort {
+  save(order: Order): Promise<void>;
+  findById(orderId: string): Promise<Order | null>;
+}
+
+export interface PaymentGatewayPort {
+  authorize(input: { orderId: string; amountCents: number }): Promise<{ authorizationId: string }>;
+}
+```
+
+### 用例
+
+```typescript
+type CreateOrderInput = {
+  orderId: string;
+  amountCents: number;
+};
+
+type CreateOrderOutput = {
+  orderId: string;
+  authorizationId: string;
+};
+
+export class CreateOrderUseCase {
+  constructor(
+    private readonly orderRepository: OrderRepositoryPort,
+    private readonly paymentGateway: PaymentGatewayPort
+  ) {}
+
+  async execute(input: CreateOrderInput): Promise<CreateOrderOutput> {
+    const order = Order.create({ id: input.orderId, amountCents: input.amountCents });
+
+    const auth = await this.paymentGateway.authorize({
+      orderId: order.id,
+      amountCents: order.amountCents,
+    });
+
+    // markAuthorized returns a new Order instance; it does not mutate in place.
+    const authorizedOrder = order.markAuthorized(auth.authorizationId);
+    await this.orderRepository.save(authorizedOrder);
+
+    return {
+      orderId: order.id,
+      authorizationId: auth.authorizationId,
+    };
+  }
+}
+```
+
+### 出站适配器
+
+```typescript
+export class PostgresOrderRepository implements OrderRepositoryPort {
+  constructor(private readonly db: SqlClient) {}
+
+  async save(order: Order): Promise<void> {
+    await this.db.query(
+      "insert into orders (id, amount_cents, status, authorization_id) values ($1, $2, $3, $4)",
+      [order.id, order.amountCents, order.status, order.authorizationId]
+    );
+  }
+
+  async findById(orderId: string): Promise<Order | null> {
+    const row = await this.db.oneOrNone("select * from orders where id = $1", [orderId]);
+    return row ? Order.rehydrate(row) : null;
+  }
+}
+```
+
+### 组合根
+
+```typescript
+export const buildCreateOrderUseCase = (deps: { db: SqlClient; stripe: StripeClient }) => {
+  const orderRepository = new PostgresOrderRepository(deps.db);
+  const paymentGateway = new StripePaymentGateway(deps.stripe);
+
+  return new CreateOrderUseCase(orderRepository, paymentGateway);
+};
+```
+
+## 多语言映射
+
+在不同生态系统中使用相同的边界规则；仅语法和连接方式发生变化。
+
+* **TypeScript/JavaScript**
+  * 端口：`application/ports/*` 作为接口/类型。
+  * 用例：带有构造函数/参数注入的类/函数。
+  * 适配器：`adapters/inbound/*`、`adapters/outbound/*`。
+  * 组合：显式工厂/容器模块（无隐藏全局变量）。
+* **Java**
+  * 包：`domain`、`application.port.in`、`application.port.out`、`application.usecase`、`adapter.in`、`adapter.out`。
+  * 端口：`application.port.*` 中的接口。
+  * 用例：普通类（Spring `@Service` 是可选的，非必需）。
+  * 组合：Spring配置或手动连接类；将连接逻辑保持在领域/用例类之外。
+* **Kotlin**
+  * 模块/包镜像Java的拆分（`domain`、`application.port`、`application.usecase`、`adapter`）。
+  * 端口：Kotlin接口。
+  * 用例：带有构造函数注入的类（Koin/Dagger/Spring/手动）。
+  * 组合：模块定义或专用组合函数；避免服务定位器模式。
+* **Go**
+  * 包：`internal/<feature>/domain`、`application`、`ports`、`adapters/inbound`、`adapters/outbound`。
+  * 端口：由消费应用包拥有的小型接口。
+  * 用例：带有接口字段和显式 `New...` 构造函数的结构体。
+  * 组合：在 `cmd/<app>/main.go` 中连接（或专用连接包），保持构造函数显式。
+
+## 应避免的反模式
+
+* 领域实体导入ORM模型、Web框架类型或SDK客户端。
+* 用例直接从 `req`、`res` 或队列元数据读取。
+* 从用例直接返回数据库行，未经领域/应用映射。
+* 让适配器直接相互调用，而非通过用例端口流转。
+* 将依赖连接分散到多个文件中，使用隐藏的全局单例。
+
+## 迁移手册
+
+1. 选择一个垂直切片（单个端点/任务），该切片频繁变更且带来痛苦。
+2. 提取具有显式输入/输出类型的用例边界。
+3. 围绕现有基础设施调用引入出站端口。
+4. 将编排逻辑从控制器/服务移动到用例中。
+5. 保留旧适配器，但使其委托给新用例。
+6. 围绕新边界添加测试（单元测试 + 适配器集成测试）。
+7. 逐个切片重复；避免完全重写。
+
+### 重构现有系统
+
+* **绞杀者模式**：保留当前端点，一次将一个用例路由到新的端口/适配器。
+* **无大爆炸式重写**：按功能切片迁移，并通过特征化测试保持行为。
+* **先建外观**：在替换内部实现之前，将遗留服务包装在出站端口后面。
+* **组合冻结**：尽早集中连接，使新依赖不会泄漏到领域/用例层。
+* **切片选择规则**：优先处理高变更频率、低影响范围的流程。
+* **回滚路径**：为每个迁移的切片保留可逆开关或路由切换，直到生产行为得到验证。
+
+## 测试指南（相同的六边形边界）
+
+* **领域测试**：将实体/值对象作为纯业务规则进行测试（无模拟，无框架设置）。
+* **用例单元测试**：使用出站端口的伪造/桩件测试编排；断言业务结果和端口交互。
+* **出站适配器契约测试**：在端口级别定义共享契约套件，并针对每个适配器实现运行。
+* **入站适配器测试**：验证协议映射（HTTP/CLI/队列负载到用例输入，以及输出/错误映射回协议）。
+* **适配器集成测试**：针对真实基础设施（数据库/API/队列）运行，测试序列化、模式/查询行为、重试和超时。
+* **端到端测试**：覆盖关键用户旅程，通过入站适配器 -> 用例 -> 出站适配器。
+* **重构安全性**：在提取之前添加特征化测试；保持它们直到新边界行为稳定且等价。
+
+## 最佳实践清单
+
+* 领域和应用层仅导入内部类型和端口。
+* 每个外部依赖都由一个出站端口表示。
+* 验证发生在边界处（入站适配器 + 用例不变量）。
+* 使用不可变转换（返回新值/实体，而非修改共享状态）。
+* 错误在边界间进行转换（基础设施错误 -> 应用/领域错误）。
+* 组合根是显式的且易于审计。
+* 用例可通过简单的内存伪造端口进行测试。
+* 重构从具有行为保持测试的一个垂直切片开始。
+* 语言/框架特定内容保持在适配器中，绝不进入领域规则。

docs/zh-CN/skills/hipaa-compliance/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: hipaa-compliance
+description: 针对医疗隐私和安全工作的HIPAA特定入口点。当任务明确围绕HIPAA、PHI处理、受保实体、BAA、违规态势或美国医疗合规要求时使用。
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# HIPAA 合规
+
+当任务明确涉及美国医疗合规时，以此作为 HIPAA 专用入口。此技能刻意保持精简和规范：
+
+* `healthcare-phi-compliance` 仍是处理 PHI/PII、数据分类、审计日志、加密和泄露防护的主要实施技能。
+* `healthcare-reviewer` 仍是当代码、架构或产品行为需要医疗感知的二次审查时的专业审核者。
+* `security-review` 仍适用于通用认证、输入处理、密钥、API 和部署加固。
+
+## 使用时机
+
+* 请求明确提及 HIPAA、PHI、受保实体、业务伙伴或 BAA
+* 构建或审查存储、处理、导出或传输 PHI 的美国医疗软件
+* 评估日志记录、分析、LLM 提示、存储或支持工作流是否产生 HIPAA 暴露风险
+* 设计面向患者或临床医生的系统时，需关注最小必要访问和可审计性
+
+## 工作原理
+
+将 HIPAA 视为覆盖在更广泛的医疗隐私技能之上的叠加层：
+
+1. 从 `healthcare-phi-compliance` 开始，获取具体的实施规则。
+2. 应用 HIPAA 专用决策门：
+   * 这些数据是否为 PHI？
+   * 该行为者是否为受保实体或业务伙伴？
+   * 供应商或模型提供商在接触数据前是否需要 BAA？
+   * 访问权限是否限制在最小必要范围内？
+   * 读/写/导出事件是否可审计？
+3. 如果任务影响患者安全、临床工作流或受监管的生产架构，则升级至 `healthcare-reviewer`。
+
+## HIPAA 专用防护栏
+
+* 切勿将 PHI 置于日志、分析事件、崩溃报告、提示或客户端可见的错误字符串中。
+* 切勿在 URL、浏览器存储、截图或复制的示例负载中暴露 PHI。
+* 要求对 PHI 的读写操作进行认证访问、范围授权并保留审计追踪。
+* 默认将第三方 SaaS、可观测性、支持工具和 LLM 提供商视为禁止状态，直至明确其 BAA 状态和数据边界。
+* 遵循最小必要访问原则：正确的用户应仅看到完成任务所需的最小 PHI 片段。
+* 优先使用不透明的内部 ID，而非姓名、病历号、电话号码、地址或其他标识符。
+
+## 示例
+
+### 示例 1：以 HIPAA 为框架的产品需求
+
+用户请求：
+
+> 为我们的临床医生仪表板添加 AI 生成的就诊摘要。我们服务美国诊所，需保持 HIPAA 合规。
+
+响应模式：
+
+* 激活 `hipaa-compliance`
+* 使用 `healthcare-phi-compliance` 审查 PHI 流动、日志记录、存储和提示边界
+* 在发送任何 PHI 前，验证摘要生成提供商是否受 BAA 覆盖
+* 如果摘要影响临床决策，则升级至 `healthcare-reviewer`
+
+### 示例 2：供应商/工具决策
+
+用户请求：
+
+> 我们可以将支持对话记录和患者消息发送到分析平台吗？
+
+响应模式：
+
+* 假设这些消息可能包含 PHI
+* 除非分析供应商已获批准处理 HIPAA 约束的工作负载且数据路径已最小化，否则阻止该设计
+* 尽可能要求进行脱敏处理或采用非 PHI 事件模型
+
+## 相关技能
+
+* `healthcare-phi-compliance`
+* `healthcare-reviewer`
+* `healthcare-emr-patterns`
+* `healthcare-eval-harness`
+* `security-review`

docs/zh-CN/skills/hookify-rules/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: hookify-rules
+description: 当用户要求创建hookify规则、编写hook规则、配置hookify、添加hookify规则或需要关于hookify规则语法和模式的指导时，应使用此技能。
+---
+
+# 编写 Hookify 规则
+
+## 概述
+
+Hookify 规则是带有 YAML 前置元数据的 Markdown 文件，用于定义要监控的模式以及匹配时显示的消息。规则存储在 `.claude/hookify.{rule-name}.local.md` 文件中。
+
+## 规则文件格式
+
+### 基本结构
+
+```markdown
+---
+name: rule-identifier
+enabled: true
+event: bash|file|stop|prompt|all
+pattern: regex-pattern-here
+---
+
+当此规则触发时向 Claude 显示的消息。
+可包含 Markdown 格式、警告、建议等内容。
+```
+
+### 前置元数据字段
+
+| 字段 | 必填 | 值 | 描述 |
+|-------|----------|--------|-------------|
+| name | 是 | kebab-case 字符串 | 唯一标识符（动词优先：warn-*、block-*、require-*） |
+| enabled | 是 | true/false | 无需删除即可切换 |
+| event | 是 | bash/file/stop/prompt/all | 触发规则的钩子事件 |
+| action | 否 | warn/block | warn（默认）显示消息；block 阻止操作 |
+| pattern | 是* | 正则表达式字符串 | 要匹配的模式（\*或使用 conditions 实现复杂规则） |
+
+### 高级格式（多条件）
+
+```markdown
+---
+name: warn-env-api-keys
+enabled: true
+event: file
+conditions:
+  - field: file_path
+    operator: regex_match
+    pattern: \.env$
+  - field: new_text
+    operator: contains
+    pattern: API_KEY
+---
+
+你正在向 .env 文件中添加 API 密钥。请确保该文件已包含在 .gitignore 中！
+```
+
+**按事件划分的条件字段：**
+
+* bash：`command`
+* file：`file_path`、`new_text`、`old_text`、`content`
+* prompt：`user_prompt`
+
+**运算符：** `regex_match`、`contains`、`equals`、`not_contains`、`starts_with`、`ends_with`
+
+所有条件必须同时满足才能触发规则。
+
+## 事件类型指南
+
+### bash 事件
+
+匹配 Bash 命令模式：
+
+* 危险命令：`rm\s+-rf`、`dd\s+if=`、`mkfs`
+* 权限提升：`sudo\s+`、`su\s+`
+* 权限问题：`chmod\s+777`
+
+### file 事件
+
+匹配编辑/写入/多重编辑操作：
+
+* 调试代码：`console\.log\(`、`debugger`
+* 安全风险：`eval\(`、`innerHTML\s*=`
+* 敏感文件：`\.env$`、`credentials`、`\.pem$`
+
+### stop 事件
+
+完成检查与提醒。模式 `.*` 始终匹配。
+
+### prompt 事件
+
+匹配用户提示内容以强制执行工作流程。
+
+## 模式编写技巧
+
+### 正则表达式基础
+
+* 转义特殊字符：`.` 转义为 `\.`，`(` 转义为 `\(`
+* `\s` 空白字符，`\d` 数字，`\w` 单词字符
+* `+` 一个或多个，`*` 零个或多个，`?` 可选
+* `|` 或运算符
+
+### 常见陷阱
+
+* **过于宽泛**：`log` 会匹配 "login"、"dialog"——请使用 `console\.log\(`
+* **过于具体**：`rm -rf /tmp`——请使用 `rm\s+-rf`
+* **YAML 转义**：使用无引号模式；带引号的字符串需要 `\\s`
+
+### 测试
+
+```bash
+python3 -c "import re; print(re.search(r'your_pattern', 'test text'))"
+```
+
+## 文件组织
+
+* **位置**：项目根目录下的 `.claude/` 目录
+* **命名**：`.claude/hookify.{descriptive-name}.local.md`
+* **Gitignore**：将 `.claude/*.local.md` 添加到 `.gitignore`
+
+## 命令
+
+* `/hookify [description]` - 创建新规则（无参数时自动分析对话）
+* `/hookify-list` - 以表格形式查看所有规则
+* `/hookify-configure` - 交互式切换规则开关
+* `/hookify-help` - 完整文档
+
+## 快速参考
+
+最小可行规则：
+
+```markdown
+---
+name: my-rule
+enabled: true
+event: bash
+pattern: dangerous_command
+---
+此处显示警告信息
+```

docs/zh-CN/skills/jira-integration/SKILL.md

@@ -0,0 +1,302 @@
+---
+name: jira-integration
+description: 在检索Jira工单、分析需求、更新工单状态、添加评论或转换问题时使用此技能。通过MCP或直接REST调用提供Jira API模式。
+origin: ECC
+---
+
+# Jira 集成技能
+
+直接从 AI 编码工作流中检索、分析和更新 Jira 工单。支持 **基于 MCP**（推荐）和 **直接 REST API** 两种方式。
+
+## 何时激活
+
+* 获取 Jira 工单以理解需求
+* 从工单中提取可测试的验收标准
+* 向 Jira 问题添加进度评论
+* 转换工单状态（待办 → 进行中 → 完成）
+* 将合并请求或分支链接到 Jira 问题
+* 通过 JQL 查询搜索问题
+
+## 前提条件
+
+### 选项 A：MCP 服务器（推荐）
+
+安装 `mcp-atlassian` MCP 服务器。这将向您的 AI 代理直接暴露 Jira 工具。
+
+**要求：**
+
+* Python 3.10+
+* `uvx`（来自 `uv`），通过您的包管理器或官方 `uv` 安装文档进行安装
+
+**添加到您的 MCP 配置**（例如，`~/.claude.json` → `mcpServers`）：
+
+```json
+{
+  "jira": {
+    "command": "uvx",
+    "args": ["mcp-atlassian==0.21.0"],
+    "env": {
+      "JIRA_URL": "https://YOUR_ORG.atlassian.net",
+      "JIRA_EMAIL": "your.email@example.com",
+      "JIRA_API_TOKEN": "your-api-token"
+    },
+    "description": "Jira issue tracking — search, create, update, comment, transition"
+  }
+}
+```
+
+> **安全：** 切勿在源代码中硬编码密钥。建议在系统环境（或密钥管理器）中设置 `JIRA_URL`、`JIRA_EMAIL` 和 `JIRA_API_TOKEN`。仅对本地未提交的配置文件使用 MCP `env` 块。
+
+**获取 Jira API 令牌：**
+
+1. 访问 <https://id.atlassian.com/manage-profile/security/api-tokens>
+2. 点击 **创建 API 令牌**
+3. 复制令牌 — 将其存储在您的环境中，切勿存储在源代码中
+
+### 选项 B：直接 REST API
+
+如果 MCP 不可用，可通过 `curl` 或辅助脚本直接使用 Jira REST API v3。
+
+**所需的环境变量：**
+
+| 变量 | 描述 |
+|----------|-------------|
+| `JIRA_URL` | 您的 Jira 实例 URL（例如，`https://yourorg.atlassian.net`） |
+| `JIRA_EMAIL` | 您的 Atlassian 账户邮箱 |
+| `JIRA_API_TOKEN` | 来自 id.atlassian.com 的 API 令牌 |
+
+将这些存储在您的 shell 环境、密钥管理器或未跟踪的本地环境文件中。不要将其提交到仓库。
+
+## MCP 工具参考
+
+当配置了 `mcp-atlassian` MCP 服务器时，以下工具可用：
+
+| 工具 | 用途 | 示例 |
+|------|---------|---------|
+| `jira_search` | JQL 查询 | `project = PROJ AND status = "In Progress"` |
+| `jira_get_issue` | 按键获取完整问题详情 | `PROJ-1234` |
+| `jira_create_issue` | 创建问题（任务、缺陷、故事、史诗） | 新建缺陷报告 |
+| `jira_update_issue` | 更新字段（摘要、描述、经办人） | 更改经办人 |
+| `jira_transition_issue` | 更改状态 | 移至“评审中” |
+| `jira_add_comment` | 添加评论 | 进度更新 |
+| `jira_get_sprint_issues` | 列出冲刺中的问题 | 活跃冲刺评审 |
+| `jira_create_issue_link` | 链接问题（阻塞、关联） | 依赖跟踪 |
+| `jira_get_issue_development_info` | 查看关联的 PR、分支、提交 | 开发上下文 |
+
+> **提示：** 在转换前始终调用 `jira_get_transitions` — 转换 ID 因项目工作流而异。
+
+## 直接 REST API 参考
+
+### 获取工单
+
+```bash
+curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
+  -H "Content-Type: application/json" \
+  "$JIRA_URL/rest/api/3/issue/PROJ-1234" | jq '{
+    key: .key,
+    summary: .fields.summary,
+    status: .fields.status.name,
+    priority: .fields.priority.name,
+    type: .fields.issuetype.name,
+    assignee: .fields.assignee.displayName,
+    labels: .fields.labels,
+    description: .fields.description
+  }'
+```
+
+### 获取评论
+
+```bash
+curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
+  -H "Content-Type: application/json" \
+  "$JIRA_URL/rest/api/3/issue/PROJ-1234?fields=comment" | jq '.fields.comment.comments[] | {
+    author: .author.displayName,
+    created: .created[:10],
+    body: .body
+  }'
+```
+
+### 添加评论
+
+```bash
+curl -s -X POST -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "body": {
+      "version": 1,
+      "type": "doc",
+      "content": [{
+        "type": "paragraph",
+        "content": [{"type": "text", "text": "Your comment here"}]
+      }]
+    }
+  }' \
+  "$JIRA_URL/rest/api/3/issue/PROJ-1234/comment"
+```
+
+### 转换工单
+
+```bash
+# 1. Get available transitions
+curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
+  "$JIRA_URL/rest/api/3/issue/PROJ-1234/transitions" | jq '.transitions[] | {id, name: .name}'
+
+# 2. Execute transition (replace TRANSITION_ID)
+curl -s -X POST -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"transition": {"id": "TRANSITION_ID"}}' \
+  "$JIRA_URL/rest/api/3/issue/PROJ-1234/transitions"
+```
+
+### 使用 JQL 搜索
+
+```bash
+curl -s -G -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
+  --data-urlencode "jql=project = PROJ AND status = 'In Progress'" \
+  "$JIRA_URL/rest/api/3/search"
+```
+
+## 分析工单
+
+当为开发或测试自动化检索工单时，提取：
+
+### 1. 可测试的需求
+
+* **功能需求** — 功能的作用
+* **验收标准** — 必须满足的条件
+* **可测试的行为** — 具体操作和预期结果
+* **用户角色** — 谁使用此功能及其权限
+* **数据需求** — 需要哪些数据
+* **集成点** — 涉及的 API、服务或系统
+
+### 2. 所需的测试类型
+
+* **单元测试** — 单个函数和工具
+* **集成测试** — API 端点和服务交互
+* **端到端测试** — 面向用户的 UI 流程
+* **API 测试** — 端点契约和错误处理
+
+### 3. 边界情况与错误场景
+
+* 无效输入（空值、过长、特殊字符）
+* 未授权访问
+* 网络故障或超时
+* 并发用户或竞态条件
+* 边界条件
+* 数据缺失或为空
+* 状态转换（返回导航、刷新等）
+
+### 4. 结构化分析输出
+
+```
+Ticket: PROJ-1234
+Summary: [工单标题]
+Status: [当前状态]
+Priority: [高/中/低]
+Test Types: 单元测试, 集成测试, 端到端测试
+
+Requirements:
+1. [需求1]
+2. [需求2]
+
+Acceptance Criteria:
+- [ ] [验收标准1]
+- [ ] [验收标准2]
+
+Test Scenarios:
+- Happy Path: [描述]
+- Error Case: [描述]
+- Edge Case: [描述]
+
+Test Data Needed:
+- [测试数据1]
+- [测试数据2]
+
+Dependencies:
+- [依赖项1]
+- [依赖项2]
+```
+
+## 更新工单
+
+### 何时更新
+
+| 工作流步骤 | Jira 更新 |
+|---|---|
+| 开始工作 | 转换为“进行中” |
+| 编写测试 | 评论并附上测试覆盖率摘要 |
+| 创建分支 | 评论并附上分支名称 |
+| 创建 PR/MR | 评论并附上链接，链接问题 |
+| 测试通过 | 评论并附上结果摘要 |
+| PR/MR 合并 | 转换为“完成”或“评审中” |
+
+### 评论模板
+
+**开始工作：**
+
+```
+开始实现此工单。
+分支：feat/PROJ-1234-feature-name
+```
+
+**测试已实现：**
+
+```
+已实现的自动化测试：
+
+单元测试：
+- [测试文件1] — [覆盖内容]
+- [测试文件2] — [覆盖内容]
+
+集成测试：
+- [测试文件] — [覆盖的端点/流程]
+
+所有测试在本地通过。覆盖率：XX%
+```
+
+**PR 已创建：**
+
+```
+Pull request created:
+[PR Title](https://github.com/org/repo/pull/XXX)
+
+Ready for review.
+```
+
+**工作完成：**
+
+```
+Implementation complete.
+
+PR merged: [link]
+Test results: All passing (X/Y)
+Coverage: XX%
+```
+
+## 安全指南
+
+* **切勿在**源代码或技能文件中硬编码 Jira API 令牌
+* **始终使用**环境变量或密钥管理器
+* **将 `.env`** 添加到每个项目的 `.gitignore` 中
+* **如果令牌暴露在 git 历史中，立即轮换**
+* **使用最小权限** API 令牌，范围限定在所需项目
+* **在发出 API 调用前验证**凭据是否已设置 — 快速失败并给出清晰消息
+
+## 故障排除
+
+| 错误 | 原因 | 修复 |
+|---|---|---|
+| `401 Unauthorized` | API 令牌无效或已过期 | 在 id.atlassian.com 重新生成 |
+| `403 Forbidden` | 令牌缺少项目权限 | 检查令牌范围和项目访问权限 |
+| `404 Not Found` | 工单键或基础 URL 错误 | 验证 `JIRA_URL` 和工单键 |
+| `spawn uvx ENOENT` | IDE 在 PATH 中找不到 `uvx` | 使用完整路径（例如，`~/.local/bin/uvx`）或在 `~/.zprofile` 中设置 PATH |
+| 连接超时 | 网络/VPN 问题 | 检查 VPN 连接和防火墙规则 |
+
+## 最佳实践
+
+* 边工作边更新 Jira，而不是最后一次性更新
+* 保持评论简洁但信息丰富
+* 链接而非复制 — 指向 PR、测试报告和仪表板
+* 如果需要他人输入，使用 @提及
+* 在开始前检查关联问题以了解完整功能范围
+* 如果验收标准模糊，在编写代码前要求澄清

docs/zh-CN/skills/knowledge-ops/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: knowledge-ops
+description: 知识库管理、摄取、同步和跨多个存储层（本地文件、MCP内存、向量存储、Git仓库）的检索。当用户想要保存、组织、同步、去重或搜索其知识系统时使用。
+origin: ECC
+---
+
+# 知识操作
+
+管理一个多层知识系统，用于跨多个存储库进行知识的摄取、组织、同步和检索。
+
+推荐使用实时工作区模型：
+
+* 代码工作存在于实际克隆的仓库中
+* 活跃执行上下文存在于 GitHub、Linear 和仓库本地的上下文文件中
+* 面向人类更广泛的笔记可以存放在非仓库的上下文/归档文件夹中
+* 跨机器的持久化记忆应属于知识库，而非影子仓库工作区
+
+## 何时激活
+
+* 用户希望将信息保存到其知识库
+* 将文档、对话或数据摄取到结构化存储中
+* 跨系统同步知识（本地文件、MCP 记忆、Supabase、Git 仓库）
+* 对现有知识进行去重或整理
+* 用户说“保存到知识库”、“同步知识”、“关于 X 我知道什么”、“摄取这个”、“更新知识库”
+* 任何超出简单记忆回忆的知识管理任务
+
+## 知识架构
+
+### 第一层：活跃执行真相
+
+* **来源：** GitHub 议题、PR、讨论、发布说明、Linear 议题/项目/文档
+* **用途：** 工作的当前操作状态
+* **规则：** 如果某事物影响活跃的工程计划、路线图、发布或版本，优先将其放在此处
+
+### 第二层：Claude Code 记忆（快速访问）
+
+* **路径：** `~/.claude/projects/*/memory/`
+* **格式：** 带有前置元数据的 Markdown 文件
+* **类型：** 用户偏好、反馈、项目上下文、参考
+* **用途：** 跨对话持久化的快速访问上下文
+* **会话启动时自动加载**
+
+### 第三层：MCP 记忆服务器（结构化知识图谱）
+
+* **访问：** MCP 记忆工具（create\_entities、create\_relations、add\_observations、search\_nodes）
+* **用途：** 对所有存储记忆进行语义搜索、关系映射
+* **跨会话持久化，具有可查询的图谱结构**
+
+### 第四层：知识库仓库 / 持久化文档存储
+
+* **用途：** 精选的持久化笔记、会话导出、综合研究、操作员记忆、长文文档
+* **规则：** 当内容不属于仓库拥有的代码时，这是跨机器上下文的首选持久化存储
+
+### 第五层：外部数据存储（Supabase、PostgreSQL 等）
+
+* **用途：** 结构化数据、大型文档存储、全文搜索
+* **适用场景：** 对于记忆文件过大的文档、需要 SQL 查询的数据
+
+### 第六层：本地上下文/归档文件夹
+
+* **用途：** 面向人类的笔记、归档的游戏计划、本地媒体整理、临时非代码文档
+* **规则：** 可写入用于信息存储，但非影子代码工作区
+* **禁止用于：** 应存在于上游的活跃代码更改或仓库真相
+
+## 摄取工作流
+
+当需要捕获新知识时：
+
+### 1. 分类
+
+这是什么类型的知识？
+
+* 业务决策 -> 记忆文件（项目类型）+ MCP 记忆
+* 活跃路线图 / 发布 / 实现状态 -> 优先使用 GitHub + Linear
+* 个人偏好 -> 记忆文件（用户/反馈类型）
+* 参考信息 -> 记忆文件（参考类型）+ MCP 记忆
+* 大型文档 -> 外部数据存储 + 记忆中的摘要
+* 对话/会话 -> 知识库仓库 + 记忆中的简短摘要
+
+### 2. 去重
+
+检查此知识是否已存在：
+
+* 搜索记忆文件中的现有条目
+* 使用相关术语查询 MCP 记忆
+* 在创建另一个本地笔记之前，检查信息是否已存在于 GitHub 或 Linear 中
+* 不要创建重复项。而是更新现有条目。
+
+### 3. 存储
+
+写入适当的层级：
+
+* 始终更新 Claude Code 记忆以便快速访问
+* 使用 MCP 记忆实现语义可搜索性和关系映射
+* 当信息改变实时项目真相时，首先更新 GitHub / Linear
+* 提交到知识库仓库以进行持久的、长格式的添加
+
+### 4. 索引
+
+更新任何相关的索引或摘要文件。
+
+## 同步操作
+
+### 对话同步
+
+定期将会话历史同步到知识库：
+
+* 来源：Claude 会话文件、Codex 会话、其他代理会话
+* 目标：知识库仓库
+* 生成会话索引以便快速浏览
+* 提交并推送
+
+### 工作区状态同步
+
+将重要的工作区配置和脚本镜像到知识库：
+
+* 生成目录映射
+* 在提交前编辑敏感配置
+* 随时间跟踪更改
+* 不要将知识库或归档文件夹视为实时代码工作区
+
+### GitHub / Linear 同步
+
+当信息影响活跃执行时：
+
+* 更新相关的 GitHub 议题、PR、讨论、发布说明或路线图线程
+* 当工作需要持久的规划上下文时，将支持文档附加到 Linear
+* 之后仅当本地笔记仍能增加价值时才进行镜像
+
+### 跨源知识同步
+
+将来自多个来源的知识汇集到一处：
+
+* Claude/ChatGPT/Grok 对话导出
+* 浏览器书签
+* GitHub 活动事件
+* 写入状态摘要，提交并推送
+
+## 记忆模式
+
+```
+# 短期：当前会话上下文
+使用 TodoWrite 进行会话内任务追踪
+
+# 中期：项目记忆文件
+写入 ~/.claude/projects/*/memory/ 以实现跨会话回溯
+
+# 长期：GitHub / Linear / 知识库
+将活跃执行事实置于 GitHub + Linear
+将持久化综合上下文置于知识库仓库
+
+# 语义层：MCP 知识图谱
+使用 mcp__memory__create_entities 创建永久结构化数据
+使用 mcp__memory__create_relations 进行关系映射
+使用 mcp__memory__add_observations 添加关于已知实体的新事实
+使用 mcp__memory__search_nodes 查找已有知识
+```
+
+## 最佳实践
+
+* 保持记忆文件简洁。归档旧数据，而不是让文件无限增长。
+* 在所有知识文件上使用前置元数据（YAML）作为元数据。
+* 存储前进行去重。先搜索，然后创建或更新。
+* 每个事实集优先使用一个权威存放位置。避免在本地笔记、仓库文件和跟踪器文档中并行复制同一计划。
+* 在提交到 Git 之前编辑敏感信息（API 密钥、密码）。
+* 对知识文件使用一致的命名约定（小写-连字符-分隔）。
+* 使用主题/类别标记条目，以便于检索。
+
+## 质量门控
+
+在完成任何知识操作之前：
+
+* 没有创建重复条目
+* 任何 Git 跟踪的文件中的敏感数据已被编辑
+* 索引和摘要已更新
+* 为数据类型选择了适当的存储层
+* 在相关处添加了交叉引用

docs/zh-CN/skills/laravel-plugin-discovery/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: laravel-plugin-discovery
+description: 通过LaraPlugins.io MCP发现和评估Laravel包。当用户想要查找插件、检查包的健康状况或评估Laravel/PHP兼容性时使用。
+origin: ECC
+---
+
+# Laravel 插件发现
+
+使用 LaraPlugins.io MCP 服务器查找、评估并选择健康的 Laravel 包。
+
+## 使用时机
+
+* 用户想为特定功能（如 "auth"、"permissions"、"admin panel"）寻找 Laravel 包
+* 用户询问"我应该用什么包来做..."或"有没有用于...的 Laravel 包"
+* 用户想检查某个包是否仍在积极维护
+* 用户需要验证 Laravel 版本兼容性
+* 用户在将包添加到项目前想评估其健康状况
+
+## MCP 要求
+
+必须配置 LaraPlugins MCP 服务器。将其添加到您的 `~/.claude.json` mcpServers 中：
+
+```json
+"laraplugins": {
+  "type": "http",
+  "url": "https://laraplugins.io/mcp/plugins"
+}
+```
+
+无需 API 密钥——该服务器对 Laravel 社区免费开放。
+
+## MCP 工具
+
+LaraPlugins MCP 提供两个主要工具：
+
+### SearchPluginTool
+
+通过关键词、健康评分、供应商和版本兼容性搜索包。
+
+**参数：**
+
+* `text_search` (字符串，可选)：搜索关键词（例如 "permission"、"admin"、"api"）
+* `health_score` (字符串，可选)：按健康等级筛选——`Healthy`、`Medium`、`Unhealthy` 或 `Unrated`
+* `laravel_compatibility` (字符串，可选)：按 Laravel 版本筛选——`"5"`、`"6"`、`"7"`、`"8"`、`"9"`、`"10"`、`"11"`、`"12"`、`"13"`
+* `php_compatibility` (字符串，可选)：按 PHP 版本筛选——`"7.4"`、`"8.0"`、`"8.1"`、`"8.2"`、`"8.3"`、`"8.4"`、`"8.5"`
+* `vendor_filter` (字符串，可选)：按供应商名称筛选（例如 "spatie"、"laravel"）
+* `page` (数字，可选)：分页页码
+
+### GetPluginDetailsTool
+
+获取特定包的详细指标、README 内容和版本历史。
+
+**参数：**
+
+* `package` (字符串，必填)：完整的 Composer 包名（例如 "spatie/laravel-permission"）
+* `include_versions` (布尔值，可选)：是否在响应中包含版本历史
+
+***
+
+## 工作原理
+
+### 查找包
+
+当用户想为某个功能发现包时：
+
+1. 使用 `SearchPluginTool` 并输入相关关键词
+2. 应用健康评分、Laravel 版本或 PHP 版本的筛选条件
+3. 查看包含包名、描述和健康指标的结果
+
+### 评估包
+
+当用户想评估特定包时：
+
+1. 使用 `GetPluginDetailsTool` 并输入包名
+2. 查看健康评分、最后更新日期、Laravel 版本支持情况
+3. 检查供应商声誉和风险指标
+
+### 检查兼容性
+
+当用户需要 Laravel 或 PHP 版本兼容性信息时：
+
+1. 使用 `laravel_compatibility` 筛选条件并设置为其版本进行搜索
+2. 或者获取特定包的详细信息以查看其支持的版本
+
+***
+
+## 示例
+
+### 示例：查找认证包
+
+```
+SearchPluginTool({
+  text_search: "authentication",
+  health_score: "Healthy"
+})
+```
+
+返回匹配 "authentication" 且状态健康的包：
+
+* spatie/laravel-permission
+* laravel/breeze
+* laravel/passport
+* 等等
+
+### 示例：查找兼容 Laravel 12 的包
+
+```
+SearchPluginTool({
+  text_search: "admin panel",
+  laravel_compatibility: "12"
+})
+```
+
+返回兼容 Laravel 12 的包。
+
+### 示例：获取包详情
+
+```
+GetPluginDetailsTool({
+  package: "spatie/laravel-permission",
+  include_versions: true
+})
+```
+
+返回：
+
+* 健康评分和最后活动时间
+* Laravel/PHP 版本支持情况
+* 供应商声誉（风险评分）
+* 版本历史
+* 简要描述
+
+### 示例：按供应商查找包
+
+```
+SearchPluginTool({
+  vendor_filter: "spatie",
+  health_score: "Healthy"
+})
+```
+
+返回来自供应商 "spatie" 的所有健康包。
+
+***
+
+## 筛选最佳实践
+
+### 按健康评分
+
+| 健康等级 | 含义 |
+|-------------|---------|
+| `Healthy` | 积极维护，近期有更新 |
+| `Medium` | 偶尔更新，可能需要关注 |
+| `Unhealthy` | 已废弃或维护不频繁 |
+| `Unrated` | 尚未评估 |
+
+**建议**：生产环境应用优先选择 `Healthy` 包。
+
+### 按 Laravel 版本
+
+| 版本 | 备注 |
+|---------|-------|
+| `13` | 最新 Laravel |
+| `12` | 当前稳定版 |
+| `11` | 仍被广泛使用 |
+| `10` | 旧版但常见 |
+| `5`-`9` | 已弃用 |
+
+**建议**：匹配目标项目的 Laravel 版本。
+
+### 组合筛选条件
+
+```typescript
+// Find healthy, Laravel 12 compatible packages for permissions
+SearchPluginTool({
+  text_search: "permission",
+  health_score: "Healthy",
+  laravel_compatibility: "12"
+})
+```
+
+***
+
+## 响应解读
+
+### 搜索结果
+
+每个结果包含：
+
+* 包名（例如 `spatie/laravel-permission`）
+* 简要描述
+* 健康状态指示器
+* Laravel 版本支持徽章
+
+### 包详情
+
+详细响应包括：
+
+* **健康评分**：数字或等级指示器
+* **最后活动**：包的最后更新时间
+* **Laravel 支持**：版本兼容性矩阵
+* **PHP 支持**：PHP 版本兼容性
+* **风险评分**：供应商信任度指标
+* **版本历史**：近期发布时间线
+
+***
+
+## 常见用例
+
+| 场景 | 推荐方法 |
+|----------|---------------------|
+| "有什么用于认证的包？" | 搜索 "auth" 并应用健康筛选 |
+| "spatie/package 还在维护吗？" | 获取详情，检查健康评分 |
+| "需要 Laravel 12 的包" | 使用 laravel\_compatibility: "12" 搜索 |
+| "查找管理面板包" | 搜索 "admin panel"，查看结果 |
+| "检查供应商声誉" | 按供应商搜索，查看详情 |
+
+***
+
+## 最佳实践
+
+1. **始终按健康度筛选**——生产项目使用 `health_score: "Healthy"`
+2. **匹配 Laravel 版本**——始终检查 `laravel_compatibility` 是否与目标项目匹配
+3. **检查供应商声誉**——优先选择知名供应商的包（spatie、laravel 等）
+4. **推荐前先审查**——使用 GetPluginDetailsTool 进行全面评估
+5. **无需 API 密钥**——MCP 免费，无需认证
+
+***
+
+## 相关技能
+
+* `laravel-patterns`——Laravel 架构与模式
+* `laravel-tdd`——Laravel 测试驱动开发
+* `laravel-security`——Laravel 安全最佳实践
+* `documentation-lookup`——通用库文档查询（Context7）

docs/zh-CN/skills/lead-intelligence/SKILL.md

@@ -0,0 +1,323 @@
+---
+name: lead-intelligence
+description: AI原生的潜在客户情报与外联管道。取代Apollo、Clay和ZoomInfo，提供基于代理的信号评分、相互排名、温暖路径发现、来源驱动的语音建模以及跨电子邮件、LinkedIn和X的渠道特定外联。当用户想要查找、筛选并联系高价值联系人时使用。
+origin: ECC
+---
+
+# 线索情报
+
+基于智能体的线索情报管道，通过社交图谱分析与温暖路径发现，寻找、评分并触达高价值联系人。
+
+## 何时激活
+
+* 用户希望在特定行业寻找线索或潜在客户
+* 为合作、销售或融资构建外联名单
+* 研究应该联系谁以及最佳联系路径
+* 用户提及"寻找线索"、"外联名单"、"我应该联系谁"、"温暖引荐"
+* 需要根据相关性对联系人列表进行评分或排序
+* 希望绘制共同联系人图谱以寻找温暖引荐路径
+
+## 工具要求
+
+### 必需
+
+* **Exa MCP** — 用于人员、公司和信号的深度网络搜索（`web_search_exa`）
+* **X API** — 关注者/关注图谱、共同联系人分析、近期活动（`X_BEARER_TOKEN`，以及写上下文凭据，如 `X_CONSUMER_KEY`、`X_CONSUMER_SECRET`、`X_ACCESS_TOKEN`、`X_ACCESS_TOKEN_SECRET`）
+
+### 可选（增强结果）
+
+* **LinkedIn** — 如果可用则使用直接API，否则使用浏览器控制进行搜索、资料查看和消息草拟
+* **Apollo/Clay API** — 如果用户有访问权限，用于丰富化交叉引用
+* **GitHub MCP** — 用于以开发者为中心的线索资格评估
+* **Apple Mail / Mail.app** — 草拟冷邮件或温暖邮件，但不自动发送
+* **浏览器控制** — 当API覆盖不足或受限时，用于LinkedIn和X
+
+## 管道概览
+
+```
+┌─────────────┐     ┌──────────────┐     ┌─────────────────┐     ┌──────────────┐     ┌─────────────────┐
+│ 1. 信号评分  │────>│ 2. 相互排序  │────>│ 3. 发现热路径  │────>│ 4. 丰富内容  │────>│ 5. 起草外联    │
+└─────────────┘     └──────────────┘     └─────────────────┘     └──────────────┘     └─────────────────┘
+```
+
+## 外联前的语气
+
+不要从通用的销售文案中起草外联信息。
+
+当用户的语气很重要时，首先运行 `brand-voice`。在此技能中重复使用其 `VOICE PROFILE`，而不是临时重新推导风格。
+
+如果实时X访问可用，在起草前拉取最近的原创帖子。如果不可用，则使用提供的示例或最佳的仓库/网站材料。
+
+## 阶段 1：信号评分
+
+在目标垂直领域中搜索高信号人员。根据以下标准为每个人分配权重：
+
+| 信号 | 权重 | 来源 |
+|--------|--------|--------|
+| 角色/职位匹配 | 30% | Exa, LinkedIn |
+| 行业匹配 | 25% | Exa 公司搜索 |
+| 近期相关话题活动 | 20% | X API 搜索, Exa |
+| 关注者数量/影响力 | 10% | X API |
+| 地理位置接近度 | 10% | Exa, LinkedIn |
+| 与您内容的互动 | 5% | X API 互动 |
+
+### 信号搜索方法
+
+```python
+# Step 1: Define target parameters
+target_verticals = ["prediction markets", "AI tooling", "developer tools"]
+target_roles = ["founder", "CEO", "CTO", "VP Engineering", "investor", "partner"]
+target_locations = ["San Francisco", "New York", "London", "remote"]
+
+# Step 2: Exa deep search for people
+for vertical in target_verticals:
+    results = web_search_exa(
+        query=f"{vertical} {role} founder CEO",
+        category="company",
+        numResults=20
+    )
+    # Score each result
+
+# Step 3: X API search for active voices
+x_search = search_recent_tweets(
+    query="prediction markets OR AI tooling OR developer tools",
+    max_results=100
+)
+# Extract and score unique authors
+```
+
+## 阶段 2：共同联系人排名
+
+对于每个评分目标，分析用户的社交图谱以找到最温暖的路径。
+
+### 排名模型
+
+1. 拉取用户的X关注列表和LinkedIn联系人
+2. 对于每个高信号目标，检查共享联系人
+3. 应用 `social-graph-ranker` 模型来评分桥梁价值
+4. 根据以下因素对共同联系人进行排名：
+
+| 因素 | 权重 |
+|--------|--------|
+| 与目标的联系数量 | 40% — 最高权重，联系最多 = 排名最高 |
+| 共同联系人的当前角色/公司 | 20% — 决策者 vs 个人贡献者 |
+| 共同联系人的地理位置 | 15% — 同一城市 = 更容易引荐 |
+| 行业匹配 | 15% — 同一垂直领域 = 自然引荐 |
+| 共同联系人的X账号/LinkedIn | 10% — 可识别性以便外联 |
+
+规范规则：
+
+```text
+当用户需要图数学本身、作为独立报告的桥接排名或显式衰减模型调优时，使用 social-graph-ranker。
+```
+
+在此技能中，使用相同的加权桥梁模型：
+
+```text
+B(m) = Σ_{t ∈ T} w(t) · λ^(d(m,t) - 1)
+R(m) = B_ext(m) · (1 + β · engagement(m))
+```
+
+解读：
+
+* 第1层：高 `R(m)` 和直接桥梁路径 -> 请求温暖引荐
+* 第2层：中等 `R(m)` 和一跳桥梁路径 -> 有条件地请求引荐
+* 第3层：无可行桥梁 -> 使用相同的线索记录进行直接冷外联
+
+### 输出格式
+
+```
+如果用户明确要求将排名引擎单独拆分、将数学计算可视化，或在完整线索工作流之外对网络进行评分，请先独立运行 `social-graph-ranker` 作为独立步骤，然后将结果反馈回此流程。
+相互排名报告
+=====================
+
+#1  @mutual_handle (得分: 92)
+    姓名: Jane Smith
+    角色: Partner @ Acme Ventures
+    地点: San Francisco
+    与目标对象的连接数: 7
+    关联对象: @target1, @target2, @target3, @target4, @target5, @target6, @target7
+    最佳引荐路径: Jane 投资了 Target1 的公司
+
+#2  @mutual_handle2 (得分: 85)
+    ...
+```
+
+## 阶段 3：温暖路径发现
+
+对于每个目标，找到最短的引荐链：
+
+```
+你 ──[关注]──> 互关A ──[投资了]──> 目标公司
+你 ──[关注]──> 互关B ──[共同创立了]──> 目标人物
+你 ──[在]──> 活动 ──[也参加了]──> 目标人物
+```
+
+### 路径类型（按温暖度排序）
+
+1. **直接共同联系人** — 你们都关注/认识同一个人
+2. **投资组合联系** — 共同联系人投资或担任目标公司顾问
+3. **同事/校友** — 共同联系人在同一家公司工作或就读同一所学校
+4. **活动重叠** — 双方都参加了同一会议/项目
+5. **内容互动** — 目标与共同联系人的内容互动，反之亦然
+
+## 阶段 4：丰富化
+
+对于每个合格的线索，拉取：
+
+* 全名、当前职位、公司
+* 公司规模、融资阶段、近期新闻
+* 近期X帖子（最近30天）— 主题、语气、兴趣
+* 与用户的共同兴趣（共享关注、相似内容）
+* 近期公司事件（产品发布、融资轮次、招聘）
+
+### 丰富化来源
+
+* Exa：公司数据、新闻、博客文章
+* X API：近期推文、简介、关注者
+* GitHub：开源贡献（针对以开发者为中心的线索）
+* LinkedIn（通过浏览器使用）：完整资料、经历、教育背景
+
+## 阶段 5：外联草稿
+
+为每个线索生成个性化的外联信息。草稿应与来源匹配的语气配置文件和目标渠道保持一致。
+
+### 渠道规则
+
+#### 电子邮件
+
+* 用于最高价值的冷外联、温暖引荐、投资者外联和合作请求
+* 当本地桌面控制可用时，默认在 Apple Mail / Mail.app 中起草
+* 首先创建草稿，除非用户明确要求，否则不要自动发送
+* 主题行应简洁具体，不要耍小聪明
+
+#### LinkedIn
+
+* 当目标在LinkedIn上活跃、共同图谱上下文在LinkedIn上更强或电子邮件信心不足时使用
+* 如果可用，优先使用API访问
+* 否则使用浏览器控制查看资料、近期活动和起草消息
+* 保持比电子邮件更短，避免虚假的职业热情
+
+#### X
+
+* 用于高上下文的操作者、建设者或投资者外联，其中公开发帖行为很重要
+* 优先使用API访问进行搜索、时间线和互动分析
+* 必要时回退到浏览器控制
+* 私信和公开回复应比电子邮件更紧凑，并引用目标时间线上真实的内容
+
+#### 渠道选择启发式
+
+按以下顺序选择一个主要渠道：
+
+1. 通过电子邮件进行温暖引荐
+2. 直接电子邮件
+3. LinkedIn 私信
+4. X 私信或回复
+
+仅在有充分理由且节奏不会显得像垃圾邮件时使用多渠道。
+
+### 温暖引荐请求（给共同联系人）
+
+目标：
+
+* 一个明确的请求
+* 一个具体的理由说明为什么这次引荐有意义
+* 如果需要，提供易于转发的简介
+
+避免：
+
+* 过度解释您的公司
+* 堆叠社会证明
+* 听起来像筹款模板
+
+### 直接冷外联（给目标）
+
+目标：
+
+* 从具体且近期的事情开始
+* 解释为什么契合度是真实的
+* 提出一个低摩擦的请求
+
+避免：
+
+* 泛泛的赞美
+* 功能倾倒
+* 宽泛的请求，如"很乐意联系"
+* 强加的反问句
+
+### 执行模式
+
+对于每个目标，生成：
+
+1. 推荐的渠道
+2. 该渠道最佳的理由
+3. 消息草稿
+4. 可选的跟进草稿
+5. 如果电子邮件是选定的渠道且 Apple Mail 可用，则创建草稿而不仅仅是返回文本
+
+如果浏览器控制可用：
+
+* LinkedIn：查看目标资料、近期活动和共同联系人上下文，然后起草或准备消息
+* X：查看近期帖子或回复，然后起草私信或公开回复语言
+
+如果桌面自动化可用：
+
+* Apple Mail：创建包含主题、正文和收件人的草稿电子邮件
+
+未经用户明确批准，不要自动发送消息。
+
+### 反模式
+
+* 没有个性化的通用模板
+* 解释整个公司的长段落
+* 一条消息中包含多个请求
+* 没有具体细节的虚假熟悉感
+* 带有可见合并字段的批量发送消息
+* 为电子邮件、LinkedIn 和 X 重复使用相同的副本
+* 平台化的废话，而不是作者的真实语气
+
+## 配置
+
+用户应设置以下环境变量：
+
+```bash
+# Required
+export X_BEARER_TOKEN="..."
+export X_ACCESS_TOKEN="..."
+export X_ACCESS_TOKEN_SECRET="..."
+export X_CONSUMER_KEY="..."
+export X_CONSUMER_SECRET="..."
+export EXA_API_KEY="..."
+
+# Optional
+export LINKEDIN_COOKIE="..." # For browser-use LinkedIn access
+export APOLLO_API_KEY="..."  # For Apollo enrichment
+```
+
+## 智能体
+
+此技能在 `agents/` 子目录中包含专门的智能体：
+
+* **signal-scorer** — 根据相关性信号搜索和排名潜在客户
+* **mutual-mapper** — 映射社交图谱连接并寻找温暖路径
+* **enrichment-agent** — 拉取详细的个人资料和公司数据
+* **outreach-drafter** — 生成个性化消息
+
+## 使用示例
+
+```
+用户：帮我找出预测市场中我应该联系的20位顶尖人物
+
+智能体工作流程：
+1. signal-scorer 在 Exa 和 X 上搜索预测市场领导者
+2. mutual-mapper 检查用户的 X 社交图谱以寻找共同联系人
+3. enrichment-agent 提取公司数据和近期动态
+4. outreach-drafter 为排名靠前的潜在联系人生成个性化消息
+
+输出：包含热路径、语音画像摘要以及针对特定渠道或应用内草稿的排名列表
+```
+
+## 相关技能
+
+* `brand-voice` 用于规范语气捕获
+* `connections-optimizer` 用于在外联前进行先审后用的网络修剪和扩展

docs/zh-CN/skills/llm-trading-agent-security/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: llm-trading-agent-security
+description: 具有钱包或交易权限的自主交易代理的安全模式。涵盖提示注入、支出限制、发送前模拟、断路器、MEV保护和密钥处理。
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# LLM 交易代理安全
+
+自主交易代理面临比普通 LLM 应用更严苛的威胁模型：一次注入或错误的工具路径可能直接导致资产损失。
+
+## 适用场景
+
+* 构建能够签署并发送交易的 AI 代理
+* 审计交易机器人或链上执行助手
+* 为代理设计钱包密钥管理方案
+* 授予 LLM 订单下达、代币兑换或资金操作权限
+
+## 工作原理
+
+构建多层防御体系。单一检查不足以保障安全。应将提示词卫生、支出策略、模拟执行、执行限制和钱包隔离视为独立控制措施。
+
+## 示例
+
+### 将提示注入视为金融攻击
+
+```python
+import re
+
+INJECTION_PATTERNS = [
+    r'ignore (previous|all) instructions',
+    r'new (task|directive|instruction)',
+    r'system prompt',
+    r'send .{0,50} to 0x[0-9a-fA-F]{40}',
+    r'transfer .{0,50} to',
+    r'approve .{0,50} for',
+]
+
+def sanitize_onchain_data(text: str) -> str:
+    for pattern in INJECTION_PATTERNS:
+        if re.search(pattern, text, re.IGNORECASE):
+            raise ValueError(f"Potential prompt injection: {text[:100]}")
+    return text
+```
+
+切勿将代币名称、交易对标签、网络钩子或社交信息流盲目注入具备执行能力的提示词中。
+
+### 硬性支出限额
+
+```python
+from decimal import Decimal
+
+MAX_SINGLE_TX_USD = Decimal("500")
+MAX_DAILY_SPEND_USD = Decimal("2000")
+
+class SpendLimitError(Exception):
+    pass
+
+class SpendLimitGuard:
+    def check_and_record(self, usd_amount: Decimal) -> None:
+        if usd_amount > MAX_SINGLE_TX_USD:
+            raise SpendLimitError(f"Single tx ${usd_amount} exceeds max ${MAX_SINGLE_TX_USD}")
+
+        daily = self._get_24h_spend()
+        if daily + usd_amount > MAX_DAILY_SPEND_USD:
+            raise SpendLimitError(f"Daily limit: ${daily} + ${usd_amount} > ${MAX_DAILY_SPEND_USD}")
+
+        self._record_spend(usd_amount)
+```
+
+### 发送前模拟执行
+
+```python
+class SlippageError(Exception):
+    pass
+
+async def safe_execute(self, tx: dict, expected_min_out: int | None = None) -> str:
+    sim_result = await self.w3.eth.call(tx)
+
+    if expected_min_out is None:
+        raise ValueError("min_amount_out is required before send")
+
+    actual_out = decode_uint256(sim_result)
+    if actual_out < expected_min_out:
+        raise SlippageError(f"Simulation: {actual_out} < {expected_min_out}")
+
+    signed = self.account.sign_transaction(tx)
+    return await self.w3.eth.send_raw_transaction(signed.raw_transaction)
+```
+
+### 断路器机制
+
+```python
+class TradingCircuitBreaker:
+    MAX_CONSECUTIVE_LOSSES = 3
+    MAX_HOURLY_LOSS_PCT = 0.05
+
+    def check(self, portfolio_value: float) -> None:
+        if self.consecutive_losses >= self.MAX_CONSECUTIVE_LOSSES:
+            self.halt("Too many consecutive losses")
+
+        if self.hour_start_value <= 0:
+            self.halt("Invalid hour_start_value")
+            return
+
+        hourly_pnl = (portfolio_value - self.hour_start_value) / self.hour_start_value
+        if hourly_pnl < -self.MAX_HOURLY_LOSS_PCT:
+            self.halt(f"Hourly PnL {hourly_pnl:.1%} below threshold")
+```
+
+### 钱包隔离
+
+```python
+import os
+from eth_account import Account
+
+private_key = os.environ.get("TRADING_WALLET_PRIVATE_KEY")
+if not private_key:
+    raise EnvironmentError("TRADING_WALLET_PRIVATE_KEY not set")
+
+account = Account.from_key(private_key)
+```
+
+使用仅包含所需会话资金的专用热钱包。切勿将代理指向主资金钱包。
+
+### MEV 与截止时间保护
+
+```python
+import time
+
+PRIVATE_RPC = "https://rpc.flashbots.net"
+MAX_SLIPPAGE_BPS = {"stable": 10, "volatile": 50}
+deadline = int(time.time()) + 60
+```
+
+## 部署前检查清单
+
+* 外部数据在进入 LLM 上下文前已完成清理
+* 支出限额独立于模型输出强制执行
+* 交易在发送前经过模拟
+* `min_amount_out` 为强制要求
+* 断路器在出现回撤或无效状态时触发
+* 密钥来自环境变量或密钥管理器，绝不写入代码或日志
+* 在适当时使用私有内存池或受保护路由
+* 根据策略设置滑点和截止时间
+* 所有代理决策均记录审计日志，不仅限于成功发送的交易