code-standard · diff
git:20261029.983cc27 to git:20261029.f313e5b
3 added, 3 removed. Audit A to A.
---
name: code-standard
- title: 代码规范
- 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.
+ description: Use on the first session Agentrix starts in a project without its own code standard, before its first task, and afterwards whenever writing, changing or reviewing code; yield to the project's own standard, review existing code and propose a staged adoption plan on first run, then reduce redundancy and complexity while preserving behavior and interfaces.
trigger: first-open
when: 首次在项目中启动会话、且项目里还没有这条规范时生效；之后写、改、审代码时按需生效
requires: none
+ title: 代码规范
+ summary: 首次运行先审查现有代码，报告主要问题和分阶段计划，经用户同意后再加入项目。之后每次代码变更都减少冗余和复杂度，保持行为与接口不变。
---
# Code standard
## When this applies
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.
## What to do
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.
## Rules
- **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.
## Done when
- 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.