docs(guidelines): add Rust Development Agent Guidelines
ZhenYi committed
Modified AGENTS.md AGENTS.md +143 −5 View AGENTS.md
@@ -1,6 +1,144 @@
1非必要:
2- 不写测试
3- 不写注释
4- 不写文档
1# Rust Development Agent Guidelines
2
3## 1. Core Principles
4
5- Analyze requirements, plan implementation steps, then write code.
6- Prefer simple, direct, and maintainable solutions.
7- Follow the existing project architecture and coding conventions.
8- Modify only code directly related to the current task.
9- Avoid overengineering, premature abstractions, and speculative features.
10- Prioritize correctness, fast iteration, and minimal execution cost.
11
12## 2. Default Behavior
13
14Unless explicitly requested or strictly necessary:
15
16- Do not write tests.
17- Do not write comments.
18- Do not write documentation.
19- Do not add dependencies.
20- Do not refactor unrelated code.
21- Do not create unnecessary files.
22- Do not introduce new abstractions or architectural changes.
23- Do not run tests or expensive validation commands.
24
25Prefer minimal changes over comprehensive improvements.
26
27## 3. Development Workflow
28
29### Step 1: Requirement Analysis
30
31- Understand the requested behavior and expected outcome.
32- Inspect relevant existing code before making changes.
33- Identify affected modules, dependencies, and boundaries.
34- Consider relevant edge cases and compatibility constraints.
35- Avoid exploring unrelated parts of the repository.
36
37### Step 2: Implementation Plan
38
39- List concrete implementation steps.
40- Identify files that need modification.
41- Choose the simplest solution that satisfies the requirements.
42- Keep the scope minimal and avoid unnecessary changes.
43
44### Step 3: Implementation
45
46- Implement changes according to the plan.
47- Keep code concise, readable, and maintainable.
48- Follow Rust best practices and existing conventions.
49- Avoid unnecessary abstractions, duplication, and complexity.
50- Do not modify unrelated functionality.
51
52### Step 4: Validation
53
54- Verify only the affected crate, module, or function.
55- Prefer targeted compilation checks over broad validation.
56- Check formatting when necessary.
57- Do not add or run tests by default.
58- Do not perform full-project validation automatically.
59- Report any skipped or incomplete validation honestly.
60
61## 4. Rust Coding Standards
62
63- Prefer stable Rust.
64- Prefer the standard library and existing dependencies.
65- Use `Result`, `Option`, and `?` appropriately.
66- Avoid unnecessary `unwrap`, `expect`, `clone`, and `unsafe`.
67- Maintain clear ownership, borrowing, and module boundaries.
68- Prefer explicit, readable code over clever abstractions.
69- Preserve existing public APIs unless changes are required.
70- Prioritize correctness, readability, and maintainability.
71
72## 5. Validation and Execution Policy
73
74### 5.1 General Rules
75
76- Validation must be proportional to the scope of changes.
77- Prefer `cargo check -p <crate>` for affected crates.
78- Prefer `cargo fmt -p <crate> -- --check` for targeted formatting checks.
79- Run targeted tests only when necessary.
80- Never run workspace-wide tests, integration suites, E2E suites, benchmarks, or release builds without explicit user approval.
81- Never escalate from targeted validation to broader validation without permission.
82- Do not perform additional validation merely because implementation is complete.
83
84### 5.2 Execution Budget
85
86- Maximum execution time per validation command: 60 seconds.
87- Enforce the timeout through the execution environment when possible.
88- Terminate validation commands that exceed the time budget.
89- Never automatically retry timed-out commands.
90- Never increase timeouts or expand validation scope without approval.
91- Avoid redundant compilation, repeated checks, and parallel validation.
92- If validation is expected to exceed the budget, skip it and report the limitation.
93- Do not launch background validation processes to bypass execution limits.
94
95### 5.3 Prohibited by Default
96
97The following commands or equivalent operations require explicit user approval:
98
99- `cargo test --workspace`
100- `cargo test --all`
101- `cargo test --all-targets`
102- Unrestricted `cargo test`
103- Unrestricted `cargo nextest run`
104- Full integration or E2E test suites
105- Workspace-wide compilation or validation
106- `cargo build --release`
107- `cargo bench`
108- Any validation expected to exceed the execution budget
109
110### 5.4 Validation Priority
111
112Use the smallest applicable validation level:
5113
6当用户提出需求的时候，先分析需求，列出实现需求的步骤，再根据步骤生成代码。
No newline at end of file
1141. Static inspection of changed code.
1152. Targeted formatting check, if necessary.
1163. Targeted `cargo check`, if necessary.
1174. Targeted tests, only when justified.
1185. Full validation, only with explicit user approval.
119
120Stop once sufficient confidence is achieved. Do not automatically proceed to the next level.
121
122## 6. Agent Execution Constraints
123
124- Treat execution time, compute resources, and token usage as limited resources.
125- Avoid unnecessary shell commands and repeated repository exploration.
126- Reuse existing findings instead of repeatedly inspecting the same files.
127- Do not run expensive commands merely to increase confidence.
128- Do not interpret task completion as authorization for additional testing.
129- If an action requires approval, request it instead of proceeding automatically.
130- When validation fails, investigate the specific failure before executing another command.
131- Never enter automatic test-fix-retest loops involving broad test suites.
132- Prefer reporting unverified behavior over running unauthorized validation.
133- Do not claim that unexecuted checks or tests passed.
134
135## 7. Response Format
136
137For each development task, respond in this order:
138
1391. **Requirement Analysis** — Briefly explain the goal and affected scope.
1402. **Implementation Plan** — List concrete steps and files to modify.
1413. **Implementation** — Apply the planned changes.
1424. **Validation & Results** — Summarize changes, executed checks, outcomes, and any unverified aspects.
143
144Keep responses concise and focused. Avoid lengthy explanations, redundant summaries, and unnecessary documentation.
No newline at end of file
Added CLAUDE.md CLAUDE.md +144 −0 View CLAUDE.md
@@ -0,0 +1,144 @@
1# Rust Development Agent Guidelines
2
3## 1. Core Principles
4
5- Analyze requirements, plan implementation steps, then write code.
6- Prefer simple, direct, and maintainable solutions.
7- Follow the existing project architecture and coding conventions.
8- Modify only code directly related to the current task.
9- Avoid overengineering, premature abstractions, and speculative features.
10- Prioritize correctness, fast iteration, and minimal execution cost.
11
12## 2. Default Behavior
13
14Unless explicitly requested or strictly necessary:
15
16- Do not write tests.
17- Do not write comments.
18- Do not write documentation.
19- Do not add dependencies.
20- Do not refactor unrelated code.
21- Do not create unnecessary files.
22- Do not introduce new abstractions or architectural changes.
23- Do not run tests or expensive validation commands.
24
25Prefer minimal changes over comprehensive improvements.
26
27## 3. Development Workflow
28
29### Step 1: Requirement Analysis
30
31- Understand the requested behavior and expected outcome.
32- Inspect relevant existing code before making changes.
33- Identify affected modules, dependencies, and boundaries.
34- Consider relevant edge cases and compatibility constraints.
35- Avoid exploring unrelated parts of the repository.
36
37### Step 2: Implementation Plan
38
39- List concrete implementation steps.
40- Identify files that need modification.
41- Choose the simplest solution that satisfies the requirements.
42- Keep the scope minimal and avoid unnecessary changes.
43
44### Step 3: Implementation
45
46- Implement changes according to the plan.
47- Keep code concise, readable, and maintainable.
48- Follow Rust best practices and existing conventions.
49- Avoid unnecessary abstractions, duplication, and complexity.
50- Do not modify unrelated functionality.
51
52### Step 4: Validation
53
54- Verify only the affected crate, module, or function.
55- Prefer targeted compilation checks over broad validation.
56- Check formatting when necessary.
57- Do not add or run tests by default.
58- Do not perform full-project validation automatically.
59- Report any skipped or incomplete validation honestly.
60
61## 4. Rust Coding Standards
62
63- Prefer stable Rust.
64- Prefer the standard library and existing dependencies.
65- Use `Result`, `Option`, and `?` appropriately.
66- Avoid unnecessary `unwrap`, `expect`, `clone`, and `unsafe`.
67- Maintain clear ownership, borrowing, and module boundaries.
68- Prefer explicit, readable code over clever abstractions.
69- Preserve existing public APIs unless changes are required.
70- Prioritize correctness, readability, and maintainability.
71
72## 5. Validation and Execution Policy
73
74### 5.1 General Rules
75
76- Validation must be proportional to the scope of changes.
77- Prefer `cargo check -p <crate>` for affected crates.
78- Prefer `cargo fmt -p <crate> -- --check` for targeted formatting checks.
79- Run targeted tests only when necessary.
80- Never run workspace-wide tests, integration suites, E2E suites, benchmarks, or release builds without explicit user approval.
81- Never escalate from targeted validation to broader validation without permission.
82- Do not perform additional validation merely because implementation is complete.
83
84### 5.2 Execution Budget
85
86- Maximum execution time per validation command: 60 seconds.
87- Enforce the timeout through the execution environment when possible.
88- Terminate validation commands that exceed the time budget.
89- Never automatically retry timed-out commands.
90- Never increase timeouts or expand validation scope without approval.
91- Avoid redundant compilation, repeated checks, and parallel validation.
92- If validation is expected to exceed the budget, skip it and report the limitation.
93- Do not launch background validation processes to bypass execution limits.
94
95### 5.3 Prohibited by Default
96
97The following commands or equivalent operations require explicit user approval:
98
99- `cargo test --workspace`
100- `cargo test --all`
101- `cargo test --all-targets`
102- Unrestricted `cargo test`
103- Unrestricted `cargo nextest run`
104- Full integration or E2E test suites
105- Workspace-wide compilation or validation
106- `cargo build --release`
107- `cargo bench`
108- Any validation expected to exceed the execution budget
109
110### 5.4 Validation Priority
111
112Use the smallest applicable validation level:
113
1141. Static inspection of changed code.
1152. Targeted formatting check, if necessary.
1163. Targeted `cargo check`, if necessary.
1174. Targeted tests, only when justified.
1185. Full validation, only with explicit user approval.
119
120Stop once sufficient confidence is achieved. Do not automatically proceed to the next level.
121
122## 6. Agent Execution Constraints
123
124- Treat execution time, compute resources, and token usage as limited resources.
125- Avoid unnecessary shell commands and repeated repository exploration.
126- Reuse existing findings instead of repeatedly inspecting the same files.
127- Do not run expensive commands merely to increase confidence.
128- Do not interpret task completion as authorization for additional testing.
129- If an action requires approval, request it instead of proceeding automatically.
130- When validation fails, investigate the specific failure before executing another command.
131- Never enter automatic test-fix-retest loops involving broad test suites.
132- Prefer reporting unverified behavior over running unauthorized validation.
133- Do not claim that unexecuted checks or tests passed.
134
135## 7. Response Format
136
137For each development task, respond in this order:
138
1391. **Requirement Analysis** — Briefly explain the goal and affected scope.
1402. **Implementation Plan** — List concrete steps and files to modify.
1413. **Implementation** — Apply the planned changes.
1424. **Validation & Results** — Summarize changes, executed checks, outcomes, and any unverified aspects.
143
144Keep responses concise and focused. Avoid lengthy explanations, redundant summaries, and unnecessary documentation.
No newline at end of file