kazuki nakai d5dfd7da21
refactor(docs): normalize documentation naming to lowercase for PEP8 compliance (#434)
* refactor(docs): rename directories to lowercase for PEP8 compliance

- Developer-Guide → developer-guide
- Getting-Started → getting-started
- Reference → reference
- Templates → templates
- User-Guide → user-guide
- User-Guide-jp → user-guide-jp
- User-Guide-kr → user-guide-kr
- User-Guide-zh → user-guide-zh

This change aligns with Python PEP8 package naming conventions.
All 43 files affected.

* refactor: rename root documentation files to lowercase

- CHANGELOG.md → changelog.md
- CODE_OF_CONDUCT.md → code_of_conduct.md
- CONTRIBUTING.md → contributing.md
- SECURITY.md → security.md

Aligns with Python package naming conventions (PEP8).
README files remain uppercase as per convention.

* refactor: move documentation files to docs/ for cleaner root

Moved OSS standard files to docs/:
- CHANGELOG.md → docs/CHANGELOG.md
- CODE_OF_CONDUCT.md → docs/CODE_OF_CONDUCT.md
- CONTRIBUTING.md → docs/CONTRIBUTING.md
- SECURITY.md → docs/SECURITY.md

Root now contains only essential files:
✓ README files (表紙: en, ja, kr, zh)
✓ LICENSE (法的要件)
✓ Build configs (pyproject.toml, setup.py, MANIFEST.in)
✓ VERSION

Rationale:
Cleaner root structure following modern Python project conventions.
All detailed documentation consolidated in docs/ directory.

* refactor: update documentation links after restructure

Auto-updated internal documentation links to reflect new structure:
- docs/ subdirectories now lowercase (PEP8)
- Root files moved to docs/
- All cross-references updated

This commit includes linter-generated link updates.

* chore(docs): keep OSS-standard uppercase root files (CHANGELOG, CODE_OF_CONDUCT, CONTRIBUTING, SECURITY)

* chore(docs): remove duplicated PR docs from repo root (moved under docs)

* docs: rename pm-agent-implementation-status.md -> PM_AGENT.md for clarity

* docs: update links to PM_AGENT.md after rename

---------

Co-authored-by: kazuki <kazuki@kazukinoMacBook-Air.local>
2025-10-15 21:07:39 +05:30

22 KiB
Raw Blame History

SuperClaude 行为模式指南 🧠

快速验证

使用 /sc: 命令测试模式 - 它们会根据任务复杂性自动激活。有关完整命令参考,请参阅 命令指南

快速参考表

模式 目的 自动触发 关键行为 最适合
🧠 头脑风暴 交互式发现 "brainstorm"、"maybe"、模糊请求 苏格拉底式问题、需求发掘 新项目规划、不明确需求
🔍 内省 元认知分析 错误恢复、"分析推理" 透明思维标记 (🤔, 🎯, 💡) 调试、学习、优化
📋 任务管理 复杂协调 >3 步骤、>2 目录 阶段分解、内存持久化 多步操作、项目管理
🎯 编排 智能工具选择 多工具操作、高资源使用 最优工具路由、并行执行 复杂分析、性能优化
令牌效率 压缩通信 高上下文使用、--uc 标志 符号系统,预计减少 30-50% 令牌 资源约束、大型操作

入门指南2 分钟概览)

模式通过行为指令激活 - Claude Code 读取上下文文件,根据您的任务模式和复杂性来决定采用哪种模式行为。

快速示例:

# 自动激活示例
/sc:brainstorm "mobile app"        # → 苏格拉底式发现问题
/sc:implement "authentication system"        # → 多阶段协调
"--uc analyze large-codebase/"     # → 压缩符号输出

何时使用手动标志:

  • 需要特定行为:--brainstorm--introspect--uc
  • 为学习/调试而覆盖自动检测
  • 针对特定约束进行优化(内存、时间、清晰度)

模式详情

🧠 头脑风暴模式 - 交互式发现

目的:通过协作发现将模糊的想法转化为结构化的需求。

自动激活触发器:

  • 模糊的项目请求:"我想构建..."、"正在考虑创建..."
  • 探索关键词brainstorm、explore、discuss、figure out、not sure
  • 不确定指示器:"maybe"、"possibly"、"could we"
  • 手动标志:--brainstorm--bs

