zhuge-workflow 0.1.0

package/templates/claude/commands/ccg/spec-plan.md

@@ -0,0 +1,225 @@
+---
+description: '多模型分析 → 消除歧义 → 零决策可执行计划'
+---
+<!-- CCG:SPEC:PLAN:START -->
+
+> ⚠️ **上下文注入（阶段一）**
+> 执行本命令前，必须先读取基础规范。参考：`~/.claude/commands/ccg/_context.md`
+>
+> **必读规范**：
+> 1. `.trellis/spec/guides/index.md` - 思维指南
+> 2. 根据开发类型读取 `backend/index.md` 或 `frontend/index.md`
+
+**Core Philosophy**
+- The goal is to eliminate ALL decision points—implementation should be pure mechanical execution.
+- Every ambiguity must be resolved into explicit constraints before proceeding.
+- Multi-model collaboration surfaces blind spots and conflicting assumptions.
+- Every requirement must have Property-Based Testing (PBT) properties—focus on invariants.
+
+**Guardrails**
+- Do not proceed to implementation until every ambiguity is resolved.
+- Multi-model collaboration is **mandatory**: use both Codex and Gemini.
+- If constraints cannot be fully specified, escalate to user or return to research phase.
+- Refer to `openspec/config.yaml` for project conventions.
+
+**Steps**
+1. **Select Change**
+   - Run `/opsx:list` to display Active Changes.
+   - Confirm with user which change ID to refine.
+   - Run `/opsx:status <change_id>` to review current state.
+
+2. **Multi-Model Implementation Analysis (PARALLEL)**
+   - **CRITICAL**: You MUST launch BOTH Codex AND Gemini in a SINGLE message with TWO Bash tool calls.
+   - **DO NOT** call one model first and wait. Launch BOTH simultaneously with `run_in_background: true`.
+
+   **Step 2.1**: In ONE message, make TWO parallel Bash calls:
+
+   **FIRST Bash call (Codex)**:
+   ```
+   Bash({
+     command: "/Users/blackzhuge/.claude/bin/codeagent-wrapper --backend codex - \"$PWD\" <<'EOF'\nAnalyze change <change_id> from backend perspective:\n- Implementation approach\n- Technical risks\n- Alternative architectures\n- Edge cases and failure modes\nOUTPUT: JSON with analysis\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Codex: backend analysis"
+   })
+   ```
+
+   **SECOND Bash call (Gemini) - IN THE SAME MESSAGE**:
+   ```
+   Bash({
+     command: "/Users/blackzhuge/.claude/bin/codeagent-wrapper --backend gemini - \"$PWD\" <<'EOF'\nAnalyze change <change_id> from frontend/integration perspective:\n- Maintainability assessment\n- Scalability considerations\n- Integration conflicts\nOUTPUT: JSON with analysis\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Gemini: frontend analysis"
+   })
+   ```
+
+   **Step 2.2**: After BOTH Bash calls return task IDs, wait for results with TWO TaskOutput calls:
+   ```
+   TaskOutput({ task_id: "<codex_task_id>", block: true, timeout: 600000 })
+   TaskOutput({ task_id: "<gemini_task_id>", block: true, timeout: 600000 })
+   ```
+
+   - Synthesize responses and present consolidated options to user.
+
+3. **Uncertainty Elimination Audit**
+   - **Codex**: "Review proposal for unspecified decision points. List each as: [AMBIGUITY] → [REQUIRED CONSTRAINT]"
+   - **Gemini**: "Identify implicit assumptions. Specify: [ASSUMPTION] → [EXPLICIT CONSTRAINT NEEDED]"
+
+   **Anti-Pattern Detection** (flag and reject):
+   - Information collection without decision boundaries
+   - Technical comparisons without selection criteria
+   - Deferred decisions marked "to be determined during implementation"
+
+   **Target Pattern** (required for approval):
+   - Explicit technology choices with parameters (e.g., "JWT with TTL=15min")
+   - Concrete algorithm selections with configs (e.g., "bcrypt cost=12")
+   - Precise behavioral rules (e.g., "Lock account 30min after 5 failed attempts")
+
+   Iterate with user until ALL ambiguities resolved.
+
+4. **PBT Property Extraction**
+   - **Codex**: "Extract PBT properties. For each requirement: [INVARIANT] → [FALSIFICATION STRATEGY]"
+   - **Gemini**: "Define system properties: [PROPERTY] | [DEFINITION] | [BOUNDARY CONDITIONS] | [COUNTEREXAMPLE GENERATION]"
+
+   **Property Categories**:
+   - **Commutativity/Associativity**: Order-independent operations
+   - **Idempotency**: Repeated operations yield same result
+   - **Round-trip**: Encode→Decode returns original
+   - **Invariant Preservation**: State constraints maintained
+   - **Monotonicity**: Ordering guarantees (e.g., timestamps increase)
+   - **Bounds**: Value ranges, size limits, rate constraints
+
+5. **Update OPSX Artifacts**
+   - The agent will use OpenSpec skills to generate/update:
+     * specs (Requirements + PBT)
+     * design (Technical decisions)
+     * tasks (Zero-decision implementation plan)
+   - Ensure all resolved constraints and PBT properties are included in the generated artifacts.
+
+   **tasks.md 格式约束（强制）**:
+
+   每个任务必须使用 checkbox 格式，便于跟踪进度：
+
+   ```markdown
+   ### 1.1 任务标题
+
+   - [ ] **文件**: `path/to/file.cs`
+
+   **实现要点**:
+   - 要点1
+   - 要点2
+
+   **验收**: 验收标准
+   ```
+
+   **格式规则**：
+   - 每个任务条目必须以 `- [ ]` 开头（待完成）
+   - 完成后标记为 `- [x]`
+   - 文件末尾必须包含进度统计表
+
+   **测试任务（强制）**：
+   - 每个功能实现任务必须有对应的测试任务
+   - 单元测试：覆盖核心逻辑、边界条件、异常处理
+   - 集成测试：覆盖 API 端点、数据库交互、跨模块协作
+   - 测试任务使用独立编号（如 1.2 实现 → 1.3 单元测试 → 1.4 集成测试）
+   - 具体测试框架参考 `openspec/config.yaml` 中的项目约定
+   - **禁止**：跳过测试任务或标记为"后续补充"
+
+   **进度统计表**：
+
+   ```markdown
+   ## 进度统计
+
+   | Phase | 总任务 | 已完成 | 进度 |
+   |-------|--------|--------|------|
+   | Phase 1 | N | 0 | 0% |
+   | **总计** | **N** | **0** | **0%** |
+   ```
+
+6. **创建任务专属上下文配置 (ccg-context.jsonl)**
+
+   基于研究和规划结果，为每个 task 创建上下文配置。
+
+   **6.1 读取 tasks.md 获取任务列表**
+
+   ```bash
+   cat openspec/changes/<change-id>/tasks.md
+   ```
+
+   **6.2 为每个任务分析所需规范**
+
+   使用语义化查询找到与每个任务相关的规范：
+
+   ```
+   mcp__ace-tool__search_context({
+     project_root_path: "$PWD",
+     query: "<任务N描述> 需要遵循的具体规范文件"
+   })
+   ```
+
+   **6.3 创建 ccg-context.jsonl**
+
+   每条规范关联到具体的 task 编号，**必须使用 tasks.md 中的 Phase.Section 编号格式**：
+
+   ```bash
+   cat > openspec/changes/<change-id>/ccg-context.jsonl << 'EOF'
+   {"task": "*", "file": "<通用规范路径>", "reason": "所有任务通用"}
+   {"task": "1.1,1.2", "file": "<规范路径>", "reason": "Phase 1.1-1.2 DTO设计需要此规范"}
+   {"task": "2.5", "file": "<规范路径>", "reason": "Phase 2.5 组件开发需要此规范"}
+   {"task": "3.1", "file": "<规范路径>", "reason": "Phase 3.1 E2E测试需要此规范"}
+   EOF
+   ```
+
+   **字段说明**：
+   - `task`: 任务编号，**必须与 tasks.md 的 Phase.Section 编号一致**（如 `"1.1"`, `"2.5"`, `"3.1"`）
+     - `"*"` 表示所有任务通用
+     - 多个任务用逗号分隔：`"1.1,1.2,1.3"`
+     - 范围表达式不支持，需逐个列出
+   - `file`: 规范文件路径
+   - `reason`: 为什么该规范与此任务相关
+
+   **编号规则（强制）**：
+   - 必须使用 `Phase.Section` 格式（如 `1.1`, `2.5`），禁止使用连续数字（如 `1`, `7`, `16`）
+   - 从 tasks.md 提取编号时，保留原始 Phase.Section 格式
+   - 示例映射：
+     - `### 1.1 预设 DTO` → task: `"1.1"`
+     - `### 2.5 预设选择器组件` → task: `"2.5"`
+     - `### 3.1 E2E 测试` → task: `"3.1"`
+
+   **选择原则**：
+   - 每条规范关联到具体任务，避免注入不相关内容
+   - 所有任务都需要的规范用 `"*"` 标记
+   - 优先选择 index.md 之外的具体规范文件
+
+   **6.4 验证配置**
+
+   ```bash
+   cat openspec/changes/<change-id>/ccg-context.jsonl | while read line; do
+     file=$(echo "$line" | jq -r '.file')
+     if [ ! -f "$file" ]; then
+       echo "警告: $file 不存在"
+     fi
+   done
+   ```
+
+7. **Context Checkpoint**
+   - Report current context usage.
+   - If approaching 80K tokens, suggest: "Run `/clear` and continue with `/ccg:spec-impl`"
+
+**Exit Criteria**
+A change is ready for implementation only when:
+- [ ] All multi-model analyses completed and synthesized
+- [ ] Zero ambiguities remain (verified by step 3 audit)
+- [ ] All PBT properties documented with falsification strategies
+- [ ] Artifacts (specs, design, tasks) generated via OpenSpec skills
+- [ ] **tasks.md 包含单元测试和集成测试任务**（无"后续补充"标记）
+- [ ] **ccg-context.jsonl 已创建**（供 spec-impl/spec-review 使用）
+- [ ] User has explicitly approved all constraint decisions
+
+**Reference**
+- Inspect change: `/opsx:status <id>`
+- Check conflicts: `/opsx:schemas`
+- Search patterns: `rg -n "INVARIANT:|PROPERTY:" openspec/`
+- Use `AskUserQuestion` for ANY ambiguity—never assume
+<!-- CCG:SPEC:PLAN:END -->

