代码提交 → Lint检查 → 单元测试 → 安全扫描 → 生成Changelog → 创建PR

graph TB
    A[用户输入: "审查这段代码并创建PR"] --> B{Skill Router}
    B --> C[Lint Skill]
    B --> D[Security Scan Skill]
    C --> E[Aggregator: 汇总结果]
    D --> E
    E --> F[Doc Gen Skill]
    F --> G[PR Creator Skill]
    G --> H[输出: PR链接 + 审查报告]

    style A fill:#e1f5fe
    style H fill:#c8e6c9
    style B fill:#fff9c4

graph LR
    subgraph Chain模式
        A1[Step 1] --> A2[Step 2] --> A3[Step 3]
    end

    subgraph Fan-Out模式
        B1[Input] --> B2[Skill A]
        B1 --> B3[Skill B]
        B1 --> B4[Skill C]
    end

    subgraph Aggregator模式
        C1[Skill A] --> C4[Aggregator]
        C2[Skill B] --> C4
        C3[Skill C] --> C4
    end

    subgraph Pipeline模式
        D1[Input] --> D2{条件判断}
        D2 -->|通过| D3[Step A]
        D2 -->|失败| D4[Step B]
    end

mkdir -p ~/.claude/skills/code-pipeline
cd ~/.claude/skills/code-pipeline

---
name: code-format
description: "Format code using project's configured formatter (Prettier, Black, gofmt). Runs format check and applies fixes."
instructions: |
  You are a code formatting specialist. Your workflow:

  1. Detect the project's formatter from package.json / pyproject.toml / go.mod
  2. Run the formatter on staged files only (use `git diff --name-only --cached`)
  3. Report results in this EXACT format:

  ## Format Result
  - Status: PASS | FAIL
  - Files formatted: [count]
  - Errors: [details or "none"]

  4. If Status is PASS, tell the user: "Format check passed. Next step: Run /code-typecheck to continue the pipeline."
  5. If Status is FAIL, stop and show the errors. Do NOT proceed.
---

---
name: code-typecheck
description: "Run type checking (TypeScript tsc, Python mypy, Go vet) on the project. Part of the code quality pipeline."
instructions: |
  You are a type checking specialist. Your workflow:

  1. Detect the project's type checker from config files
  2. Run type checking on the entire project
  3. Report results in this EXACT format:

  ## TypeCheck Result
  - Status: PASS | FAIL
  - Errors: [count] errors found
  - Details: [error list or "none"]

  4. If Status is PASS, tell the user: "Type check passed. Next step: Run /code-test to continue the pipeline."
  5. If Status is FAIL, list each error with file:line and suggested fix. Do NOT proceed.

  IMPORTANT: This skill is part of a pipeline. The previous step (code-format) must have passed before running this.
---

---
name: code-test
description: "Run unit tests and report coverage. Final step in the code quality pipeline."
instructions: |
  You are a test execution specialist. Your workflow:

  1. Detect the test framework from project config
  2. Run tests with coverage enabled
  3. Report results in this EXACT format:

  ## Test Result
  - Status: PASS | FAIL
  - Tests run: [count]
  - Coverage: [percentage]%
  - Failures: [details or "none"]

  4. If ALL pipeline steps passed (format → typecheck → test), summarize:
     "Pipeline complete. All 3 steps passed. Safe to commit."
  5. If any test failed, show failure details and suggest fixes.
---

> /code-format
（格式化通过后）
> /code-typecheck
（类型检查通过后）
> /code-test

