# 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.