code-standard · diff
git:20261029.be105a9 to git:20261029.983cc27
36 added, 26 removed. Audit A to A.
---
name: code-standard
title: 代码规范
- summary: 每次写、改、审代码都遵循：去掉冗余、降低复杂度、提高可读性和可维护性，行为和接口保持不变。分阶段改、用现有测试验证，最后总结删了什么、简化了什么、还剩什么问题。
- description: Apply this code standard whenever writing, refactoring or reviewing code to reduce redundancy and complexity, improve readability and maintainability, and preserve behavior and interfaces.
+ summary: 首次运行先审查现有代码，报告主要问题和分阶段计划，经用户同意后再加入项目。之后每次代码变更都减少冗余和复杂度，保持行为与接口不变。
+ description: Review existing code and propose a staged adoption plan on first run, then reduce redundancy and complexity while preserving behavior and interfaces on every change. Use when first opening a project without this standard, or when writing, changing or reviewing code afterwards.
+ trigger: first-open
+ when: 首次在项目中启动会话、且项目里还没有这条规范时生效；之后写、改、审代码时按需生效
+ requires: none
---
# Code standard
- Goal: less redundant code, lower cognitive complexity, better readability, maintainability and execution efficiency.
+ ## When this applies
- The project's own conventions and linters take precedence where they differ.
+ On the first session started in a project that does not already have this standard, review the existing code against
+ these rules, report the most important problems and a staged plan, and ask whether to add this standard to the project
+ (for example, copy it to skills/code-standard/). Change no code and write no file until the user agrees.
+ After that first run, apply the rules whenever writing, changing or reviewing code; every code change follows them.
+ If the project has a code-standard skill in skills/, .claude/skills/ or .codex/skills/, or names it as a word in its
+ root AGENTS.md or CLAUDE.md, follow the project's standard instead. Its conventions and linters take precedence.
- ## Rules
+ ## What to do
- 1. **No redundant code.** Remove duplicated logic, pointless intermediate variables, needless wrapper functions and
- boilerplate.
- 2. **Simple control flow.** Avoid redundant if/else, deep nesting and tangled branches; use early returns and pattern
- matching where they make the code clearer.
- 3. **Concise code.** Shorten verbose expressions and functions, but never at the cost of readability.
- 4. **Clear structure.** Split functions and modules whose responsibility is unclear; extract only logic that is
- really reused; no over-abstraction.
- 5. **Readability.** Consistent naming and formatting; comment complex business logic (why, not what); delete
- meaningless comments. Match the surrounding code's style and comment density.
- 6. **No code smells.** Fix duplicated code, overlong functions, oversized modules, over-design and unnecessary
- dependencies.
+ 1. On the first run in a project, review the existing code against the rules below without changing code or writing files.
+ 2. Report the most important problems, with specific evidence, and a staged plan for addressing them.
+ 3. Ask whether to add this standard to the project, for example by copying it to skills/code-standard/. Change no code
+ and write no file until the user agrees; wait for that agreement before adoption or implementation.
+ 4. Once agreed, add the standard as requested. Afterwards apply these rules to every code change, while preserving
+ existing behavior, external interfaces and expected results.
+ 5. Make changes in stages and verify each stage with the existing tests. If work is split across workers, put the rules
+ in every brief; the lead reviews each returned diff and sends violations back with the specific lines.
- ## Principles
+ ## Rules
- - Keep existing behaviour, external interfaces and expected results unchanged.
- - Do not trade clarity for fewer lines.
- - Add no unnecessary abstractions, design patterns or new dependencies.
- - Prefer the language's idiomatic way of doing things.
- - Change in stages and verify each stage with the existing tests.
- - Finish with a summary: redundancy removed, complexity reduced, problems left.
+ - **No redundant code.** Remove duplicated logic, pointless intermediate variables, needless wrapper functions and boilerplate.
+ - **Simple control flow.** Avoid redundant if/else, deep nesting and tangled branches; use early returns and pattern matching where clearer.
+ - **Concise code.** Shorten verbose expressions and functions without trading clarity for fewer lines.
+ - **Clear structure.** Split functions and modules with unclear responsibilities; extract only truly reused logic, without over-abstraction.
+ - **Readability.** Use consistent naming and formatting. Comment complex business logic's reasons, remove meaningless comments, and match surrounding style and comment density.
+ - **No code smells.** Fix duplication, overlong functions, oversized modules, over-design and unnecessary dependencies.
+ - Preserve behavior, external interfaces and expected results. Prefer idiomatic language features; add no unnecessary abstractions, patterns or dependencies.
+ - On first run, do not change code or write any file until the user agrees to the proposed adoption and work.
+ - Apply the rules to every subsequent code change, verify each stage, and follow the project's own conventions where they differ.
- ## For the lead
+ ## Done when
- When work is split across workers (see the model-routing skill), include these rules in every worker brief. The lead
- reviews each returned diff against them before accepting it and sends violations back with the specific lines.
+ - On first run, the user has received the most important findings and staged plan, and has been asked whether to add the standard.
+ - Until agreement, no code has changed and no file has been written. Report that adoption is awaiting the user's decision.
+ - After agreement, each change follows the rules and the relevant existing tests pass.
+ - Finish with a summary of redundancy removed, complexity reduced, validation results and problems left.