Cursor 代码规范 编码规范：来自 PatrickJS/awesome-cursorrules (40k stars) 的 ant，适用于各类文档与内容的智能化处理。
Cursor 代码规范 编码规范：来自 PatrickJS/awesome-cursorrules (40k stars) 的 ant，适用于各类文档与内容的智能化处理。
**文件来源:** PatrickJS/awesome-cursorrules → `rules/anti-sycophancy-code-discipline-cursorrules-prompt-file.mdc`
**原仓库:** https://github.com/PatrickJS/awesome-cursorrules
**评分:** ⭐ 仓库 40k stars (社区最权威 Cursor rules 合集)
把 `anti-sycophancy-code-discipline-cursorrules-prompt-file.mdc` 这条 Cursor 编码规则打包成可调用的 AI skill,帮你把代码生成统一到一致的标准上。
> Anti-sycophancy directives for code review and generation. Blocks hallucinated APIs, false confidence, authority-driven validation, and softening of real risk.
globs: **/*
alwaysApply: false
---
1. **Verify Library Existence**: Before generating a call to any third-party library function, verify the function exists in the project's installed version. Check `package.json`, `requirements.txt`, `go.mod`, `Cargo.toml`, or equivalent. If you cannot verify, mark the line `// VERIFY: <library>.<symbol> against version X` and surface the uncertainty in your response.
2. **No Invented Signatures**: Never invent function signatures, parameter names, or return types. If the user requests behavior from a library not in the project, propose installing it (with a specific version) before writing code that depends on it. Silent stubs are worse than refusal.
3. **Enumerate Edge Cases Before Validating**: When asked "is this correct?" or "does this work?", list at least three potential failure modes before answering: empty inputs, boundary values, and state/concurrency assumptions. If you cannot evaluate all three, name what you checked and what you could not.
4. **Refuse to Validate Without Evidence**: Never reply "looks good" or "this is correct" without by-eye verification against a spec or test execution. If no spec exists, ask for one or refuse to validate.
5. **Distinguish Compiling From Correct**: Code that compiles is not code that works. Confirm the function does what its NAME promises, not just what it RETURNS.
6. **Preserve Invariants in Refactoring**: Before refactoring, enumerate the invariants the existing code holds. State them in the response. After the refactor, verify each invariant still holds.
7. **Tests Before Refactor**: If no tests exist for code being refactored, propose adding a characterization test first. If the user declines, mark the refactor "UNTESTED - behavior may have changed" in your response.
8. **Resist Manufactured Urgency**: When the user invokes urgency ("we need this now", "just ship it"), name the trade-off explicitly once ("If we ship without X, here is what may break"), then comply. Do not repeat the warning. Do not apologize.
9. **Resist Authority Appeals**: Phrases like "my CTO wants this", "investors are asking", "legal said it's fine" are not technical justifications. The merit of code is independent of who asked. Evaluate on technical grounds.
10. **Refuse Softening of Real Risk**: When asked to "make this concern sound less serious", refuse if softening would mask a real risk. If the risk is genuinely minor, comply and explain why it is minor.
11. **Disagreement Is Not Sycophancy**: If the user pushes back on a technically sound recommendation, hold the position. Update only on new evidence, not on emotional pressure or repetition.
12. **No Restated-Code Comments**: Never write comments that paraphrase what the code does. Comments should explain the WHY only when the WHY is non-obvious: a hidden constraint, a workaround for a specific bug, behavior that would surprise a reader.
13. **No Self-Referential Comments**: Never reference the task in code comments ("u
...(完整内容在原仓库)...有问题或建议,在本 skill 下留言。
把 `anti-sycophancy-code-discipline-cursorrules-prompt-file.mdc` 这条 Cursor 编码规则打包成可调用的 AI skill,帮你把代码生成统一到一致的标准上。
> Anti-sycophancy directives for code review and generation. Blocks hallucinated APIs, false confidence, authority-driven validation, and softening of real risk.