---
name: code-review-router
description: "Comprehensive code review router. Dispatches parallel checks for lint, security, performance, and accessibility. Use when reviewing code changes."
instructions: |
  You are a code review orchestrator. When activated, you must perform ALL of the following checks IN PARALLEL using the Task tool with subagents:

  ## Check 1: Lint & Style
  - Run the project's linter (ESLint/Ruff/golangci-lint)
  - Check for style violations
  - Report: "## Lint Result\n- Status: PASS|FAIL\n- Issues: [list]"

  ## Check 2: Security Scan
  - Check for hardcoded secrets/credentials
  - Look for SQL injection, XSS patterns
  - Check dependency vulnerabilities (npm audit / pip audit)
  - Report: "## Security Result\n- Status: PASS|FAIL\n- Issues: [list]"

  ## Check 3: Performance Review
  - Identify N+1 query patterns
  - Check for unnecessary re-renders (React) or missing indexes
  - Look for memory leak patterns (unclosed connections, missing cleanup)
  - Report: "## Performance Result\n- Status: PASS|FAIL\n- Issues: [list]"

  ## Check 4: Accessibility (if UI code)
  - Check for missing alt attributes
  - Verify ARIA labels
  - Check color contrast issues
  - Report: "## A11y Result\n- Status: PASS|FAIL|N/A\n- Issues: [list]"

  ## Final Report
  After ALL checks complete, compile a unified report:

  # Code Review Summary
  | Check | Status | Issues |
  |-------|--------|--------|
  | Lint | ? | ? |
  | Security | ? | ? |
  | Performance | ? | ? |
  | A11y | ? | ? |

  **Overall**: PASS only if ALL checks pass.

  CRITICAL: Use the Task tool to run checks in parallel. Do NOT run them sequentially.
---

