Rust Development Agent Guidelines

1. Core Principles

• Analyze requirements, plan implementation steps, then write code.
• Prefer simple, direct, and maintainable solutions.
• Follow the existing project architecture and coding conventions.
• Modify only code directly related to the current task.
• Avoid overengineering, premature abstractions, and speculative features.
• Prioritize correctness, fast iteration, and minimal execution cost.

2. Default Behavior

Unless explicitly requested or strictly necessary:

• Do not write tests.
• Do not write comments.
• Do not write documentation.
• Do not add dependencies.
• Do not refactor unrelated code.
• Do not create unnecessary files.
• Do not introduce new abstractions or architectural changes.
• Do not run tests or expensive validation commands.

Prefer minimal changes over comprehensive improvements.

3. Development Workflow

Step 1: Requirement Analysis

• Understand the requested behavior and expected outcome.
• Inspect relevant existing code before making changes.
• Identify affected modules, dependencies, and boundaries.
• Consider relevant edge cases and compatibility constraints.
• Avoid exploring unrelated parts of the repository.

Step 2: Implementation Plan

• List concrete implementation steps.
• Identify files that need modification.
• Choose the simplest solution that satisfies the requirements.
• Keep the scope minimal and avoid unnecessary changes.

Step 3: Implementation

• Implement changes according to the plan.
• Keep code concise, readable, and maintainable.
• Follow Rust best practices and existing conventions.
• Avoid unnecessary abstractions, duplication, and complexity.
• Do not modify unrelated functionality.

Step 4: Validation

• Verify only the affected crate, module, or function.
• Prefer targeted compilation checks over broad validation.
• Check formatting when necessary.
• Do not add or run tests by default.
• Do not perform full-project validation automatically.
• Report any skipped or incomplete validation honestly.

4. Rust Coding Standards

• Prefer stable Rust.
• Prefer the standard library and existing dependencies.
• Use Result, Option, and ? appropriately.
• Avoid unnecessary unwrap, expect, clone, and unsafe.
• Maintain clear ownership, borrowing, and module boundaries.
• Prefer explicit, readable code over clever abstractions.
• Preserve existing public APIs unless changes are required.
• Prioritize correctness, readability, and maintainability.

5. Validation and Execution Policy

5.1 General Rules

• Validation must be proportional to the scope of changes.
• Prefer cargo check -p <crate> for affected crates.
• Prefer cargo fmt -p <crate> -- --check for targeted formatting checks.
• Run targeted tests only when necessary.
• Never run workspace-wide tests, integration suites, E2E suites, benchmarks, or release builds without explicit user approval.
• Never escalate from targeted validation to broader validation without permission.
• Do not perform additional validation merely because implementation is complete.

5.2 Execution Budget

• Maximum execution time per validation command: 60 seconds.
• Enforce the timeout through the execution environment when possible.
• Terminate validation commands that exceed the time budget.
• Never automatically retry timed-out commands.
• Never increase timeouts or expand validation scope without approval.
• Avoid redundant compilation, repeated checks, and parallel validation.
• If validation is expected to exceed the budget, skip it and report the limitation.
• Do not launch background validation processes to bypass execution limits.

5.3 Prohibited by Default

The following commands or equivalent operations require explicit user approval:

• cargo test --workspace
• cargo test --all
• cargo test --all-targets
• Unrestricted cargo test
• Unrestricted cargo nextest run
• Full integration or E2E test suites
• Workspace-wide compilation or validation
• cargo build --release
• cargo bench
• Any validation expected to exceed the execution budget

5.4 Validation Priority

Use the smallest applicable validation level:

1. Static inspection of changed code.
2. Targeted formatting check, if necessary.
3. Targeted cargo check, if necessary.
4. Targeted tests, only when justified.
5. Full validation, only with explicit user approval.

Stop once sufficient confidence is achieved. Do not automatically proceed to the next level.

6. Agent Execution Constraints

• Treat execution time, compute resources, and token usage as limited resources.
• Avoid unnecessary shell commands and repeated repository exploration.
• Reuse existing findings instead of repeatedly inspecting the same files.
• Do not run expensive commands merely to increase confidence.
• Do not interpret task completion as authorization for additional testing.
• If an action requires approval, request it instead of proceeding automatically.
• When validation fails, investigate the specific failure before executing another command.
• Never enter automatic test-fix-retest loops involving broad test suites.
• Prefer reporting unverified behavior over running unauthorized validation.
• Do not claim that unexecuted checks or tests passed.

7. Response Format

For each development task, respond in this order:

1. Requirement Analysis — Briefly explain the goal and affected scope.
2. Implementation Plan — List concrete steps and files to modify.
3. Implementation — Apply the planned changes.
4. Validation & Results — Summarize changes, executed checks, outcomes, and any unverified aspects.

Keep responses concise and focused. Avoid lengthy explanations, redundant summaries, and unnecessary documentation.