StemCode for Rust Developers: AI Coding with Cargo, rust-analyzer, and explicit ownership.

Give StemCode durable repository instructions before asking it to edit.

Add an AGENTS.md file at the repository root for persistent project instructions. StemCode loads AGENTS.md or .agent/AGENTS.md from the workspace into the model context, so this is the right place for architecture boundaries, generated-file rules, coding conventions, validation expectations, and manual setup notes that should apply across sessions.

# Rust Project Instructions

This is a Rust project.

Important source and configuration paths:
- Cargo.toml
- Cargo.lock
- crates/
- src/
- tests/
- benches/
- build.rs

Generated or disposable paths — do not modify:
- target/
- dist/
- coverage/
- temporary generated output

Follow these rules:
- Respect existing crate and module boundaries.
- Do not edit target or generated build output.
- Prefer existing error types and conversion patterns.
- Avoid unnecessary clone, Arc, Mutex, and boxed trait objects.
- Do not block the async runtime with synchronous I/O or heavy CPU work.
- Run fmt, check, Clippy, and relevant tests before finishing.

Validation:
- cargo fmt --check
- cargo check --workspace
- cargo clippy --workspace --all-targets
- cargo test --workspace

Commit the file with the project so the same instructions are reviewable and shared by everyone using StemCode in the repository.

Use repository-aware AI without replacing the tools your stack already needs.

StemCode works best when it can understand the repository around a task, inspect related files, use code intelligence where available, run the project's normal validation commands, and review the final diff before you accept a change.

Install StemCode and open the project root.

Start StemCode at the Cargo package or workspace root so manifests, lockfiles, crates, features, source, tests, build scripts, and Git history are available in one workspace.

cd your-project
stemcode
/init

Keep StemCode at the repository root so project instructions, source, configuration, tests, and Git history are visible from one workspace.

Keep crate boundaries, features, source, and tests visible while excluding Cargo build output.

Rust repositories often encode architecture through crates, features, traits, and ownership boundaries. Those files are valuable context; target output and generated artifacts generally are not.

Cargo.toml
Cargo.lock
crates/
src/
tests/
benches/
build.rs

target/
dist/
coverage/
temporary generated output

Add generated paths to Git ignore rules or .stemcode/.stemcodeignore so repository search stays focused.

Use rust-analyzer to understand traits, types, references, and diagnostics.

rust-analyzer is particularly valuable in Rust because behavior can be distributed across traits, implementations, generics, feature flags, and macro-heavy APIs.

/lsp refresh
/lsp

Make ownership, error, async, and crate boundaries explicit before editing.

Ask StemCode to explain lifetimes and ownership only where they matter to the task, then preserve the project’s existing patterns for errors, async execution, traits, and dependency injection rather than adding abstraction for its own sake.

Use Cargo’s formatter, checker, linter, tests, and build as the validation loop.

Cargo provides a consistent baseline. Repositories may add feature matrices, nextest, deny checks, database setup, integration environments, or platform-specific targets through scripts and CI.

Respect the repository’s feature combinations and target matrix. Begin with the affected crate and feature set, then broaden to the workspace after focused checks pass.

Run the smallest relevant validation first. If it passes, run the broader project checks and review the final diff.

Keep longer-lived architecture context alongside your project instructions.

Use AGENTS.md for concise rules the agent should follow on every task. Keep longer architecture notes, domain context, and workflow references in repository-level StemCode memory so both stay reviewable and versionable.

Respect existing crate and module boundaries.
Do not edit target or generated build output.
Prefer existing error types and conversion patterns.
Avoid unnecessary clone, Arc, Mutex, and boxed trait objects.
Do not block the async runtime with synchronous I/O or heavy CPU work.
Run fmt, check, Clippy, and relevant tests before finishing.

Review the change in terms of your stack, not only the generated code.

Ask StemCode to inspect its own diff and check the integration points that are easiest to miss in a repository-wide change.

- ownership and lifetime correctness
- unnecessary clones and allocations
- Send/Sync and shared-state assumptions
- blocking work in async contexts
- error context and conversions
- feature-flag compatibility
- public crate API impact
- fmt, Clippy, check, and test results

Common setup questions.

Does this cover Axum, Actix Web, and Tokio?

Yes. The guide keeps framework-specific routing and runtime behavior in context while treating Cargo, crate boundaries, traits, errors, and tests as the underlying repository workflow.

Should target be indexed?

No in normal development. target is generated build output and can be extremely large. Keep manifests, source, tests, build scripts, and reviewed generated source visible instead.

Can StemCode help with borrow-checker errors?

It can inspect the surrounding types, ownership flow, trait bounds, and compiler diagnostics. The best workflow is to keep the compiler in the loop and prefer a design fix over adding clones simply to silence an error.

Put StemCode to work in a real repository.

Install StemCode, open the project you already work in, and begin with a repository-understanding task before asking the agent to change code. That gives the model better context and keeps the workflow reviewable.

npm install -g stemcode
cd your-project
stemcode