القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill coding-standardsيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
| name | coding-standards |
| description | 检测代码异味、反模式和可读性问题。在实现功能、评审代码或重构时使用。 |
检测到以下任一模式时，暂停实现并记录：触发的模式、受影响的当前需求、最小的合规替代方案，以及恢复所需的验证。当替代方案消除该模式或有文档记录的需求证明保留该模式合理时，方可恢复。
持续排查，直到依据能够确定在保持系统正确性和可维护性的前提下，以最低总复杂度交付所需的用户、运维或维护者价值的方案。
对每个被激活的层面综合评估总复杂度：用户决策、设置、模式、概念、输出、持久状态和实现路径，以及它们各自在 UX、运行时、实现、测试、文档和维护方面的成本。只比较各可行方案之间存在差异的维度。当能以更低的总复杂度交付相同的已确认价值和验证结果时，优先选择复用或不引入新机制。
在出错时快速失败，防止在无效状态下继续处理。传播该失败，或返回带有原始诊断上下文的显式类型化错误。
关于详细实现方法（Result 类型、自定义错误类、分层错误处理等），请参考特定语言和框架的规则。
根据 Martin Fowler《重构》一书处理重复代码的方式：
| 重复次数 | 处理方式 | 理由 |
|---|---|---|
| 第 1 次 | 内联实现 | 无法预测未来的变化 |
| 第 2 次 | 考虑未来的整合 | 模式开始出现 |
| 第 3 次 | 提取公共实现 | 模式已确立 |
适合提取公共实现的情况
应保持分离的情况
提示中给出的路径是调查的起点。当有依据表明仓库中的其他文件实现了被接受的结果、是必需的依赖或调用路径、或必须变更以维持受本次工作影响的契约时，将其纳入范围。调用方、使用方、测试、配置和数据流是有用的依据，而非必须逐项核查的清单。
在采用某种模式、API 或依赖时，检查具有相同职责和当前契约的相关功能及仓库中的其他使用之处。在该职责范围内优先选择兼容的实现。出现频率有助于定位候选方案，但并不能使某个模式因此具有权威性；当多种方案并存时，通过其调用方、生命周期和兼容性来区分当前模式与遗留或无关的模式。
从清单文件、锁文件和兼容的使用方中解析外部依赖版本。仅当这些来源无法解决影响兼容性或架构的选择时才上报处理。
症状：修复一个错误导致产生新的错误 原因：未理解根本原因就进行表面修复 规避方法：修复前用五个为什么（5 Whys）找出根本原因
症状：过度使用 any 类型或 as 原因：想要规避类型错误的冲动 规避方法：应用“类型安全基础”中关于依据的判断标准。
症状：实现后出现大量 bug 原因：忽视 Red-Green-Refactor 流程 规避方法：以能够展示所需结果的失败测试开始行为变更
症状：引入新技术时频繁出现意外错误 原因：未事先调查，假设“照官方文档应该能行” 规避方法：
症状：重复实现、架构不一致、集成失败、采用过时模式 原因：实现前对现有代码理解不足；仅参考附近文件而未核实其代表性 规避方法：
将每个回答追溯到已观察到的依据，直至找到一个修正后能防止原始故障的原因。记录每个问题、依据以及最终的因果链；当下一个回答将只是推测时停止，并指出还需要哪些依据。
类型安全原则：类型收窄应以运行时检查或既有契约为依据。类型守卫保证的类型应与实际检查内容一致。
unknown，并验证使用方需要的属性。类型复杂度管理
基本方针
实现流程：理解现状 -> 渐进式修改 -> 行为验证 -> 最终确认
优先级：删除重复代码 > 拆分大函数 > 简化复杂条件分支 > 提升类型安全
完成标准：完成全部 3 个阶段
Grep -n "TargetClass\|TargetMethod" -o content
Grep -n "DependencyClass" -o content
Grep -n "targetData\|SetData\|UpdateData" -o content
必须：阅读所有发现的文件，并将必要部分纳入上下文：
结构化影响报告（必须）：
## 影响分析
### 直接影响：ClassA、ClassB（附理由）
### 间接影响：SystemX、ComponentY（附集成路径）
### 处理流程：输入 -> 处理1 -> 处理2 -> 输出
完成条件：在开始实现前，发现、理解和判定三个阶段都必须包含所需的依据。
检测到未使用的代码时，在任务完成前确认是否有当前需求和可达的调用路径会用到它。
对象：代码、文档、配置文件
推荐原则：以因预期原因而失败的测试开始行为变更
开发步骤：
可直接验证的情况：
推荐：在单元测试中对外部依赖进行 mock
单元测试边界：对外部连接使用确定性的替代品；在为该契约选定的集成测试或 E2E 测试中，实际调用真实的外部边界
修正测试：预期值错误、引用了不存在的功能、依赖于实现细节、仅为测试而存在的实现 修正实现：合理的规格、业务逻辑、重要的边缘情况 两种解读在现有需求下都说得通：返回未解决的行为决策 —— 说明两种候选行为、能够裁定哪一种正确的来源，以及在不做选择之前应停止的条件
通过可观测边界进行测试：公共 API、返回值、异常、外部调用和持久化状态。只能通过这些可观测边界间接触及私有方法、内部状态和算法细节。
references/security-checks.md