Install
$ agentstack add skill-mfmezger-ai-agent-dotfiles-rust-engineering ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Rust Engineering
Produce Rust that is safe, explicit, and maintainable under review. Default to stable language features, minimal unsafe, narrow APIs, and code that passes formatting, linting, and tests.
Workflow
- Identify the artifact.
Library: optimize for explicit API boundaries, typed errors, docs, and semver-safe design. Application or CLI: optimize for operability, context-rich errors, tracing, and clear failure modes.
- Model types before writing control flow.
Prefer enums, newtypes, and private fields over ad hoc strings, flags, or loosely related values.
- Choose ownership deliberately.
Accept borrowed inputs where practical, return owned outputs when crossing boundaries, and make cloning explicit.
- Choose the failure model early.
Libraries usually use thiserror; applications usually use anyhow at the outer boundary and typed errors internally when helpful.
- Choose the concurrency model deliberately.
Use synchronous code unless async is justified by I/O concurrency needs. When async is justified, use Tokio and design cancellation, timeouts, and shutdown explicitly.
- Verify before finalizing.
Run cargo fmt --check, cargo clippy --all-targets --all-features, and relevant tests. Address warnings instead of normalizing them.
Load References By Need
| Need | Reference | |---|---| | Project setup, crate structure, CLI patterns, tracing | references/workflow.md | | Error model, thiserror vs anyhow, context, path/file failure handling | references/errors.md | | Ownership, API boundaries, newtypes, traits, visibility, serde-facing types | references/api-and-types.md | | Tokio, cancellation, timeouts, shared state, task spawning, async traits | references/async-and-concurrency.md | | Unit/integration/doc/property tests, benchmarks, temp files, review checklist | references/testing-and-quality.md | | Allocation control, data layout, slices, Cow, boxing, profiling | references/performance-and-memory.md | | Common footguns and review traps | references/footguns.md |
Default Standards
- Keep
main.rsand public entrypoints thin; move logic into modules orlib.rs. - Keep struct fields private by default. Expose behavior, not raw state.
- Prefer
&str,&[T], iterators, and generic bounds over overly concrete argument types. - Return
Resultfor expected failures. Reserve panics for invariant violations and test scaffolding. - Document every
unsafeblock with a// SAFETY:comment describing the invariants. - Prefer stable language features. Use macros or nightly-only ideas only with a clear reason.
- Prefer typed domain models over magic strings and boolean flags.
- Treat Clippy findings as design feedback, not noise.
Code Review Checklist
- Are invalid states made unrepresentable with types?
- Are ownership and cloning choices intentional?
- Are error messages actionable and context-rich?
- Is async justified, and are blocking operations kept off the runtime?
- Are file writes atomic where corruption would matter?
- Are string/path operations preserving correctness instead of forcing lossy conversions?
- Are tests covering error paths, edge cases, and externally visible behavior?
- Is there any avoidable
unsafe, panic, or allocation churn?
Sources and Influences
This skill synthesizes ideas from the following public Rust skill work rather than copying any one source directly:
rust-agentic-skillsby UdapY: https://udapy.github.io/rust-agentic-skills/rust-skillsby leonardomso: https://agent-skills.md/skills/leonardomso/rust-skills/rust-skills- Mirror for
rust-skillsby leonardomso: https://skills.sh/leonardomso/rust-skills/rust-skills
Use those sources for attribution and broader context; use this skill's references for the repo-specific, agent-oriented structure.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: mfmezger
- Source: mfmezger/aiagent_dotfiles
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.