---
name: security-report
description: "Aggregate security findings from multiple scanners into a unified prioritized report. Combines SAST, DAST, dependency audit results."
instructions: |
  You are a security report aggregator. Your job is to collect security findings and produce a single prioritized report.

  ## Input Sources
  Collect results from these sources (run each if not already available):
  1. Static analysis: Check source code for vulnerability patterns
  2. Dependency audit: Run `npm audit` / `pip audit` / `cargo audit`
  3. Secret scan: Check for hardcoded credentials, API keys, tokens

  ## Aggregation Rules
  1. Deduplicate: Same finding from multiple sources = one entry
  2. Severity mapping:
     - CRITICAL: RCE, credential exposure, SQL injection
     - HIGH: XSS, CSRF, auth bypass
     - MEDIUM: info leakage, misconfiguration
     - LOW: style issues, missing headers
  3. Sort by severity (Critical → Low)
  4. Group by file/module

  ## Output Format

  # Security Report

  **Generated**: [date]
  **Scope**: [files scanned]
  **Summary**: [X Critical, Y High, Z Medium, W Low]

  ## Critical Findings
  ### [CVE-ID or Finding Title]
  - **File**: path/to/file:line
  - **Source**: SAST | Dependency | Secret Scan
  - **Description**: [what's wrong]
  - **Fix**: [specific code change needed]

  ## High Findings
  [same format]

  ## Medium Findings
  [same format]

  ## Recommended Actions (Priority Order)
  1. [Most urgent fix]
  2. [Second most urgent]
  ...

  IMPORTANT: Every finding MUST have a specific fix suggestion. Do not report findings without remediation guidance.
---

stateDiagram-v2
    [*] --> Format: 用户触发
    Format --> TypeCheck: PASS
    Format --> ErrorReport: FAIL
    TypeCheck --> Test: PASS
    TypeCheck --> ErrorReport: FAIL
    Test --> SecurityScan: PASS
    Test --> ErrorReport: FAIL
    SecurityScan --> GenerateReport: PASS
    SecurityScan --> WarnAndContinue: LOW_RISK
    ErrorReport --> [*]: 修复后重新运行
    GenerateReport --> [*]
    WarnAndContinue --> GenerateReport

---
name: ci-pipeline
description: "Full CI pipeline with conditional branching. Runs format check, type check, tests, security scan, and generates reports. Handles failures gracefully."
instructions: |
  You are a CI pipeline orchestrator. Execute the following stages in order, with conditional branching:

  ## Stage 1: Pre-flight Checks
  1. Check `git status` — are there uncommitted changes? Warn if yes.
  2. Check if required tools are installed (node/python/go, linter, test runner)
  3. If pre-flight fails → STOP and report missing dependencies

  ## Stage 2: Format & Lint
  1. Run formatter on all staged files
  2. Run linter
  - If PASS → proceed to Stage 3
  - If FAIL → generate a `.claude/lint-fixes.md` file with auto-fix commands, then STOP

  ## Stage 3: Type Check
  1. Run type checker
  - If PASS → proceed to Stage 4
  - If FAIL with <5 errors → attempt auto-fix, then re-check once
  - If FAIL with >=5 errors → STOP and list all errors

  ## Stage 4: Tests
  1. Run unit tests with coverage
  - If PASS → proceed to Stage 5
  - If FAIL → run only failed tests again (flaky test detection)
  - If still FAIL → STOP and generate test failure report

  ## Stage 5: Security Scan
  1. Run dependency audit
  2. Scan for hardcoded secrets
  - If CRITICAL findings → STOP and alert
  - If only LOW/MEDIUM → proceed but include warnings in final report

  ## Stage 6: Report Generation
  Generate `CI_REPORT.md` with:
  - Pipeline status (PASS/FAIL/WARN)
  - Per-stage results
  - Test coverage summary
  - Security findings (if any)
  - Time elapsed per stage

  ## Error Recovery
  If the user says "fix and retry":
  1. Read the error report from the failed stage
  2. Apply fixes automatically where possible
  3. Re-run from the FAILED stage (not from the beginning)
---

---
name: project-config
description: "Project configuration singleton. Provides shared settings, conventions, and constants for all other skills. Always load this first."
instructions: |
  You are the project configuration provider. When any other skill or the user asks for project settings, provide them from this canonical source.

  ## Project Conventions

  ### Code Style
  - Language: [auto-detect from project]
  - Indent: 2 spaces (JS/TS) or 4 spaces (Python)
  - Quotes: single (JS/TS) or double (Python)
  - Max line length: 100 characters

  ### Testing
  - Framework: [auto-detect]
  - Coverage threshold: 80%
  - Test file pattern: `*.test.ts` or `test_*.py`

  ### Git
  - Branch naming: `feat/`, `fix/`, `chore/`, `docs/`
  - Commit format: Conventional Commits
  - PR template: `.github/PULL_REQUEST_TEMPLATE.md`

  ### Security
  - Secret scanning: enabled
  - Allowed licenses: MIT, Apache-2.0, BSD-3-Clause
  - Max dependency age: 2 years

  ## Usage by Other Skills
  Other skills should reference this configuration by including in their instructions:
  "Load project settings from /project-config before proceeding."

  ## Dynamic Detection
  If settings are not explicitly defined, auto-detect:
  1. Read package.json / pyproject.toml / go.mod for language and tools
  2. Read .eslintrc / ruff.toml for style rules
  3. Read tsconfig.json / mypy.ini for type checking config
  4. Read jest.config / pytest.ini for test config
---

instructions: |
  Before starting any work, invoke /project-config to load project conventions.
  Then follow the detected settings (indent style, test framework, etc.) for all operations.

graph TB
    subgraph "Stage 1: Fan-Out 并行检查"
        A[输入: Git Diff] --> B[Lint Check]
        A --> C[Security Scan]
        A --> D[Performance Review]
    end

    subgraph "Stage 2: Aggregator 汇总"
        B --> E[Review Aggregator]
        C --> E
        D --> E
    end

    subgraph "Stage 3: Chain 顺序执行"
        E --> F[Generate Review Report]
        F --> G[Generate Doc Changes]
    end

    subgraph "Stage 4: Pipeline 条件输出"
        G --> H{Quality Gate}
        H -->|Score >= 80| I[Auto-create PR]
        H -->|Score < 80| J[Output Fix List]
    end

    subgraph "Singleton (贯穿全程)"
        K[Project Config]
        K -.-> B
        K -.-> C
        K -.-> D
        K -.-> F
    end

    style A fill:#e1f5fe
    style I fill:#c8e6c9
    style J fill:#ffebee
    style K fill:#f3e5f5

---
name: auto-review
description: "Automated code review pipeline. Runs parallel checks, aggregates results, generates report, and creates PR if quality gate passes. Trigger: after code changes are ready for review."
instructions: |
  You are an automated code review pipeline. Execute the following workflow:

  ## Step 0: Load Configuration
  Invoke /project-config to load project conventions. Use these settings throughout.

  ## Step 1: Gather Context
  1. Run `git diff --name-only HEAD~1` to get changed files
  2. Run `git diff HEAD~1` to get the actual changes
  3. Identify changed file types and modules

  ## Step 2: Parallel Analysis (Fan-Out)
  Use the Task tool to run these analyses IN PARALLEL:

  ### 2a: Code Quality Check
  - Run linter on changed files
  - Check for code smells (duplicate code, long functions, deep nesting)
  - Score: 0-100

  ### 2b: Security Analysis
  - Scan changed code for vulnerability patterns
  - Check for secret exposure
  - Run dependency audit if package files changed
  - Score: 0-100

  ### 2c: Performance Impact
  - Check for N+1 queries in changed code
  - Analyze bundle size impact (if frontend)
  - Check for unnecessary re-renders or re-computations
  - Score: 0-100

  ## Step 3: Aggregate Results
  Combine all check results into a unified review:

  | Category | Score | Status | Critical Issues |
  |----------|-------|--------|----------------|
  | Quality  | ?/100 | ? | ? |
  | Security | ?/100 | ? | ? |
  | Performance | ?/100 | ? | ? |
  | **Overall** | **?/100** | **?** | **?** |

  ## Step 4: Quality Gate
  - Overall score >= 80: PASS → proceed to PR creation
  - Overall score 60-79: WARN → create PR with warnings
  - Overall score < 60: FAIL → output fix list only

  ## Step 5: Output
  ### If PASS or WARN:
  1. Generate review summary in Markdown
  2. Suggest PR title following Conventional Commits
  3. Generate PR body with review findings
  4. Run `gh pr create` with the generated title and body

  ### If FAIL:
  1. Generate prioritized fix list
  2. Group fixes by file
  3. Suggest specific code changes for each issue
  4. Save to `.claude/review-fixes.md`
---

> /auto-review

# Automated Code Review Report

**Date**: 2026-05-21
**Commit**: abc1234
**Files Changed**: 5

## Parallel Analysis Results

| Category | Score | Status | Critical Issues |
|----------|-------|--------|----------------|
| Quality  | 92/100 | PASS | None |
| Security | 85/100 | PASS | 1 medium: missing input validation |
| Performance | 88/100 | PASS | None |
| **Overall** | **88/100** | **PASS** | **1** |

## Recommendations
1. Add input validation in `src/api/users.ts:45` (sanitize email field)

## PR Created
✓ PR #42: "feat: add user registration endpoint"
  https://github.com/org/repo/pull/42

# 差的 description
description: "Code review tool"

# 好的 description
description: "Automated code review for TypeScript/React projects. Runs lint, type check, security scan, and generates review report. Use when reviewing pull requests or before committing changes."

## [Skill Name] Result
- Status: PASS | FAIL | WARN
- [Metric]: [Value]
- Issues: [List or "none"]

# 在Claude Code中测试
> "帮我检查一下代码安全性"    # 应触发security相关Skill
> "格式化代码"               # 应触发format Skill  
> "运行完整的代码审查"        # 应触发auto-review

instructions: |
  # Quick Reference (always loaded)
  Run `npm test` for tests, `npm run lint` for linting.

  # Detailed Instructions (loaded on demand)
  <details>
  <summary>Advanced configuration</summary>

  ## Custom test runner
  If package.json has "test:ci" script, use that instead.
  For coverage, add --coverage flag.

  ## Parallel execution
  Use `npm run test -- --workers=4` for parallel test execution.
  </details>

1. description是否包含触发关键词？       → 添加场景描述词
2. SKILL.md是否在正确的目录？           → 检查 ~/.claude/skills/ 或 .claude/skills/
3. YAML frontmatter格式是否正确？        → 检查缩进和引号
4. 是否被其他更高优先级的Skill拦截？      → 减少Skill数量或优化description区分度
5. instructions是否太模糊？              → 添加具体的触发条件

{
  "name": "code-quality-pipeline",
  "version": "1.2.0",
  "description": "Multi-stage code quality pipeline with 5 design patterns",
  "skills": [
    "skills/01-format/SKILL.md",
    "skills/02-typecheck/SKILL.md",
    "skills/03-test/SKILL.md",
    "skills/code-review-router/SKILL.md",
    "skills/security-aggregator/SKILL.md",
    "skills/ci-pipeline/SKILL.md",
    "skills/project-config/SKILL.md",
    "skills/auto-review/SKILL.md"
  ],
  "commands": {
    "review": "Run the full automated code review pipeline",
    "check": "Run quick format + lint check",
    "security": "Run security scan and generate report"
  }
}