ワンクリックでManusで任意のスキルを実行

rust-clean-code

スター9

フォーク0

更新日2026年4月10日 04:13

Clean-code guidance for Rust: function size, modules, error handling, naming, and tests. Use during refactors, readability reviews, or when the user asks for cleaner or more maintainable code without a specific architecture topic.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

antonygiomarxdev

antonygiomarxdev/maverick

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Rust — clean code

Practical principles (community-aligned)

Readability over micro-optimization unless a path is measured as hot.
Explicit over implicit: clear return types; visible conversions (.into(), TryFrom).
Errors as values: propagate Result; prefer ? over nested if let Err.
Less shared mutable state; when it exists, keep boundaries clear (Arc, channels, or single-owner design).

Review checklist

Does the function fit one screen and does its name describe the observable effect?
Is every pub justified, or can visibility shrink?
Any unwrap/expect outside tests or documented invariants?
Do tests assert observable behavior, not brittle implementation details?

Warning signs

Many parameters of the same primitive type → context struct or builder.
Heavy clone to appease the borrow checker without revisiting API boundaries → redesign ownership at the boundary.

このリポジトリの他の Skills

同じリポジトリ

rust-best-practices

antonygiomarxdev/maverick

Idiomatic Rust and engineering hygiene: Clippy, Option/Result patterns, ownership in APIs, iterators, unsafe discipline, async Send boundaries, and public API docs. Use when writing or reviewing Rust, onboarding idioms, or when the user asks for Rust best practices, idioms, or lint hygiene.

2026-04-109

rust-linter-configuration

antonygiomarxdev/maverick

Documents Maverick Rust lint and format setup: rustfmt.toml, Clippy flags in CI, cargo aliases, and policy for allow/expect attributes. Use when configuring editors, fixing CI lint failures, adding clippy.toml or rustfmt options, or when the user mentions linters, rustfmt, Clippy, or -D warnings.

2026-04-109

rust-no-magic-values

antonygiomarxdev/maverick

Applies common production Rust practices to remove magic literals: named consts, enums, newtypes, and centralized schema strings. Use when writing or reviewing Rust, when the user mentions magic strings/numbers, duplicated literals, or when designing core versus adapter layers.

2026-04-109

rust-solid-hexagonal

antonygiomarxdev/maverick

Applies SOLID and hexagonal architecture in Rust: traits as ports, implementations in adapters, dependency inversion. Use when designing maverick-core/domain versus adapters, adding persistence or transport, or when the user mentions SOLID, ports, adapters, or coupling.

2026-04-109

name	rust-clean-code
description	Clean-code guidance for Rust: function size, modules, error handling, naming, and tests. Use during refactors, readability reviews, or when the user asks for cleaner or more maintainable code without a specific architecture topic.

Rust — clean code

Practical principles (community-aligned)

Readability over micro-optimization unless a path is measured as hot.
Explicit over implicit: clear return types; visible conversions (.into(), TryFrom).
Errors as values: propagate Result; prefer ? over nested if let Err.
Less shared mutable state; when it exists, keep boundaries clear (Arc, channels, or single-owner design).

Review checklist

Does the function fit one screen and does its name describe the observable effect?
Is every pub justified, or can visibility shrink?
Any unwrap/expect outside tests or documented invariants?
Do tests assert observable behavior, not brittle implementation details?

Warning signs

Many parameters of the same primitive type → context struct or builder.
Heavy clone to appease the borrow checker without revisiting API boundaries → redesign ownership at the boundary.