Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/tashangkd/tashan-cursor-skills/full-node-auditgit clone --depth 1 https://github.com/TashanGKD/tashan-cursor-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/tashangkd/tashan-cursor-skills/full-node-audit)<a href="https://agentmods.dev/rules/tashangkd/tashan-cursor-skills/full-node-audit"><img src="https://agentmods.dev/badge/rules/tashangkd/tashan-cursor-skills/full-node-audit.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00073 | $0.02600 |
| Opus 5 | $0.00036 | $0.01300 |
| Sonnet 5 | $0.00015 | $0.00520 |
| Haiku 4.5 | $0.00007 | $0.00260 |
Grade A, and why
full-node-audit scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- full-node-audit — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 172 lines — stays where its author put it; the contents beside it link to each section on GitHub.
全节点审核规则（full-node-audit）
认知根：F-022（全节点审核机制原则）/ L1.5候选 P10? 关系类型：extends（是 P1「验证优先于感受」在系统架构层的强制实施版本） 与其他 Rule 的关系：auto-experience-hook 关注「执行后沉淀」；本 Rule 关注「输出前审核」
核心原则
任何生产节点，在最终输出给用户或写入文件之前，必须内置至少一次挑战者反思。
创作者（无论是 AI 还是人）在单一视角下有系统性盲区——自以为正确的设计，对使用者/读者/系统可能有明显问题。挑战者视角是发现这类盲区的最低成本机制。
适用范围：什么是「生产节点」
以下类型的输出步骤属于生产节点，适用本 Rule：
| 生产节点类型 | 示例 |
|---|---|
| 内容生产 | 生成文章草稿、段落、标题 |
| 产品设计 | 输出产品定义、功能设计、用户流 |
| 技术设计 | 输出技术架构、API规范、数据模型 |
| 代码生产 | 完成一个功能模块、接口、组件 |
| Skill/Rule 设计 | 完成 Skill 初稿、Rule 内容 |
| 认知更新 | 向认知结构写入新内容（碎片/原则/整合） |
| 决策输出 | 给出方案建议、做出选择 |
不适用（不需要挑战者反思的步骤）：
- 纯读取/信息整理步骤（没有新输出）
- 已经是审核者角色的步骤本身（如关卡A/B/C）
- 日志记录、索引更新等机械性写入
最低挑战者反思要求
每个生产节点完成后，在输出/提交前，执行以下最低程度的挑战者反思：
挑战者检查（最多3条，针对当前输出最可能的盲区）：
1. 使用者/读者视角：这个输出对最终使用它的人来说，有什么不清楚或有误导的地方？
2. 反例视角：有没有一个具体情况，这个输出会失效或造成问题？
3. 遗漏视角：这里省略了什么本应包含但被我无意识跳过的内容？
要求：
- 3 条检查都需要给出具体答案（不能全部回答"无"）
- 如果发现问题 → 修改后再输出
- 如果3条均无重大问题 → 可以输出，但必须有至少1条"尚可接受的小问题"（如果全部"完美"则说明挑战视角不够认真）
各节点类型的挑战者视角重点
不同类型的生产节点，挑战的重点不同：
| 节点类型 | 挑战重点1 | 挑战重点2 | 挑战重点3 |
|---|---|---|---|
| 内容生产 | 读者第一次读到这里会理解错什么？ | 是否有「AI腔」或空话？ | 标题/结论是否能独立成立？ |
| 产品设计 | 挑剔用户会在哪一步卡住或放弃？ | 有没有假设用户知道某个前提？ | 边界情况（用户做了意外操作）怎么处理？ |
| 技术设计 | 这个架构在最高负载/极端输入时会在哪里崩溃？ | 有没有单点故障？ | 6个月后新开发者能从文档独立理解吗？ |
| 代码生产 | 这个函数在输入为null/空/超大时会怎样？ | 有没有隐藏的副作用？ | 有没有已有代码可以复用而未复用？ |
| Skill/Rule设计 | AI执行者读完会有哪3个歧义点？ | 这个规则和已有规则有没有冲突？ | 触发条件是否过宽（会误触）或过窄（会漏触）？ |
| 认知更新 | 这个内容和已有认知结构的哪里可能矛盾？ | 置信度标注是否诚实（是推断还是确认）？ | 有没有应该同步更新但没有更新的关联文档？ |
与各关卡的关系
本 Rule 的挑战者反思是节点内的小闭环，不替代以下大闭环审核机制：
| 审核机制 | 层级 | 关系 |
|---|---|---|
| 本 Rule（挑战者反思） | 节点内，自我审核 | 生产者自己从挑战者视角快速检查 |
| 关卡A（用户模拟） | 产品定义→代码之间 | 独立审核者，全面模拟用户路径 |
| 关卡B（系统破坏） | 架构→代码之间 | 独立审核者，从破坏者视角找漏洞 |
| 关卡C（测试工程师） | 代码写完→上线之前 | 独立审核者，按验收标准全面测试 |
层级关系：本 Rule（节点内 ⊂ 小闭环）→ 关卡A/B/C（大闭环）→ 元验证（全系统闭环）
与全量搜索原则的关系（F-021）
F-021 要求全量搜索，F-022 要求全节点审核——两者共同构成大闭环：
产品设计阶段：
生产节点（产品定义输出）
→ [本 Rule] 挑战者反思（节点内）
→ 关卡A（全路径用户模拟 × 全量搜索）← F-021 在这里作用
技术架构阶段：
生产节点（架构输出）
→ [本 Rule] 挑战者反思（节点内）
→ 关卡B（全覆盖破坏性测试 × 全分支）← F-021 在这里作用
代码阶段：
生产节点（每个功能模块输出）
→ [本 Rule] 挑战者反思（节点内）
→ 关卡C（全覆盖功能验证 × 全路径）← F-021 在这里作用
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 172 lines · 73 tokens per session scan A 12e8a4c3c268
full-node-audit is a cursor rule published in the GitHub repository TashanGKD/tashan-cursor-skills (20 stars, last pushed 5mo ago), licensed MIT. It adds 73 tokens to every session and 2,600 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
10-feature-development
Feature implementation workflow and engineering mindset.
11-template-conventions
Reusable building blocks shipped with this template - use them instead of writing new ones.
12-new-project
Workflow for starting a new app from this template - rebranding, identity, cleanup and first feature.
13-updating-project
Workflow for updating an existing project - dependency and SDK upgrades, migrations, refactors, bug fixes.
01-tech-stack
Android tech stack and project standards.
03-ui
UI, layout, theming and localization standards.