mcpField
F
feature-arch-gate

feature-arch-gate

github.com/pproenca测试与质量21869 次安装11 周前更新
代码仓库

关于 feature-arch-gate

feature-arch-gate 是一项技能，用于依据固定规则检查 React 功能式架构。它为团队提供合并前的独立通过或失败判定，但不会修改代码。

主要功能

  1. 01内置 33 条可判定架构规则
  2. 02单个盲审员审查流程
  3. 03逐条给出通过、失败或不适用
  4. 04失败即不通过，并列出具体修复项

适用场景

  1. 01合并前检查 React 架构 PR
  2. 02核验蓝图迁移是否完成
  3. 03审计完整 src/ 目录
  4. 04独立审查 Agent 生成的功能代码

安装

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

$npx skills add https://github.com/pproenca/dot-skills --skill feature-arch-gate

安装后在 Claude Code 中输入/feature-arch-gate确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

gotchas.md
metadata.json
assets/templates/
verdict.md
references/
_rule-evidence.md
_sections.md
bound-feature-scoped-routing.md
bound-interface-contracts.md
bound-minimize-shared-state.md
fcomp-colocate-styles.md
fcomp-composition-over-props.md
fcomp-error-boundaries.md
fquery-avoid-n-plus-one.md
fquery-colocate-with-feature.md
fquery-feature-scoped-keys.md
fquery-parallel-fetching.md
fquery-server-component-fetching.md
fquery-single-responsibility.md
fstate-feature-scoped-stores.md
fstate-server-state-separation.md
import-avoid-barrel-files.md
import-no-cross-feature.md
import-path-aliases.md
import-public-api.md
import-type-only.md
import-unidirectional-flow.md
name-descriptive-exports.md
name-feature-naming.md
name-file-conventions.md
reviewer-prompt.md
struct-app-layer.md

详细介绍

Feature-Arch Gate

强制检查 React 功能模块架构是否符合要求——这是一个通过/失败门禁：由单个盲审子 Agent 根据 feature-arch v1.1.0 的规则，以对抗性审查方式评判工作；只有每条规则都为 PASS 或 N/A 时，工作才算通过。此技能只给出判定，绝不修复工作。

此门禁自给自足：它所执行的 33 条可判定规则（源规则共 43 条）已作为 feature-arch v1.1.0 的快照存放在此技能的 references/ 目录中，因此审查不需要此目录之外的任何内容。references/_rule-evidence.md 记录了来源、判定每条规则所需的证据，以及排除的 10 条不可判定源规则。

适用场景

  • 对采用功能模块组织方式的 React 代码库进行 PR 或分支修改，需要在合并前给出架构符合性判定。
  • 声称已完成 FEATURE-ARCH-TARGET.md 蓝图中的某个迁移步骤，需要独立验证。
  • 要求审计完整的 src/ 树（“此代码库是否符合 feature-arch？”）。
  • 由 Agent 生成的功能模块工作需要经过一个不受生成该工作时对话影响的门禁。

请勿将此门禁用于设计或迁移架构——这是 feature-arch 技能的职责（它负责生成蓝图；此技能负责判定是否符合规则）。

审查流程

严格遵循以下步骤——每次审查都采用同样的方式，正是此门禁的价值所在。

  1. 确定目标。 明确待审查的内容（差异、一组文件或完整的 src/ 树），并记录引用和路径，确保审查针对明确且固定的目标。记录审查者需要的两个上下文信息：代码库是否使用 React Server Components，以及是否存在查询库（如 TanStack Query）——缺少这些时，有两条规则为 N/A。
  2. 加载规则。 阅读 references/_rule-evidence.md，并在此技能自己的 references/ 目录中找到其中列出的 33 个随附规则文件。如果任何列出的规则文件缺失或不可读，立即停止并报告错误——绝不可使用不完整的规则继续审查，也不可默默判定通过。
  3. 编写审查者提示词。 在 references/reviewer-prompt.md 中填写规则文件路径、审查目标，以及（若目标仓库中存在）其 docs/architecture/FEATURE-ARCH-TARGET.md 蓝图。编写好的提示词必须完全自足——审查者看不到任何对话历史，因此不得引用提示词之外的上下文。
  4. 派发一名盲审者。 启动一个 Task 子 Agent，其全部输入仅为编写好的提示词——不附带对话上下文或其他评论。
  5. 严格按失败关闭。 审查者的结构化输出即为判定——不设合并步骤。只有每条规则都为 PASS 或 N/A 时，总体判定才为 PASS；任意一条 FAIL 都会导致门禁失败。绝不取平均值、权衡严重程度或豁免规则——“轻微”的 FAIL 仍然是 FAIL。
  6. 给出判定。 填写 assets/templates/verdict.md。若为 FAIL，将审查者提出的“通过所缺条件”建议汇总到修复清单中，每项都要注明位置，并按源技能的类别优先级排序（struct → import → bound → fquery → fcomp → fstate → test → name）。最终结果为 FAIL 的每条规则都必须出现在修复清单中，并且要附上足够具体、可直接照做的修改方案——如果审查者的建议只是重述违规情况，则应根据规则中的 Correct 示例推导出修复方案后再填写。

如果同一目标未发生变化，但同一条规则在多次重新审查中得到不同判定，或者人工查看证据后推翻判定，则说明该规则存在可判定性缺陷——请在 gotchas.md 中记录并完善规则；不要推翻门禁判定。

评审结果格式

评审者针对每条规则返回：PASS | FAIL | N/A、证据（file:line 或引文；PASS 和 FAIL 都必须提供），以及每条 FAIL 对应的修复：应用后可使规则变为 PASS 的修改及其位置，不能只是重复描述违规内容。最终报告遵循 assets/templates/verdict.md。

规则类别

八个类别及其优先级顺序定义于 references/_sections.md；33 个引入的规则文件与其同在 references/ 中，references/_rule-evidence.md 列出了这些文件及判定各项规则所依据的证据，还列出了排除的 10 条源规则（附原因）。

参考文件

文件描述
references/reviewer-prompt.md供盲审评审者使用的独立提示词模板
assets/templates/verdict.md评审结果报告模板
references/_rule-evidence.md引入来源 + 各规则的判定证据 + 排除项
references/_sections.md类别定义和修复清单优先级顺序
references/<category>-*.md33 个引入的规则文件（struct/import/bound/fquery/fcomp/fstate/test/name）
metadata.json版本和来源参考

相关技能

  • feature-arch — 本门禁引入规则所依据的源精简技能；使用它（如果可用）来设计或迁移目标架构，并查看门禁排除的 10 条需作判断的规则。门禁在评审时本身无需依赖此技能。

评论

支持 Markdown