mcpField
P
perimeter

perimeter

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

关于 perimeter

perimeter 是用于审查代码库或子系统架构边界的技能。它依据既有规范组件、实际绕过行为和具体风险形成发现，并将合格边界问题转交实施、测试或人工讨论。

主要功能

  1. 01查找绕过内部封装的原始 API 调用
  2. 02追踪架构层之间的导入关系
  3. 03审查文件系统与资源处理
  4. 04依据证据和风险判定约束
  5. 05将发现转入变更集、测试或讨论

适用场景

  1. 01审查子系统的边界违规
  2. 02查找绕过规范客户端的直接调用
  3. 03评估实际绕过行为带来的架构风险
  4. 04准备有证据支持的边界声明

安装

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

$npx skills add https://github.com/venhdev/skills --skill perimeter

安装后在 Claude Code 中输入/perimeter确认已加载。

附带文件references/fitness-functions.md

详细介绍

perimeter — 架构边界与绕过检测引擎

领域评估准则

1. 边界审计维度
  • 受认可的基础机制与原始绕过（横向）：识别管理 I/O、网络客户端、资源或生命周期的内部封装器；标记绕过这些封装器、直接调用原始运行时 API 的调用点。
  • 层级与依赖方向性（纵向）：追踪跨架构层（Domain、App、Infra、UI）的导入关系图；标记方向反转或跨越边界的导入。
  • 资源与沙箱卫生：审计存储路径、并发池和内存缓冲区；标记未受约束的文件系统访问或未限制的资源使用。
2. 承重约束资格门槛

严格依据以下 3 个条件评估候选约束：

  1. 现有受认可的基础机制：代码库定义了用于处理该边界的内部封装器、基类或规范路径。
  2. 实证绕过证据：至少有一个活跃调用点违反该边界，直接调用原始 API。
  3. 可量化的失败风险：绕过会导致架构漂移、资源泄漏、内存耗尽或安全暴露。
  • 负面边界：禁止针对外观样式、简单工具（Math.*、集合类）或缺乏活跃基础机制的推测性规则声明约束。

规范输出约定

# Perimeter Report: <Target Subsystem / Scope>

## 1. Executive Verdict
- **Target Inspected**: `<directory_or_package>`
- **Verdict**: <HARDENED | PARTIAL | UNPROTECTED> (<N> active boundaries)
- **Primary Risk**: <Single-sentence technical judgment on highest boundary exposure>

## 2. Qualified Boundary Declarations
*(If HARDENED: 'All architectural boundaries are enforced by active test suites; zero raw bypasses detected.')*

### Boundary: <Constraint Name, e.g., Direct Network Client Bypass>
- **Offending Evidence**: [<file>#L<N>](file:///path/to/file#L<N>) ── <Bypass snippet or call site>
- **Failure Risk**: <Concrete risk: memory leak / auth bypass / architectural drift>
- **Rule**: Required: `<Sanctioned Primitive>` ── Banned: `<Forbidden Raw API>`
- **Enforcement**: Tier: `<Arch Unit Test | AST Linter | Script Guard>` | Whitelist: `<Exempt files | 'None'>`

## 3. Disqualified Invariants (Pruned) *(omit if no candidate patterns pruned)*
- **[PRUNED] <Candidate Pattern>**: <Reason for rejection, e.g., No existing codebase primitive / Trivial style issue>
路由
  • 符合资格的边界需要具体的实现计划 →（通过 /changeset）。
  • 边界测试有证据支持的变更集和获准的执行范围 →（通过 /forge）。
  • 边界归属、白名单例外或架构权衡需要人工审议 →（通过 /clarify）。

执行协议

阶段 1：宏观锚点定位
  1. 摄取目标目录或子系统。
  2. 使用符号和文件搜索工具，探查高层架构锚点（内部封装器、受认可的客户端、解析器、基础接口）。
  3. 建立有依据的锚点上下文，为后续检查提供基础。
阶段 2：自适应规模边界审计
  1. 评估目标范围的规模：
    • 单轮内执行（少于 10 个文件或局部模块）：在当前轮次中，直接依据已发现的锚点审计调用点。
    • 子 Agent 分派（大型代码库或跨层范围）：启动 1–3 个 research 子 Agent（角色：Perimeter Reviewer (<Slice>)）。为每个子 Agent 提供：
      • 目标切片目录。
      • 阶段 1 中发现的架构锚点。
      • 承重约束资格门槛以及 references/fitness-functions.md 的路径。
      • 规范子报告约定，要求提供违规代码位置（file:///...#L<N>）。
阶段 3：规则编纂与轮次停止门槛（汇总）
  1. 将发现结果整理为规范输出约定；将缺乏依据的规则移至第 3 节（已剔除；若无内容则省略第 3 节）。
  2. 如果边界归属或白名单豁免仍存在未解决的权衡：停止并进行审议（通过 /clarify）。
  3. 将报告输出到对话流中，并立即停止当前轮次。

评论

支持 Markdown