mcpField
I
inspect-role-naming

inspect-role-naming

github.com/venhdev测试与质量189 次安装今天更新
代码仓库

关于 inspect-role-naming

inspect-role-naming 是用于检查代码命名是否符合架构角色与职责的审计技能，面向审查目标代码的开发者。它区分局部重命名与需要结构重构的问题。

主要功能

  1. 01采用仓库命名规范或指定评审标准
  2. 02识别架构误导和边界架构泄漏
  3. 03将问题区分为 [RENAME] 或 [REFACTOR]
  4. 04将局部与结构性变更交由相应技能处理
  5. 05生成分类审计报告

适用场景

  1. 01检查模块中误导性的名称或角色
  2. 02判断命名问题是否需要结构抽取
  3. 03编制按优先级整理的命名审计报告

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/venhdev/zenforge --skill inspect-role-naming

安装后在 Claude Code 中输入/inspect-role-naming确认已加载。

附带文件references/role-naming-rubric.md

详细介绍

inspect-role-naming — 架构角色与命名审查工具

领域评估准则

1. 范围与容忍度界限（忽略哪些内容）
  • 仅关注关键风险：只关注危险的架构误表述、运行时冲突或边界架构泄漏。
  • 容忍无害代码：容忍小型本地辅助函数（少于 3 个方法）、内部变量命名简短、访问器中的无害指标／日志，以及外观上的风格差异；绝不强迫重构可正常工作的内聚代码。
  • 权威参考：严格依据 references/role-naming-rubric.md（或宿主仓库的权威命名规范，始终以后者为准）评估命名和角色是否一致。
2. 决策分流：[RENAME] 与 [REFACTOR]
  • [RENAME]（纯命名偏差）：底层职责单一且合理；仅标识符／后缀与 references/role-naming-rubric.md 不符。修复范围局部且风险低。
  • [REFACTOR]（角色失实／职责泄漏）：符号名称掩盖了多个不同职责，或作出了不实承诺（例如，repository 调用外部 API）。重命名之前必须先进行结构拆分。

规范输出约定

# Role & Naming Audit Dossier: <Target Scope>

## 1. Executive Summary
- **Target Inspected**: `<directory_or_file_path>`
- **Health Rating**: <PRISTINE | LOCALIZED_DRIFT | SYSTEMIC_DEBT>
- **Primary Bottleneck**: <Single-sentence summary of greatest role or boundary hazard>

## 2. Load-Bearing Defect Catalog
### [<CRITICAL | MAJOR>] [<RENAME | REFACTOR>] <Dimension>: `<Target Symbol>`
- **Offending Code**: [<file>#L<N>](file:///path/to/file#L<N>)
- **Violated Rubric**: [<spec_or_rubric>](references/role-naming-rubric.md#anchor)
- **Smell**: <Observable contract mismatch or dangerous collision>
- **Action**: <[RENAME] New Identifier OR [REFACTOR] Minimal Separation Path>

*(Emit 'No load-bearing role or naming defects observed' if clean)*
路由
  • 单文件内的局部符号重命名或轻微布尔逻辑清理 →（通过 /simplify-audit）。
  • 多文件符号迁移或结构性角色拆分 →（通过 /changeset）。

执行协议

  1. 接收并依据参考规范：

    • 接收目标路径（directory 或 files）。
    • 如果宿主仓库有命名标准，则以此为准（项目规范优先）；否则读取并应用 references/role-naming-rubric.md。

  2. 在当前轮次中务实审查：

    • 在当前轮次直接依据评估准则审查目标代码。
    • 遵守第 1 节的容忍度界限：严格忽略无害惯用写法、本地简短命名和正常工作的辅助函数。
    • 对每项发现，明确将修复分类为 [RENAME] 或 [REFACTOR]。

  3. 综合并触发轮次终止：

    • 将发现汇总到规范输出约定中。
    • 给出确定的健康评级（PRISTINE、LOCALIZED_DRIFT 或 SYSTEMIC_DEBT）。
    • 将完整审查报告呈现到对话流中，并立即结束当前轮次。

评论

支持 Markdown