write-code
Provides style guidelines and code conventions for writing Rust code in Syncpack.
Install
mkdir -p .claude/skills/write-code && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/7256" && unzip -o skill.zip -d .claude/skills/write-code && rm skill.zipInstalls to .claude/skills/write-code
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Rust code style and conventions for Syncpack. Use when writing or modifying Rust code. Covers functional patterns, imports, naming, and quality standards.Key capabilities
- →Enforce Rust naming conventions
- →Apply functional pipeline patterns
- →Standardize import strategies
- →Maintain Syncpack quality standards
How it works
Applies specific style rules, import grouping, and functional programming patterns to Rust code.
Inputs & outputs
When to use write-code
- →Refactor Rust modules
- →Add new features to Syncpack
- →Improve code naming and imports
About this skill
Write Code
Rust code conventions for Syncpack.
Style
- Functional style: pipelines over loops
- Avoid
?chains: use.and_then(),.map(),.or_else() - Descriptive names: clarity over brevity
- Named placeholders:
println!("{var}")notprintln!("{}", var) - British English: "behaviour" not "behavior", "organised" not "organized"
Imports
Single use statement with grouped braces:
use {
crate::{cli::Cli, config::Config},
log::{debug, error},
std::{process::exit, sync::Arc},
};
Rules:
- Never use
super::— alwayscrate::for internal imports - Group:
crate::, external crates,std:: - Alphabetise within groups
File Organisation
| Adding... | Location |
|---|---|
| New command | src/commands/{name}.rs |
| New test | Sibling _test.rs file (e.g., src/foo.rs → src/foo_test.rs) |
NEVER use #[cfg(test)] modules inside implementation files.
Quality
- Functions <50 lines, commands 100-300 lines
- Zero warnings (except during TDD red phase)
- Run
just formatbefore committing
Comments
Forbidden
//!module docs — collect implementation history and rot- Phase/F-N labels —
// Phase v4-2,// F16:, banner headers like// ---------- Phase v4-3 RED ---------- - History refs —
Migrated from,carry-over,Mirrors v3,replaces the v3,previously inside X,reserved for future - Issue/PR refs —
Reproduces issue #239,GitHub issue #206. Plans rot; the code is the truth - Banner separators —
// ---------- Free functions: yaml ops ----------. Use module structure or let the file speak for itself - Test scenario labels — don't write
// Windows-style backslashesabove a test input. Use a descriptive variable binding (let windows_backslashes = [...]) instead - Name-restating field docs —
/// A unique identifier for this instance,/// The dependency name,/// The instance id. The field name already says it - Step numbering inside functions —
// 1. ...,// 2. .... Drop the numbers; keep the WHY if it's non-obvious
Allowed
@TODOmarkers — future plans worth tracking inline///doc comments for non-obvious detail:None/Errsemantics, side effects, invariants, distinctions between similar fields (e.g.is_local_dependencyvsis_local_instance)//inline comments when WHY is non-obvious: hidden constraints, ordering invariants ("SnappedTo groups must be visited last"), workarounds for surprising library behaviour, "must not poison X" cautions
Default
No comments. Add one only when the WHY is non-obvious to a fresh reader.
Patterns
Iterating Instances
ctx.version_groups.iter().for_each(|group| {
group.get_sorted_dependencies(&ctx.config.cli.sort).for_each(|dependency| {
dependency.get_sorted_instances()
.filter(|instance| instance.is_invalid())
.for_each(|instance| { /* process */ });
});
});
Error Handling
Prefer combinators over ?:
// Good
path.parent()
.and_then(|p| p.to_str())
.map(|s| s.to_string())
.unwrap_or_default()
// Avoid
let parent = path.parent()?;
let str = parent.to_str()?;
Ok(str.to_string())
State Mutation
let mut state = instance.state.borrow_mut();
if !state.is_invalid() {
*state = InstanceState::fixable(SomeVariant);
}
When not to use it
- →Writing non-Rust code
- →Projects outside Syncpack standards
Prerequisites
Limitations
- →Requires adherence to Syncpack-specific style rules
How it compares
Enforces strict, project-specific conventions instead of general Rust guidelines.
Compared to similar skills
write-code side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| write-code (this skill) | 1 | 3mo | Review | Intermediate |
| deepwiki-rs | 25 | 9mo | Review | Intermediate |
| implementing-cards | 7 | 2mo | Review | Advanced |
| rust-tests-guidelines | 7 | 5mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by JamieMason
View all by JamieMason →You might also like
deepwiki-rs
sopaco
AI-powered Rust documentation generation engine for comprehensive codebase analysis, C4 architecture diagrams, and automated technical documentation. Use when Claude needs to analyze source code, understand software architecture, generate technical specs, or create professional documentation from any programming language.
implementing-cards
bcollazo
Fill out the implementation of effects of different attacks, abilities, and trainer cards in this Pokemon TCG Pocket engine codebase.
rust-tests-guidelines
RediSearch
Guidelines for writing Rust tests.
write-rust-tests
RediSearch
Write Rust tests to verify correctness of Rust code.
check-rust-coverage
RediSearch
Check which Rust lines are not covered by Rust tests.
rust-errors
EpicenterHQ
Rust to TypeScript error handling patterns for Tauri apps. Use when defining Rust errors that will be passed to TypeScript, handling Tauri command errors, or creating discriminated union error types.