module-design-guidelines

A set of rules for writing module design documents with clear structure, diagrams, and design principles such as keeping responsibilities separate.

In plain words
What is it for?
Use it when planning or reviewing modules, documenting their roles, flows, interfaces, data, quality requirements, security, and future changes.
Why use it?
It gives a team a shared way to describe software modules, making designs easier to review, compare, and maintain.

Cursor rule for Cursor

Install

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.

agentmods
npx agentmods add rules/mywand/cusrsor-do-it/module-design-guidelines
Clone the repo
git clone --depth 1 https://github.com/mywand/cusrsor-do-it

Made for: Cursor.

Per session 15 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 6,386 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00015 $0.06386
Opus 5 $0.00008 $0.03193
Sonnet 5 $0.00003 $0.01277
Haiku 4.5 $0.00002 $0.00639

Measured 2d ago against content hash 700dc76e7dce, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

module-design-guidelines 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 2d 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.

.cursor/rules/docs/module-design-guidelines.mdc · 523 lines

How it starts

The opening of the file, as written. The whole thing — 523 lines — stays where its author put it; the contents beside it link to each section on GitHub.

最近更新: 2025-10-28 最近审阅: 2025-10-28

Module Design Documentation Guidelines

核心理念:结构化表达 + 图示优先 + 可裁剪 + 设计原则驱动

文件编码:所有文档统一使用 UTF-8 编码,无 BOM

目标:通过清晰的设计原则和文档规范,确保模块设计质量和团队协作效率

📚 文档导航

本规范已拆分为多个文档,方便按需查阅:

文档 内容 适用场景
📖 当前文档 核心设计原则、文档概述、七要素框架 设计前必读
📘 七要素详细规范 第3-9章:背景、角色、模型、流程、状态、接口、数据 详细设计阶段
📙 质量保障指南 第10-15章:NFR、监控、安全、风险 质量评审阶段
📕 工程实践指南 第16-24章:技术债、评审、演进、快速指南 工程实践阶段

0. 核心设计原则

0.1 通用设计原则(SOLID + 经典原则)

SOLID 原则
原则 含义 模块设计应用 反模式示例
Single Responsibility 单一职责 一个模块只负责一个业务能力或领域概念 订单模块既管理订单又处理支付和库存
Open/Closed 开闭原则 通过扩展而非修改来应对变化(策略模式、插件机制) 每次新增支付方式都要修改核心支付流程
Liskov Substitution 里氏替换 子类/实现类可替换父类/接口而不影响系统正确性 继承关系破坏了父类的不变量约束
Interface Segregation 接口隔离 客户端不应依赖它不需要的接口 一个接口包含读、写、审计、统计所有方法
Dependency Inversion 依赖倒置 依赖抽象而非具体实现;高层模块不依赖低层模块 Service 直接依赖具体的 MySQLRepository
其他核心原则
原则 说明 模块设计检查点
DRY (Don't Repeat Yourself) 避免重复逻辑和知识 相同的业务规则是否在多处重复?
KISS (Keep It Simple, Stupid) 保持简单 是否过度设计?能用简单方案解决吗?
YAGNI (You Aren't Gonna Need It) 不要过度设计未来需求 是否实现了当前不需要的功能?
高内聚,低耦合 模块内部紧密相关,模块间松散依赖 模块之间的依赖关系是否清晰最小?
最少知识原则 (Law of Demeter) 只与直接朋友通信 是否存在跨多层的方法调用链?

0.2 领域驱动设计(DDD)原则

战略设计原则
graph TB
    subgraph "限界上下文 Bounded Context"
        A[订单上下文] --> |发布事件| B[支付上下文]
        B --> |发布事件| C[库存上下文]
        D[用户上下文] -.防腐层.-> A
    end
    style A fill:#e0f2fe
    style B fill:#dbeafe
    style C fill:#bfdbfe
    style D fill:#93c5fd
DDD 概念 定义 模块设计应用 关键检查
限界上下文 明确的业务边界,内部术语统一 每个模块对应一个限界上下文 是否存在术语冲突?边界是否清晰?
聚合根 保证数据一致性的边界 一个聚合内的修改必须原子性 聚合是否过大?是否跨聚合事务?
实体 Entity 有唯一标识的领域对象 订单、用户、商品 标识是否唯一?生命周期是否清晰?
值对象 Value Object 无标识,不可变的领域概念 金额、地址、时间范围 是否不可变?是否可替换?
领域事件 已发生的业务事实 订单已创建、支付已完成 事件命名是否过去时?是否幂等?
领域服务 跨实体的业务逻辑 订单结算、库存分配 是否无状态?是否业务语义清晰?
仓储 Repository 聚合的持久化抽象 UserRepository, OrderRepository 是否只操作聚合根?是否隐藏存储细节?
防腐层 ACL 保护本领域模型不被外部污染 适配外部API的数据模型 是否隔离了外部模型变化影响?

Read the full file on GitHub · 523 lines

Changes

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.

  1. 2d ago First seen · 523 lines · 15 tokens per session scan A 700dc76e7dce

Subscribe to this mod's changes

module-design-guidelines is a cursor rule published in the GitHub repository mywand/cusrsor-do-it (2 stars, last pushed 7mo ago), licensed Apache-2.0. It adds 15 tokens to every session and 6,386 once invoked, about $0.0001 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-31.