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/mywand/cusrsor-do-it/adr-templategit clone --depth 1 https://github.com/mywand/cusrsor-do-itWhat 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 | $0.00000 | $0.04126 |
| Opus 5 | $0.00000 | $0.02063 |
| Sonnet 5 | $0.00000 | $0.00825 |
| Haiku 4.5 | $0.00000 | $0.00413 |
Grade A, and why
adr-template 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 3d 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.
How it starts
The opening of the file, as written. The whole thing — 475 lines — stays where its author put it; the contents beside it link to each section on GitHub.
最近更新: 2025-10-11
架构决策记录（ADR）模板
用于记录重要架构决策的标准化模板，确保决策过程透明、可追溯、可审查。
1. 什么是 ADR
1.1 定义
架构决策记录（Architecture Decision Record，ADR）是一种轻量级文档，用于记录在软件开发过程中做出的重要架构决策。
1.2 价值
- 透明性：决策过程和理由公开透明
- 可追溯：未来可以回顾为什么做出某个决策
- 知识传承：新成员可以快速了解系统演进历史
- 避免重复讨论：已讨论过的问题有明确记录
1.3 适用场景
以下情况建议创建 ADR：
- 技术栈选择（框架、数据库、中间件）
- 架构模式选择（微服务、分层、事件驱动）
- 重要的性能、安全或可扩展性决策
- 影响成本的技术决策
- 跨团队协作的技术约定
2. ADR 文件管理
2.1 文件命名
ADR-<序号>-<决策主题>.md
示例：
ADR-001-选择-PostgreSQL-作为主数据库.md
ADR-002-采用-事件驱动架构.md
ADR-003-使用-Redis-作为分布式缓存.md
命名规则：
- 序号：4位数字，从 0001 开始递增
- 主题：使用中文或英文，简洁明了
- 格式：Markdown (.md)
2.2 文件存放
项目根目录/
├── docs/
│ ├── adr/
│ │ ├── ADR-0001-选择-PostgreSQL-作为主数据库.md
│ │ ├── ADR-0002-采用-事件驱动架构.md
│ │ ├── ADR-0003-使用-Redis-作为分布式缓存.md
│ │ └── README.md # ADR 索引文件
2.3 状态管理
| 状态 | 说明 | 操作 |
|---|---|---|
| 提议中（Proposed） | 待讨论和决策 | 创建 ADR 草稿，征求意见 |
| 已接受（Accepted） | 决策已通过，开始实施 | 更新状态，开始实施 |
| 已废弃（Deprecated） | 不再推荐，但仍在使用 | 说明替代方案 |
| 已取代（Superseded） | 被新决策替代 | 引用新的 ADR |
| 已拒绝（Rejected） | 决策未通过 | 说明拒绝理由 |
3. ADR 模板
3.1 基础模板
# ADR-<序号>: <决策标题>
**状态**: 提议中 | 已接受 | 已废弃 | 已取代 | 已拒绝
**日期**: YYYY-MM-DD
**决策者**: 姓名或团队
**利益相关方**: 相关团队或人员
## 背景与问题（Context）
### 问题描述
清楚描述需要决策的问题或挑战。
**当前现状**：
- 现有方案的不足
- 面临的痛点和瓶颈
- 业务或技术背景
**触发因素**：
- 为什么现在需要做这个决策？
- 什么事件或需求促成了这次讨论？
### 约束条件
- 技术约束（如现有技术栈、团队技能）
- 时间约束（如上线时间要求）
- 预算约束（如许可证费用、资源成本）
- 合规要求（如安全标准、行业规范）
## 决策驱动因素（Decision Drivers）
按重要性排序的决策考虑因素：
1. **[因素名称]** - 描述为什么这个因素重要
2. **[因素名称]** - 说明影响程度
3. **[因素名称]** - ...
示例：
1. **性能要求** - 需要支持 10000 QPS，响应时间 < 100ms
2. **开发效率** - 团队需要在 2 个月内完成开发
3. **运维成本** - 控制在现有预算的 20% 以内
## 候选方案（Considered Options）
### 方案 A：[方案名称]
**描述**：
简要描述方案的核心思路。
**优点**：
- ✅ 优点 1
- ✅ 优点 2
- ✅ 优点 3
**缺点**：
- ❌ 缺点 1
- ❌ 缺点 2
- ❌ 缺点 3
**成本评估**：
- 开发成本：X 人月
- 运维成本：Y 元/月
- 学习成本：Z 天
### 方案 B：[方案名称]
**描述**：
...
**优点**：
- ✅ ...
**缺点**：
- ❌ ...
**成本评估**：
- ...
### 方案 C：[方案名称]
（可选，根据实际情况添加）
## 方案对比
| 维度 | 方案 A | 方案 B | 方案 C |
|------|--------|--------|--------|
| **性能** | 高 | 中 | 低 |
| **开发成本** | 低 | 中 | 高 |
| **运维成本** | 中 | 低 | 高 |
| **学习曲线** | 平缓 | 陡峭 | 平缓 |
| **社区支持** | 活跃 | 一般 | 活跃 |
| **可扩展性** | 好 | 一般 | 很好 |
| **风险** | 低 | 中 | 高 |
## 决策结果（Decision Outcome）
**选择方案**：方案 [A/B/C]
**核心理由**：
1. 理由 1 - 为什么这个方案最合适
2. 理由 2 - 如何平衡各种因素
3. 理由 3 - 权衡后的最优选择
**关键权衡**：
- 牺牲了 [某个方面]，获得了 [更重要的收益]
- 接受了 [某个风险]，因为 [风险可控且收益明显]
## 实施计划（Implementation）
### 实施阶段
| 阶段 | 任务 | 负责人 | 时间 |
|------|------|--------|------|
| 1. 技术验证 | POC 开发 | 张三 | Week 1-2 |
| 2. 基础搭建 | 环境准备 | 李四 | Week 3-4 |
| 3. 核心开发 | 功能实现 | 团队 | Week 5-8 |
| 4. 测试部署 | 测试上线 | 王五 | Week 9-10 |
### 验证标准
- [ ] POC 验证通过，满足性能要求
- [ ] 开发文档完成，团队培训完成
- [ ] 单元测试覆盖率 > 80%
- [ ] 集成测试通过，性能测试达标
## 影响分析（Consequences）
### 正面影响
- ✅ 提升性能，满足业务增长需求
- ✅ 降低维护成本
- ✅ 改善开发体验
### 负面影响
- ⚠️ 短期内增加学习成本
- ⚠️ 需要迁移现有数据
- ⚠️ 可能影响现有服务稳定性
### 风险与缓解
| 风险 | 影响 | 概率 | 缓解措施 |
|------|------|------|----------|
| 性能不达预期 | 高 | 中 | POC 验证，性能测试 |
| 团队学习成本高 | 中 | 高 | 提前培训，文档支持 |
| 兼容性问题 | 中 | 低 | 充分测试，灰度发布 |
## 后续行动（Follow-up）
### 短期（1-3个月）
- [ ] 完成技术方案设计
- [ ] 完成 POC 验证
- [ ] 完成团队培训
### 中期（3-6个月）
- [ ] 完成核心功能开发
- [ ] 完成性能测试和优化
- [ ] 完成灰度发布
### 长期（6个月以上）
- [ ] 全量上线
- [ ] 监控指标达标
- [ ] 文档和最佳实践沉淀
## 相关资源（References）
### 相关 ADR
- [ADR-XXX: 相关决策标题](./ADR-XXX-相关决策.md)
### 技术文档
- [官方文档](https://example.com/docs)
- [最佳实践](https://example.com/best-practices)
### 讨论记录
- [会议纪要](link-to-meeting-notes)
- [技术评审](link-to-tech-review)
---
**更新记录**：
- YYYY-MM-DD: 初始版本（提议中）
- YYYY-MM-DD: 更新状态为已接受
- YYYY-MM-DD: 补充实施进展
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.
- 3d ago First seen · 475 lines · 0 tokens per session scan A 7029d34b0f39
adr-template is a cursor rule published in the GitHub repository mywand/cusrsor-do-it (2 stars, last pushed 7mo ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 4,126 tokens. 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-31.
Other cursor rules, from other repositories
angular-20
This rule provides comprehensive best practices and coding standards for Angular development, focusing on modern TypeScript, standalone components, signals, and performance optimizations.
dev-standard
Apache Superset development standards and guidelines for Cursor IDE.
cli-error-handling
CLI command error handling patterns.
prefer-direct-imports-over-module-mocks
Prefer extracting a testable core over vi.mock / vi.resetModules when unit tests need to reach production logic entangled with config, env, or singletons.
control-plane-descriptors
Control plane descriptor and instance implementation patterns.
family-instance-domain-actions
Family instance domain action implementation patterns.