mcpField
A
adversarial-tanstack

adversarial-tanstack

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

关于 adversarial-tanstack

adversarial-tanstack 是用于审查 TanStack Start 和 TypeScript 变更的合并门禁技能。它由单个盲审子 Agent 按规则给出严格的通过或失败结论，不负责修复代码或提供建议式反馈。

主要功能

  1. 01单个子 Agent 盲审
  2. 02失败即拦截的判定
  3. 03安全与客户端／服务端边界规则
  4. 04检查当前 TanStack Start API
  5. 05为失败规则列出具体修复项

适用场景

  1. 01合并前检查 TanStack Start 变更
  2. 02独立审查 Agent 编写的代码
  3. 03审计客户端／服务端边界安全

安装

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

$npx skills add https://github.com/pproenca/dot-skills --skill adversarial-tanstack

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

包含的文件

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

gotchas.md
metadata.json
assets/templates/
verdict.md
references/
_sections.md
boundary-client-env-prefix.md
boundary-env-server-context.md
boundary-loader-no-secrets.md
reviewer-prompt.md
sec-auth-at-handler.md
sec-csrf-with-custom-start.md
sec-no-account-enumeration.md
sec-private-cache-control.md
sec-session-cookie-flags.md
serverfn-current-api.md
serverfn-post-mutations.md
serverfn-static-imports.md
serverfn-validate-input.md
ssr-deterministic-render.md
ssr-per-request-instances.md
ssr-suspense-for-loader-data.md
tscfg-erasable-syntax.md
tscfg-no-verbatim-module-syntax.md
tscfg-strict-baseline.md
types-exhaustive-switch.md
types-justified-nonnull.md
types-no-escape-hatches.md
types-parse-external-data.md

详细介绍

对抗式 TanStack 门禁

用于 TanStack Start + TypeScript Web 应用变更的合并门禁——这是一个通过/不通过门禁：由单个盲审子 Agent 带着对抗性审查要求，根据本门禁的规则评判工作；只有每条规则均为 PASS 或 N/A 时，工作才算通过。本技能只给出裁定，绝不修复工作。

规则基于 @tanstack/react-start 1.168+（v1 RC，2026 年 7 月）以及 TypeScript 5.8–6.x 的语义。

适用时机

  • TanStack Start 功能、路由或服务端函数即将合并，需要客观的 PASS/FAIL，而非建议性反馈。
  • Agent（Claude、Codex）编写了 Start 应用代码，你希望进行独立检查，避免作者偏见导致审核流于形式。
  • 差异涉及客户端/服务端边界——环境变量、加载器、服务端函数、身份验证——此处错误的 PASS 会导致机密泄露或未经授权的数据访问。
  • 根据当前 v1 RC API 范围审查现有 Start 代码库文件集（过时的 .inputValidator()、已移除的 createServerFileRoute）。

不要用于非 Start React 应用（大多数 serverfn/boundary/ssr 规则会返回 N/A，门禁会退化为 TypeScript 检查），也不要在用户想要解释和重构而非裁定时使用。

审查流程

严格按以下步骤执行——本门禁的价值在于每次审查都采用相同流程。

  1. 确定目标。 明确要审查的内容（差异、文件集或 PR），并记录 ref/路径，确保审查针对明确且固定的目标。目标路径始终包含 tsconfig.json、src/router.tsx 和 src/start.ts（如果存在）——即使差异未涉及这些文件，若干规则也需要依据它们来判定。
  2. 加载规则。 阅读 references/_sections.md 和 references/ 中的每个规则文件（所有 boundary-*.md、serverfn-*.md、sec-*.md、ssr-*.md、types-*.md、tscfg-*.md 文件）。
  3. 编写审查者提示词。 根据规则和目标填写 references/reviewer-prompt.md。组合后的提示词必须完全自包含——审查者看不到任何对话历史，因此不得引用提示词以外的上下文。
  4. 派发一名盲审者。 启动单个 Task 子 Agent，其全部输入必须是组合后的提示词——不得提供对话上下文，也不得附带评论。
  5. 失败即关闭。 审查者的结构化输出就是裁定——不进行合并步骤。只有每条规则均为 PASS 或 N/A 时，总体裁定才为 PASS；任意一条 FAIL 都会导致门禁失败。绝不取平均、权衡严重程度或豁免规则——“轻微”的 FAIL 仍然是 FAIL。
  6. 生成裁定。 填写 assets/templates/verdict.md。若为 FAIL，将审查者的“通过所需的缺失项”建议汇总到修复列表中，每项注明位置，并按类别重要性排序。每条最终结果为 FAIL 的规则都必须出现在修复列表中，并给出足够具体、可直接执行的变更——如果审查者的建议只是重述违规内容，生成裁定前应根据规则中的 Correct 示例推导修复方案。

如果同一条规则在针对未变更目标的多次重新审查中反复改变裁定，或者人工阅读证据后推翻裁定，这说明规则存在可判定性缺陷——应在 gotchas.md 中记录并细化规则；不得推翻门禁。

裁定格式

审查者应针对每条规则返回：PASS | FAIL | N/A、证据（file:line 或引文——PASS 和 FAIL 都必须提供证据），以及每条 FAIL 对应的修复方案，该方案应用后应能使规则转为 PASS——写明具体变更及其位置，绝不能只重述违规内容。最终报告遵循 assets/templates/verdict.md。

规则类别

#类别前缀涵盖内容
1客户端／服务端边界boundary-仅在服务端上下文中使用环境变量、加载器同构性、公共前缀规范
2服务端函数与路由serverfn-输入验证器、变更操作使用 POST、当前 v1 RC API、静态导入
3身份验证与安全sec-在处理程序中进行身份验证、使用自定义启动配置处理 CSRF、缓存隐私、Cookie 标志、防枚举
4SSR 与数据加载ssr-为每个请求创建路由器／QueryClient、对加载器数据使用 useSuspenseQuery、确定性渲染
5边界处的类型安全types-使用架构解析外部数据、穷尽式 switch、逃生口审计、非空断言
6编译器配置tscfg-strict + noUncheckedIndexedAccess、erasableSyntaxOnly、关闭 verbatimModuleSyntax（Start 专用）

参考文件

文件描述
references/reviewer-prompt.md供盲审员使用的自包含提示词模板
assets/templates/verdict.md评审报告模板
references/_sections.md类别定义与排序
metadata.json版本与来源引用

评论

支持 Markdown