用途
Smell 用于分析代码库，找出违反软件架构原则的问题、反模式、代码“坏味道”以及算法复杂度热点，并产出全面、可操作的 Markdown 报告。其知识库涵盖架构模式、反模式、代码坏味道与算法复杂度启发式，来源包括 Martin Fowler / Kent Beck 的经典代码坏味道目录（按 refactoring.guru 的组织方式：Bloaters、Object-Orientation Abusers、Change Preventers、Dispensables、Couplers）以及行业研究与实践。
主要能力
- 梳理项目范围并确认分析对象（全项目、指定模块、仅最近变更文件，或仅架构级问题）。
- 使用 find、grep 及 Explore 子代理并行扫描代码库，收集候选信号与证据。
- 在确认发现前，结合上下文、调用方、历史、工作负载与度量对候选进行验证。
- 检测的坏味道与反模式类别包括：架构（如 Big Ball of Mud、Violated Layer Boundaries、Distributed Monolith、Anemic Domain Model、Over-Abstraction 等）、耦合（Circular Dependencies、Content Coupling、Common Coupling、Stamp Coupling、Message Chains、Middle Man 等）、内聚（God Object、Shotgun Surgery、Feature Envy、Data Clumps、Divergent Change、Data Class、Lazy Class 等）、设计（Leaky Abstractions、Static Cling、Service Locator Abuse、Violated SOLID、Switch Statements、Refused Bequest、Speculative Generality 等）、代码（Temporary Field、Duplicated Code、Long Method、Long Parameter List、Primitive Obsession、Magic Numbers/Strings、Dead Code 等）、测试（No Tests、Test-Implementation Coupling、Slow Tests）、命名（Vague Names、Inconsistent Naming）、可读性（Deep Nesting / Arrow Anti-Pattern）、复杂度（Nested Loops、Repeated Linear Scan、Sort-in-Loop、N+1 Query Pattern、Render-Path Recompute、Pairwise Comparison、Unnecessary Recompute、Wrong Data Structure）。
- 复杂度启发式覆盖：嵌套循环、循环内 includes/indexOf/.find、循环内排序、循环内数据库/API/HTTP 调用、渲染路径中的 filter().map().sort() 链、成对比较、缺少缓存的重复计算、数据结构选择不当。
使用方式
技能执行分四步：
- 范围澄清：询问用户分析范围（A. 整个项目；B. 指定模块/目录；C. 仅最近变更文件 git diff；D. 仅架构级问题）。若用户未指定，小项目（< 100 文件）默认 A，大项目默认 C。
- 证据收集：使用 Explore 子代理并行扫描，包括项目结构扫描、依赖分析、模块/组件扫描、模式检测、测试扫描、命名与清晰度扫描、复杂度扫描。启发式仅作为候选信号，需结合代码职责、调用方、变更历史、工作负载和有意约束验证，不单凭阈值定级。
- 报告生成：候选检测 → 上下文验证 → 发现确认；按独立根因计数，每条发现使用一个主原则与可选相关原则。按 Critical / Warning / Suggestion 分级，未确定影响的静态候选单独列入“Candidates Requiring Measurement”，不计入严重度总数。报告结构包含执行摘要、检测到的架构风格、按类别发现、详细发现（含类别、严重度、反模式、位置、置信度、证据强度、失败或变更场景、主原则、相关原则、描述、证据、影响、建议、验证方式）、依赖图分析、模块健康评分卡、坏味道分布、重构路线图（立即/短期/长期）、反模式参考附录。
- 保存与呈现：报告保存至 tasks/smell-report-[YYYY-MM-DD-HHmm].md，并向用户呈现简要摘要。
适用场景
- 评估项目架构健康度并识别需优先修复的架构问题。
- 在上线前或重构前排查反模式与复杂度热点。
- 对指定模块或最近变更文件做聚焦审查。
限制
- 静态信号需经上下文验证，静态复杂度不得直接报告为已测瓶颈；性能、规模或优化结论需要基线或代表性工作负载。
- 证据强度（Measured / Observed / Inferred）与置信度（High / Medium / Low/Candidate）分开记录，证据强度不代表严重度。
- 关联原则仅作解释，不单独计数；SOLID 作为总括标签，若有具体证据应使用 SRP、OCP 或 DIP 作为主标签。
- 收费、价格、平台与具体使用步骤本次资料暂未提供。