package/templates/claude/commands/ccg/spec-research.md

@@ -0,0 +1,113 @@
+---
+description: '需求 → 约束集（并行探索 + OPSX 提案）'
+---
+<!-- CCG:SPEC:RESEARCH:START -->
+
+> ⚠️ **上下文注入（阶段一）**
+> 执行本命令前，必须先读取基础规范。参考：`~/.claude/commands/ccg/_context.md`
+>
+> **执行步骤**：
+> 1. 发现规范目录：`find .trellis/spec -type d`
+> 2. 读取相关目录的 `index.md`
+> 3. 根据任务类型选择性读取具体规范
+
+**Core Philosophy**
+- Research produces **constraint sets**, not information dumps. Each constraint narrows the solution space.
+- Constraints tell subsequent stages "don't consider this direction," enabling mechanical execution without decisions.
+- Output: 约束集合 + 可验证的成功判据 (constraint sets + verifiable success criteria).
+- Strictly adhere to OPSX rules when writing spec-structured documents.
+
+**Guardrails**
+- **STOP! BEFORE ANY OTHER ACTION**: You MUST call `mcp__ace-tool__enhance_prompt` FIRST. This is NON-NEGOTIABLE.
+- **NEVER** divide subagent tasks by roles (e.g., "架构师agent", "安全专家agent").
+- **ALWAYS** divide by context boundaries (e.g., "user-related code", "authentication logic").
+- Each subagent context must be self-contained with independent output.
+- Use `mcp__ace-tool__search_context` to minimize grep/find operations.
+- Do not make architectural decisions—surface constraints that guide decisions.
+
+**Steps**
+0. **MANDATORY: Enhance Requirement FIRST**
+   - **DO THIS IMMEDIATELY. DO NOT SKIP. DO NOT CALL ANY OTHER TOOL FIRST.**
+   - Call:
+   ```
+   mcp__ace-tool__enhance_prompt({
+     prompt: "$ARGUMENTS",
+     conversation_history: "<recent conversation>",
+     project_root_path: "$PWD"
+   })
+   ```
+   - Wait for enhanced prompt result.
+   - Use enhanced prompt for ALL subsequent steps.
+
+1. **Generate OPSX Change**
+   - Create a new change using OPSX command:
+     ```bash
+     /opsx:new "<brief-descriptive-name>"
+     ```
+   - This scaffolds `openspec/changes/<name>/` with proposal.md.
+   - If change already exists, use `/opsx:list` to find it and continue.
+
+2. **Initial Codebase Assessment**
+   - Use `mcp__ace-tool__search_context` to scan codebase.
+   - Determine project scale: single vs multi-directory structure.
+   - **Decision**: If multi-directory → enable parallel Explore subagents.
+
+3. **Define Exploration Boundaries (Context-Based)**
+   - Identify natural context boundaries (NOT functional roles):
+     * Subagent 1: User domain code (models, services, UI)
+     * Subagent 2: Auth & authorization (middleware, session, tokens)
+     * Subagent 3: Infrastructure (configs, deployments, builds)
+   - Each boundary should be self-contained: no cross-communication needed.
+
+4. **Parallel Multi-Model Exploration**
+   - Dispatch Explore subagents with unified output template:
+   ```json
+   {
+     "module_name": "context boundary explored",
+     "existing_structures": ["key patterns found"],
+     "existing_conventions": ["standards in use"],
+     "constraints_discovered": ["hard constraints limiting solution space"],
+     "open_questions": ["ambiguities requiring user input"],
+     "dependencies": ["cross-module dependencies"],
+     "risks": ["potential blockers"],
+     "success_criteria_hints": ["observable success behaviors"]
+   }
+   ```
+   - Run Codex for backend boundaries, Gemini for frontend boundaries.
+
+5. **Aggregate and Synthesize**
+   - Collect all subagent outputs.
+   - Merge into unified constraint sets:
+     * **Hard constraints**: Technical limitations, patterns that cannot be violated
+     * **Soft constraints**: Conventions, preferences, style guides
+     * **Dependencies**: Cross-module relationships affecting implementation order
+     * **Risks**: Blockers needing mitigation
+
+6. **User Interaction for Ambiguity Resolution**
+   - Compile prioritized list of open questions.
+   - Use `AskUserQuestion` tool to present systematically:
+     * Group related questions
+     * Provide context for each
+     * Suggest defaults when applicable
+   - Capture responses as additional constraints.
+
+7. **Finalize OPSX Proposal**
+   - Transform constraint sets into OPSX format:
+     * **Context**: User need + discovered constraints
+     * **Requirements**: Each constraint becomes requirement with scenario
+     * **Success Criteria**: Derived from hints and user confirmations
+   - Ensure proposal includes:
+     * All discovered constraints as requirements
+     * Verifiable scenarios for each requirement
+     * Clear dependencies and sequencing
+     * Risk mitigation strategies
+
+8. **Context Checkpoint**
+   - Report current context usage.
+   - If approaching 80K tokens, suggest: "Run `/clear` and continue with `/ccg:spec-plan`"
+
+**Reference**
+- OPSX CLI: `/opsx:status`, `/opsx:show`
+- Check prior research: `ls openspec/changes/*/`
+- Use `AskUserQuestion` for ANY ambiguity—never assume or guess
+<!-- CCG:SPEC:RESEARCH:END -->