行为变化:

  • 苏格拉底式提问:提出探性问题以发掘隐藏需求
  • 非预设性方法:避免假设,让您引导发现方向
  • 协作伙伴关系:在探索中与您合作,而不是指导性咨询
  • 需求综合:将见解转化为结构化的技术简报
  • 跨会话内存:为后续讨论维护发现上下文

体验示例:

Standard Approach: "I'll build a user authentication system with JWT tokens..."
Brainstorming Approach: 
"🤔 Let's explore this together:
 - What specific user problems does auth solve for your app?
 - Who are your users and what's their technical comfort level?  
 - Any existing systems or social logins to integrate with?
 - What security/compliance requirements do you have?
 📝 Outcome: Detailed auth requirements brief ready for implementation"

成功标准

  • 用问题而不是直接解决方案来回应
  • 问题探索用户需求、技术约束和业务目标
  • 在整个发现过程中保持协作语调
  • 产生结构化需求或技术简介作为结果

验证: /sc:brainstorm "web app" 应该询问用户、功能、技术相关问题 测试: 模糊请求应该触发发现性问题,而不是假设 检查: 模式应该在同一会话的后续问题中保持一致

最佳搭配:

  • → 任务管理:需求发现 → 系统性实施规划
  • → 编排:需求明确化 → 实施的最优工具选择
  • 手动覆盖:使用 --brainstorm 强制发现,即使对于"明确"的需求

🔍 内省模式 - 元认知分析

目的:为学习优化和透明决策制定暴露推理过程。

自动激活触发器:

  • 自我分析请求:"分析我的推理"、"反思决策"
  • 错误恢复场景和需要调查的意外结果
  • 具有多种可行方法的复杂问题求解
  • 优化机会的模式识别需求
  • 手动标志:--introspect

行为变化:

  • 推理透明度:通过清晰标记暴露思维过程 (🤔, 🎯, , 📊, 💡)
  • 决策分析:评估选择逻辑并考虑替代方案
  • 模式识别:识别重复行为和改进机会
  • 元学习:提取见解以持续改进框架
  • 框架合规性:根据 SuperClaude 原则和质量门控验证行为

体验示例:

Standard Approach: "I'll analyze this code structure and suggest improvements..."
Introspective Approach:
"🧠 Meta-Analysis: Why did I choose structural analysis over functional flow analysis?
 🎯 Decision Logic: Saw class hierarchy → assumed OOP patterns dominate
 🔄 Alternative Considered: Data flow analysis might reveal hidden dependencies
 📊 Evidence Check: File imports suggest functional composition, not OOP
 💡 Learning: Need to analyze imports before choosing analysis strategy
 ⚡ Correction: Switching to functional flow analysis approach"

最佳搭配:

  • → 任务管理:为复杂阶段决策提供透明推理
  • 任何模式:为任何其他模式的操作添加推理透明度层
  • 手动覆盖:在学习会话和调试工作流中使用 --introspect

📋 任务管理模式 - 复杂协调

目的:具有会话持久性的分层任务组织,用于多步操作。

自动激活触发器:

  • 需要超过 3 个协调步骤的操作
  • 多文件/目录范围(>2 目录或 >3 文件)
  • 需要阶段和检查点的复杂依赖关系
  • 质量改进请求:完善、优化、增强
  • 手动标志:--task-manage--delegate

行为变化:

  • 分层规划:将复杂工作分解为计划 → 阶段 → 任务 → 待办结构
  • 会话持久性:在中断期间维护项目上下文和进度
  • 内存集成:使用 write_memory/read_memory 进行状态保存
  • 进度编排:协调 TodoWrite 与内存更新以进行跟踪
  • 质量门控:在阶段之间实施系统验证检查点

体验示例:

Standard Approach: "I'll implement user authentication..." → Direct implementation
Task Management Approach:
"📋 Multi-Phase Implementation Plan:
 🎯 Phase 1: Security requirements analysis (Session 1)
 🎯 Phase 2: API design & documentation (Session 2)
 🎯 Phase 3: Implementation & testing (Sessions 3-4)
 🎯 Phase 4: Integration & validation (Session 5)
 💾 Session Persistence: Auto-resume context
 ✓ Quality Gates: Validation before each phase transition"

最佳搭配:

  • 头脑风暴 →:需求发现然后系统化实施
  • + 编排:任务协调与最优工具选择
  • + 内省:复杂阶段决策的透明推理

🎯 编排模式 - 智能工具选择

目的:通过智能工具路由和并行协调优化任务执行。

