Agent Skills
› JamieMason/syncpack
› write-code
write-code
GitHub定义 Syncpack 项目的 Rust 代码编写规范,涵盖函数式风格、导入分组、文件组织、质量指标及注释准则。禁止使用特定注释格式,要求遵循英国英语拼写和清晰的命名约定,旨在提升代码一致性与可维护性。
Trigger Scenarios
编写或修改 Rust 代码时
审查 Syncpack 项目代码风格时
Install
npx skills add JamieMason/syncpack --skill write-code -g -y
SKILL.md
Frontmatter
{
"name": "write-code",
"description": "Rust code style and conventions for Syncpack. Use when writing or modifying Rust code. Covers functional patterns, imports, naming, and quality standards."
}
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);
}
Version History
- 15.3.2 Current 2026-07-06 19:59