package/templates/claude/commands/ccg/spec-review.md

@@ -0,0 +1,127 @@
+---
+description: '双模型交叉审查（独立工具，随时可用）'
+---
+<!-- CCG:SPEC:REVIEW:START -->
+
+> ⚠️ **上下文注入（阶段一 + 阶段二）**
+> 执行本命令前，必须完成上下文注入。参考：`~/.claude/commands/ccg/_context.md`
+>
+> **阶段一**：发现并读取 `.trellis/spec/` 下相关目录的规范
+> **阶段二**：读取 `openspec/changes/<change-id>/ccg-context.jsonl` 中配置的规范文件
+
+**Core Philosophy**
+- Dual-model cross-validation catches blind spots single-model review would miss.
+- Critical findings SHOULD be addressed before proceeding.
+- Review validates implementation against spec constraints and code quality.
+- This is an independent review tool—can be used anytime, not tied to archive workflow.
+
+**Guardrails**
+- **MANDATORY**: Both Codex AND Gemini must complete review before synthesis.
+- Review scope is strictly limited to the proposal's changes—no scope creep.
+- Refer to `openspec/AGENTS.md` for spec conventions if reviewing OpenSpec proposals.
+
+**Steps**
+1. **Select Proposal**
+   - Run `/opsx:list` to display Active Changes.
+   - Confirm with user which proposal ID to review.
+   - Run `/opsx:show <proposal_id>` to load spec and tasks.
+
+2. **Collect Implementation Artifacts**
+   - Identify all files modified by this proposal.
+   - Use `git diff` or `/opsx:diff <proposal_id>` to get change summary.
+   - Load relevant spec constraints and PBT properties from `openspec/changes/<id>/specs/`.
+
+3. **Multi-Model Review (PARALLEL)**
+   - **CRITICAL**: You MUST launch BOTH Codex AND Gemini in a SINGLE message with TWO Bash tool calls.
+   - **DO NOT** call one model first and wait. Launch BOTH simultaneously with `run_in_background: true`.
+
+   **Step 3.1**: In ONE message, make TWO parallel Bash calls:
+
+   **FIRST Bash call (Codex)**:
+   ```
+   Bash({
+     command: "/Users/blackzhuge/.claude/bin/codeagent-wrapper --backend codex - \"$PWD\" <<'EOF'\nReview proposal <proposal_id> implementation:\n\n## Codex Review Dimensions\n1. **Spec Compliance**: Verify ALL constraints from spec are satisfied\n2. **PBT Properties**: Check invariants, idempotency, bounds are correctly implemented\n3. **Logic Correctness**: Edge cases, error handling, algorithm correctness\n4. **Backend Security**: Injection vulnerabilities, auth checks, input validation\n5. **Regression Risk**: Interface compatibility, type safety, breaking changes\n\n## Output Format (JSON)\n{\n  \"findings\": [\n    {\n      \"severity\": \"Critical|Warning|Info\",\n      \"dimension\": \"spec_compliance|pbt|logic|security|regression\",\n      \"file\": \"path/to/file.ts\",\n      \"line\": 42,\n      \"description\": \"What is wrong\",\n      \"constraint_violated\": \"Constraint ID from spec (if applicable)\",\n      \"fix_suggestion\": \"How to fix\"\n    }\n  ],\n  \"passed_checks\": [\"List of verified constraints/properties\"],\n  \"summary\": \"Overall assessment\"\n}\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Codex: backend/logic review"
+   })
+   ```
+
+   **SECOND Bash call (Gemini) - IN THE SAME MESSAGE**:
+   ```
+   Bash({
+     command: "/Users/blackzhuge/.claude/bin/codeagent-wrapper --backend gemini - \"$PWD\" <<'EOF'\nReview proposal <proposal_id> implementation:\n\n## Gemini Review Dimensions\n1. **Pattern Consistency**: Naming conventions, code style, project patterns\n2. **Maintainability**: Readability, complexity, documentation adequacy\n3. **Integration Risk**: Dependency changes, cross-module impacts\n4. **Frontend Security**: XSS, CSRF, sensitive data exposure\n5. **Spec Alignment**: Implementation matches spec intent (not just letter)\n\n## Output Format (JSON)\n{\n  \"findings\": [\n    {\n      \"severity\": \"Critical|Warning|Info\",\n      \"dimension\": \"patterns|maintainability|integration|security|alignment\",\n      \"file\": \"path/to/file.ts\",\n      \"line\": 42,\n      \"description\": \"What is wrong\",\n      \"spec_reference\": \"Spec section (if applicable)\",\n      \"fix_suggestion\": \"How to fix\"\n    }\n  ],\n  \"passed_checks\": [\"List of verified aspects\"],\n  \"summary\": \"Overall assessment\"\n}\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Gemini: patterns/integration review"
+   })
+   ```
+
+   **Step 3.2**: After BOTH Bash calls return task IDs, wait for results with TWO TaskOutput calls:
+   ```
+   TaskOutput({ task_id: "<codex_task_id>", block: true, timeout: 600000 })
+   TaskOutput({ task_id: "<gemini_task_id>", block: true, timeout: 600000 })
+   ```
+
+4. **Synthesize Findings**
+   - Merge findings from both models.
+   - Deduplicate overlapping issues.
+   - Classify by severity:
+     * **Critical**: Spec violation, security vulnerability, breaking change → MUST fix
+     * **Warning**: Pattern deviation, maintainability concern → SHOULD fix
+     * **Info**: Minor improvement suggestion → MAY fix
+
+5. **Present Review Report**
+   - Display findings grouped by severity:
+   ```
+   ## Review Report: <proposal_id>
+
+   ### Critical (X issues) - MUST FIX
+   - [ ] [SPEC] file.ts:42 - Constraint X violated: description
+   - [ ] [SEC] api.ts:15 - SQL injection vulnerability
+
+   ### Warning (Y issues) - SHOULD FIX
+   - [ ] [PATTERN] utils.ts:88 - Inconsistent naming convention
+
+   ### Info (Z issues) - MAY FIX
+   - [ ] [MAINT] helper.ts:20 - Consider extracting to separate function
+
+   ### Passed Checks
+   - ✅ PBT: Idempotency property verified
+   - ✅ Security: No XSS vulnerabilities found
+   ```
+
+6. **Decision Gate**
+   - **If Critical > 0**:
+     * Present findings to user.
+     * Ask: "Fix now or return to `/ccg:spec-impl` to address?"
+     * Do NOT allow archiving.
+
+   - **If Critical = 0**:
+     * Ask user: "All critical checks passed. Proceed to archive?"
+     * If Warning > 0, recommend addressing before archive.
+
+7. **Optional: Inline Fix Mode**
+   - If user chooses "Fix now" for Critical issues:
+     * Route each fix to appropriate model (backend→Codex, frontend→Gemini).
+     * Apply fix using unified diff patch pattern.
+     * Re-run affected review dimension.
+     * Repeat until Critical = 0.
+
+8. **Context Checkpoint**
+   - Report current context usage.
+   - If approaching 80K tokens, suggest: "Run `/clear` and continue with `/ccg:spec-review` or `/ccg:spec-impl`"
+
+**Exit Criteria**
+Review is complete when:
+- [ ] Both Codex and Gemini reviews completed
+- [ ] All findings synthesized and classified
+- [ ] Zero Critical issues remain (fixed or user-acknowledged)
+- [ ] User decision captured (archive / return to impl / defer)
+
+**Reference**
+- View proposal: `/opsx:show <id>`
+- Check spec constraints: `rg -n "CONSTRAINT:|MUST|INVARIANT:" openspec/changes/<id>/specs/`
+- View implementation diff: `/opsx:diff <id>` or `git diff`
+- Archive (after passing): `/ccg:spec-impl` → Step 10
+<!-- CCG:SPEC:REVIEW:END -->

package/templates/claude/commands/developer/brainstorm.md

@@ -0,0 +1,5 @@
+---
+description: "在进行任何创作工作（例如创建功能、构建组件、添加特性或修改行为）之前，您必须使用此工具。它会在实施之前探索需求和设计。"
+disable-model-invocation: true
+---
+使用brainstorming的技能，并严格按照流程和规范给你的方式去执行

package/templates/claude/commands/developer/design-checklist.md

@@ -0,0 +1,81 @@
+---
+description: 生成设计质量检查清单
+---
+
+基于 S-Tier SaaS 设计标准（参考 Stripe、Airbnb、Linear），对「$ARGUMENTS」进行设计质量检查。
+
+## 检查清单
+
+### 一、核心设计原则
+
+- [ ] **用户优先**：界面是否以用户任务为中心设计
+- [ ] **简洁清晰**：信息层次是否清晰，无冗余元素
+- [ ] **一致性**：颜色、字体、组件是否与现有系统一致
+- [ ] **可访问性**：对比度是否达标（WCAG AA 4.5:1）
+
+### 二、视觉设计
+
+#### 颜色
+- [ ] 主色调使用是否克制（不超过 3 种主色）
+- [ ] 语义色是否正确（成功=绿、错误=红、警告=黄、信息=蓝）
+- [ ] 深色模式是否考虑（如需要）
+
+#### 字体
+- [ ] 标题层级是否清晰（H1 > H2 > H3 > Body）
+- [ ] 正文字号是否舒适（14-16px）
+- [ ] 行高是否合适（1.5-1.7）
+
+#### 间距
+- [ ] 是否使用 8px 基准网格
+- [ ] 元素间距是否一致
+- [ ] 留白是否充足
+
+### 三、交互设计
+
+- [ ] 按钮状态是否完整（默认、悬停、激活、禁用）
+- [ ] 表单验证反馈是否及时
+- [ ] 加载状态是否有提示
+- [ ] 空状态是否有引导
+- [ ] 错误状态是否有恢复建议
+
+### 四、响应式
+
+- [ ] 桌面端（1440px）布局是否正常
+- [ ] 平板端（768px）是否适配
+- [ ] 移动端（375px）是否可用
+- [ ] 无水平滚动条
+
+### 五、可访问性（WCAG 2.1 AA）
+
+- [ ] Tab 键导航顺序是否合理
+- [ ] 焦点状态是否可见
+- [ ] 图片是否有 alt 文本
+- [ ] 表单标签是否关联
+
+### 六、性能
+
+- [ ] 图片是否优化（WebP、懒加载）
+- [ ] 动画是否流畅（60fps）
+- [ ] 首屏加载是否快速
+
+---
+
+## 输出格式
+
+```markdown
+### 设计检查报告：[功能名称]
+
+**总体评分**：⭐⭐⭐⭐☆ (X/5)
+
+#### ✅ 通过项
+- [列出通过的检查项]
+
+#### ⚠️ 建议改进
+- [问题描述] → [改进建议]
+
+#### ❌ 必须修复
+- [问题描述] → [修复方案]
+
+#### 截图/示意（如有）
+[相关截图或 ASCII 示意]
+```