自动激活触发器:

  • 需要复杂协调的多工具操作
  • 性能约束(高资源使用)
  • 并行执行机会(>3 个独立文件/操作)
  • 具有多种有效工具方法的复杂路由决策

行为变化:

  • 智能工具路由:为每种任务类型选择最优的 MCP 服务器和原生工具
  • 资源感知:基于系统约束和可用性调整方法
  • 并行优化:识别独立操作以进行并发执行
  • 协调焦点:通过协调执行优化工具选择和使用
  • 自适应回退:当首选选项不可用时优雅地切换工具

体验示例:

Standard Approach: Sequential file-by-file analysis and editing
Orchestration Approach:
"🎯 Multi-Tool Coordination Strategy:
 🔍 Phase 1: Serena (semantic analysis) + Sequential (architecture review)
 ⚡ Phase 2: Morphllm (pattern edits) + Magic (UI components)
 🧪 Phase 3: Playwright (testing) + Context7 (doc patterns)
 🔄 Parallel Execution: 3 tools working simultaneously"

最佳搭配:

  • 任务管理 →:为复杂多阶段计划提供工具协调
  • + 令牌效率:带压缩通信的最优工具选择
  • 任何复杂任务:添加智能工具路由以增强执行

令牌效率模式 - 压缩通信

目的:通过符号系统实现预计 30-50% 的令牌减少,同时保持信息质量。

自动激活触发器:

  • 高上下文使用接近限制
  • 需要资源效率的大规模操作
  • 用户显式标志:--uc--ultracompressed
  • 具有多个输出的复杂分析工作流

行为变化:

  • 符号通信:为逻辑流程、状态和技术领域使用视觉符号
  • 技术缩写:对重复技术术语进行上下文感知压缩
  • 结构化密度:使用要点、表格和简洁格式,而非冗长段落
  • 信息保留:尽管压缩,仍保持 ≥95% 的信息质量
  • 结构化格式:为清晰度和任务完成而组织

体验示例:

Standard Approach: "Authentication system implementation shows security vulnerability in user validation function requiring immediate attention..."
Token-Efficient Approach:
"🛡️ Security Alert:
 auth.js:45 → user val() → critical vuln
 📊 Impact: ❌ possible token bypass
 ⚡ Action: fix validation + audit ∵ high severity
 🔧 Estimate: 2hr impl + 1hr test"

最佳搭配:

  • 任何模式:在保持特定模式行为的同时添加压缩层
  • 编排 →:压缩的工具协调和状态更新
  • 手动覆盖:当上下文压力或效率是优先级时使用 --uc

🎨 标准模式 - 均衡默认

目的:为直接的开发任务提供清晰、专业的沟通。

自动激活触发器:

  • 没有复杂性指标的简单、明确定义的任务
  • 具有明确要求的单文件操作
  • 基本解释和标准开发工作流
  • 未检测到其他模式触发器(默认回退)

行为变化:

  • 专业沟通:清晰、简洁的技术语言,无压缩
  • 适度细节:适合大多数开发任务的平衡信息深度
  • 标准工具选择:使用原生 Claude 能力和基本工具
  • 质量焦点:在无复杂编排开销的情况下保持代码质量
  • 响应式适应:当复杂性增加时准备切换到专门模式

体验示例:

Standard Approach: Consistent, professional baseline for all tasks
"I'll implement the login functionality with proper error handling:

 1. Validate user input (email format, password requirements)
 2. Authenticate against database with secure hashing
 3. Generate JWT token with appropriate expiration
 4. Return success response with user data

 Implementation will follow security best practices and include comprehensive error handling."

最佳搭配:

  • → 任何模式:作为其他模式增强的基线
  • 模式切换:需要时自动升级到专门模式
  • 清晰优先:当直接沟通比优化更重要时

高级用法

模式组合

多模式工作流:

# 发现 → 规划 → 实现
/sc:brainstorm "microservices architecture" --task-manage
# → 头脑风暴:需求发现
# → 任务管理:多阶段协调

# 透明和高效的分析
/sc:analyze legacy-system/ --introspect --uc
# → 内省:透明推理
# → 令牌效率:压缩输出

手动模式控制

强制特定行为:

  • --brainstorm:为任何任务强制协作发现
  • --introspect:为任何模式添加推理透明度
  • --task-manage:启用分层协调
  • --orchestrate:优化工具选择和并行执行
  • --uc:为效率压缩通信

覆盖示例:

# 对“明确”的需求强制头脑风暴
/sc:implement "user login" --brainstorm

# 为调试添加推理透明度
# 使用透明推理调试认证问题

# 为简单操作启用任务管理
# 系统化任务管理更新样式文件

模式边界和优先级

模式激活时机:

  1. 复杂度阈值>3 文件 → 任务管理
  2. 资源压力:高上下文使用 → 令牌效率
  3. 多工具需求:复杂分析 → 编排
  4. 不确定性:模糊需求 → 头脑风暴
  5. 错误恢复:问题 → 内省

优先级规则:

  • 安全第一:质量和验证总是覆盖效率
  • 用户意图:手动标志覆盖自动检测
  • 上下文适应:基于复杂性堆叠模式
  • 资源管理:在压力下激活效率模式

现实世界示例

完整工作流示例

新项目开发:

# 阶段 1发现头脑风暴模式自动激活
"I want to build a productivity app"
→ 🤔 关于用户、功能、平台选择的苏格拉底式问题
→ 📝 结构化需求简报

# 阶段 2规划任务管理模式自动激活
/sc:implement "core productivity features"
→ 📋 带依赖关系的多阶段分解
→ 🎯 带质量门控的阶段协调

# 阶段 3实现编排模式协调工具
/sc:implement "frontend and backend systems"
→ 🎯 Magic (UI) + Context7 (模式) + Sequential (架构)
→ ⚡ 并行执行优化

调试复杂问题:

# 问题分析(内省模式自动激活)
"Users experiencing intermittent authentication failures"
→ 🤔 关于潜在原因的透明推理
→ 🎯 假设形成和证据收集
→ 💡 跨相似问题的模式识别

# 系统性解决(任务管理协调)
# 全面修复认证系统
→ 📋 阶段 1根因分析
→ 📋 阶段 2解决方案实现
→ 📋 阶段 3测试和验证

模式组合模式

高复杂度场景:

# 带多重约束的大型重构
/sc:improve legacy-system/ --introspect --uc --orchestrate
→ 🔍 透明推理introspect内省
→ ⚡ 压缩通信uc令牌效率
→ 🎯 最优工具协调orchestrate编排
→ 📋 系统化阶段(任务管理自动激活)

快速参考

模式激活模式

触发类型 输入示例 激活模式 关键行为
模糊请求 "我想构建一个应用" 🧠 头脑风暴 苏格拉底式发现问题
复杂范围 >3 文件或 >2 目录 📋 任务管理 阶段协调
多工具需求 分析 + 实施 🎯 编排 工具优化
错误恢复 "这没有按预期工作" 🔍 内省 透明推理
资源压力 高上下文使用 令牌效率 符号压缩
简单任务 "修复这个函数" 🎨 标准 清晰、直接的方法

手动覆盖命令

# 强制特定模式行为
/sc:command --brainstorm    # 协作发现
/sc:command --introspect    # 推理透明度
/sc:command --task-manage   # 分层协调
/sc:command --orchestrate   # 工具优化
/sc:command --uc            # 令牌压缩

# 组合多种模式
/sc:command --introspect --uc    # 透明 + 高效
/sc:command --task-manage --orchestrate  # 协调 + 优化

故障排除

有关故障排除帮助,请参阅:

常见问题

  • 模式未激活:使用手动标志:--brainstorm--introspect--uc
  • 激活了错误的模式:检查请求中的复杂性触发器和关键词
  • 模式意外切换:基于任务演化的正常行为
  • 执行影响:模式优化工具使用,不应影响执行
  • 模式冲突:检查标志指南中的标志优先级规则

即时修复

  • 强制特定模式:使用明确标志如 --brainstorm--task-manage
  • 重置模式行为:重启 Claude Code 会话以重置模式状态
  • 检查模式指示器:在响应中查找 🤔🎯📋 符号
  • 验证复杂性:简单任务使用标准模式,复杂任务自动切换

特定模式故障排除

头脑风暴模式问题:

# 问题:模式给出解决方案而不是问题
# 快速修复:检查请求清晰度并使用显式标志
/sc:brainstorm "web app" --brainstorm         # 强制发现模式
"I have a vague idea about..."                # 使用不确定语言
"Maybe we could build..."                     # 触发探索

任务管理模式问题:

# 问题:简单任务得到复杂协调
# 快速修复:减少范围或使用更简单的命令
/sc:implement "function" --no-task-manage     # 禁用协调
/sc:troubleshoot bug.js                       # 使用基本命令
# 检查任务是否真正复杂(>3 文件,>2 目录)

令牌效率模式问题:

# 问题:输出过于压缩或不清楚
# 快速修复:禁用压缩以提高清晰度
/sc:command --no-uc                           # 禁用压缩
/sc:command --verbose                         # 强制详细输出
# 当清晰度比效率更重要时使用

内省模式问题:

# 问题:过多元评论,行动不足
# 快速修复:为直接工作禁用内省
/sc:command --no-introspect                   # 直接执行
# 仅在学习和调试时使用内省

编排模式问题:

# 问题:工具协调造成混乱
# 快速修复:简化工具使用
/sc:command --no-mcp                          # 仅使用原生工具
/sc:command --simple                          # 基本执行
# 检查任务复杂度是否需要编排

错误代码参考

模式错误 含义 快速修复
B001 头脑风暴激活失败 使用显式 --brainstorm 标志
T001 任务管理开销 对简单任务使用 --no-task-manage
U001 令牌效率过于激进 使用 --verbose--no-uc
I001 内省模式卡住 对直接行动使用 --no-introspect
O001 编排协调失败 使用 --no-mcp--simple
M001 检测到模式冲突 检查标志优先级规则
M002 模式切换循环 重启会话以重置状态
M003 模式无法识别 更新 SuperClaude 或检查拼写

渐进式支持级别

级别 1快速修复< 2 分钟)

  • 使用手动标志覆盖自动模式选择
  • 检查任务复杂性是否与预期模式行为匹配
  • 尝试重启 Claude Code 会话

级别 2详细帮助5-15 分钟)

# 特定模式诊断
/sc:help modes                            # 列出所有可用模式
/sc:reflect --type mode-status            # 检查当前模式状态
# 检查请求复杂性和触发器

级别 3专家支持30+ 分钟)

# 深度模式分析
SuperClaude install --diagnose
# 检查模式激活模式
# 检查行为触发器和阈值

级别 4社区支持

  • GitHub Issues 报告模式问题
  • 包括意外模式行为的示例
  • 描述期望与实际模式激活的差异

成功验证

应用模式修复后,进行测试:

  • 简单请求使用标准模式(清晰、直接的响应)
  • 复杂请求自动激活适当的模式(协调、推理)
  • 手动标志正确覆盖自动检测
  • 模式指示器(🤔🎯📋)在预期时出现
  • 在不同模式下性能保持良好

快速故障排除(旧版)

  • 模式未激活 → 使用手动标志:--brainstorm--introspect--uc
  • 激活了错误的模式 → 检查请求中的复杂性触发器和关键词
  • 模式意外切换 → 基于任务演化的正常行为
  • 执行影响 → 模式优化工具使用,不应影响执行
  • 模式冲突 → 检查标志指南中的标志优先级规则

常见问题

问:如何知道哪个模式处于激活状态? 答:在通信模式中查找这些指示器:

  • 🤔 发现性问题 → 头脑风暴
  • 🎯 推理透明度 → 内省
  • 阶段分解 → 任务管理
  • 工具协调 → 编排
  • 符号压缩 → 令牌效率

问:我可以强制特定模式吗? 答:是的,使用手动标志覆盖自动检测:

/sc:command --brainstorm     # 强制发现模式
/sc:command --introspect     # 增加透明性
/sc:command --task-manage    # 启用协调
/sc:command --uc             # 压缩输出

问:模式会影响执行吗? 答:模式通过协调优化工具使用:

  • 令牌效率:上下文减少 30-50%
  • 编排:并行处理
  • 任务管理:通过系统化规划防止返工

问:模式可以协同工作吗? 答:是的,模式设计为互相补充:

  • 任务管理协调其他模式
  • 令牌效率压缩任何模式的输出
  • 内省为任何工作流添加透明度

总结

SuperClaude 的 5 种行为模式创建了一个智能适应系统,自动匹配您的需求:

  • 🧠 头脑风暴:将模糊想法转化为清晰需求
  • 🔍 内省:为学习和调试提供透明推理
  • 📋 任务管理:协调复杂的多步操作
  • 🎯 编排:优化工具选择和并行执行
  • 令牌效率:在保持清晰度的同时压缩通信
  • 🎨 标准:为直接任务维护专业基线

关键洞察:您无需思考模式 - 它们透明地工作以增强您的开发体验。只需描述您想要完成的任务SuperClaude 会自动调整其方法以匹配您的需求。


相关指南

学习进展:

🌱 基础第1周

🌿 中级第2-3周

🌲 高级第2+个月)

🔧 专家级

特定模式指南: