rust-crate-ci
Skill517 starsChanged 3 days agoMITView on GitHub
Load before editing any Rust crate in this repo (currently runners/swarm-sandbox-runner). Covers the mandatory local validation gate, common rustfmt/clippy pitfalls, and Windows-specific Rust correctness patterns that CI enforces but are hard to catch locally without a Windows toolchain.
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 0 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 38
Run them in this exact order.
- Very specific: line 41
If cargo is not in PATH locally (e.g.
- Very specific: line 51
Long
format!macros: If the total length of format!("...", arg) exceeds the line limit, rustfmt splits it. - Very specific: line 71
Rule of thumb: After editing, always run cargo fmt (not --check) locally to apply rustfmt's opinion, then read the diff before committing.
- Very specific: line 109
If you compare a canonicalized path against a policy root stored without this prefix, the comparison silently fails.
- Very specific: line 131
If your code stores the temp_dir() path as a policy root and then canonicalizes the cwd, the comparison will fail because RUNNER~1 ≠ …
- Very specific: line 179
All third-party uses: actions are pinned to 40-character SHAs per the repo policy.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Rust Crate CI Guide
This repo contains a Rust crate at runners/swarm-sandbox-runner/. The CI job that
validates it is rust-sandbox-runner (runs on windows-latest). This guide prevents
the most common failure modes before they reach CI.
Mandatory local gate (run in order before pushing)
cd runners/swarm-sandbox-runner
# 1. Format check — CI fails here first; clippy will not run if this fails
cargo fmt --check
# 2. Clippy — -D warnings makes all warnings hard errors; --all-targets matches CI,
# which also lints tests, examples, and benches (ci.yml rust-sandbox-runner job)
cargo clippy --all-targets -- -D warnings
# 3. Tests — --all-targets matches CI; Windows-specific tests are gated with #[cfg(windows)]
cargo test --all-targets
# 4. Release build — confirms the binary compiles with optimizations
cargo build --releaseRun them in this exact order. If cargo fmt --check fails, fix formatting first —
clippy errors may be masked until fmt passes.
If cargo is not in PATH locally (e.g. you are on a machine without Rust installed),
push to a draft PR and let CI run the checks. Read the CI log carefully; do not guess
at what failed.
How rustfmt makes decisions
rustfmt (current stable — rust-toolchain.toml floats on channel = "stable")
applies line-length thresholds per syntax item, not per file or per block.
Two patterns that look equivalent locally can format differently:
Long format! macros: If the total length of format!("...", arg) exceeds the
line limit, rustfmt splits it. If it fits on one line, rustfmt collapses it.
// rustfmt will COLLAPSE this to one line if it fits:
return Err(RunnerError::PolicyViolation {
reason: format!(
"cwd resolves outside allowed roots (symlink egress): {canonical_str}"
),
});
// rustfmt will SPLIT this if it exceeds the limit:
events::emit(&events::denial_event("deny_symlink_egress", Some(canonical_str)));
// becomes:
events::emit(&events::denial_event(
"deny_symlink_egress",
Some(canonical_str),
));Rule of thumb: After editing, always run cargo fmt (not --check) locally to
apply rustfmt's opinion, then read the diff before committing. Do not hand-format
and assume rustfmt agrees.
Common clippy errors in this codebase
windows-rs 0.58 API changes: Several Win32 APIs changed signatures between
windows crate versions. The Cargo.toml pins the version; do not bump it without
checking the full API diff.
HANDLE is not Send + Sync: Raw HANDLE values cannot be sent across threads.
Wrap them in a newtype with unsafe impl Send and unsafe impl Sync, or use
OwnedHandle from std::os::windows::io. The kill-callback pattern in
temp_watcher.rs uses raw isize (handle as integer) to sidestep this.
Unused imports: #[cfg(windows)] blocks frequently hide imports that are used
only on Windows. On non-Windows builds, the import becomes dead code. Use
#[cfg(windows)] on the use statement itself or accept the #[allow(unused_imports)]
annotation for platform-conditional code.
struct default initialization: For Win32 structs like STARTUPINFOW, use a
struct initializer with ..Default::default() rather than unsafe { std::mem::zeroed() }
— clippy flags the latter when Default is available.
Windows path normalization (critical correctness patterns)
These bugs are invisible on Linux/macOS CI and will only appear on windows-latest.
std::fs::canonicalize always prepends \\?\
On Windows, canonicalize typically returns a verbatim extended-length path with
the \\?\ prefix, but this is not guaranteed across all Windows configurations and
path forms. Always use .strip_prefix with a fallback:
C:\foo\bar → \\?\C:\foo\bar (typical)If you compare a canonicalized path against a policy root stored without this prefix,
the comparison silently fails. Strip the prefix before comparing, always with .unwrap_or:
let lower = canonical.to_string_lossy().to_lowercase();
let canonical_str = lower.strip_prefix("\\\\?\\").unwrap_or(&lower);Apply the same strip to both sides of any comparison.
GitHub Actions CI uses 8.3 short names in %TEMP%
std::env::temp_dir() on GitHub Actions Windows runners returns a path like:
C:\Users\RUNNER~1\AppData\Local\TempBut std::fs::canonicalize expands it to:
C:\Users\runneradmin\AppData\Local\TempIf your code stores the temp_dir() path as a policy root and then canonicalizes
the cwd, the comparison will fail because RUNNER~1 ≠ runneradmin.
Fix: Canonicalize both the policy root AND the cwd before comparing. Fall back to the raw value if the root does not exist on disk yet:
let root_resolved = std::fs::canonicalize(root)
.map(|p| p.to_string_lossy().to_lowercase())
.unwrap_or_else(|_| root.to_lowercase());
let root_cmp = root_resolved
.strip_prefix("\\\\?\\")
.unwrap_or(&root_resolved)
.to_owned();WaitForSingleObject return value semantics
WAIT_TIMEOUT is 0x00000102u32, not a Rust Err. Check the return value
explicitly before treating the child as having exited normally.
IPC contract stability
The exit codes in error.rs are frozen — do not renumber them. TypeScript
callers in runner-client.ts depend on these values:
| Code | Meaning |
| 0 | Child exited zero (or non-zero child exit code passed through directly) |
| 64 | Policy violation |
| 65 | Temp quota exceeded |
| 66 | Wall-clock timeout |
| 67 | Launcher misconfiguration or policy parse error (invalid JSON from caller) |
| 68 | OS API failure, I/O error, or JSON error |
| 69 | Probe failed |
The NDJSON event types on stderr (start, denial, quota_exceeded, exit) are
also frozen. Adding new event types is safe; renaming or removing existing ones
is a breaking IPC change.
Exit events are required on every termination path. Emit exit_event before
returning from both the wall-clock timeout path and the temp-cap kill path, not
only on the normal exit path. TypeScript consumers block waiting for an exit event.
CI workflow reference
The job is defined in .github/workflows/ci.yml as rust-sandbox-runner.
It runs on windows-latest with the toolchain pinned in runners/swarm-sandbox-runner/rust-toolchain.toml.
All third-party uses: actions are pinned to 40-character SHAs per the repo policy.
Steps in order: fmt check → clippy → tests → release build → probe smoke test.
Other versions1 project uses a version of this.
Word for word · 1
- zaxbysauce/opencode-swarm★ 517100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository66 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- ci-fix-monitorSkill
- codebase-review-swarmSkill
- commit-prSkill
- contributingSkill
- engineering-conventionsSkill
- fork-pr-operationsSkill
- guardrail-patternsSkill
- issue-tracerSkill
- mock-to-internals-migrationSkill
- pr-review-fixSkill
- qa-sweepSkill
- research-firstSkill
- running-testsSkill
- subprocess-safetySkill
- swarm-ci-monitorSkill
- swarm-implementSkill
- swarm-pr-feedbackSkill
- swarm-pr-reviewSkill
- swarm-pr-subscribeSkill
- swarmSkill
- tech-debt-ci-reviewSkill
- test-file-splitSkill
- unswarmSkill
- writing-testsSkill
- brainstormSkill
- clarifySkill
- clarify-specSkill
- codebase-review-swarmSkill
- commit-prSkill
- consultSkill
- councilSkill
- critic-gateSkill
- deep-diveSkill
- deep-researchSkill
- design-docsSkill
- discoverSkill
- durable-session-stateSkill
- editing-skillsSkill
- engineering-conventionsSkill
- executeSkill
- fork-pr-operationsSkill
- graphifySkill
- issue-ingestSkill
- issue-tracerSkill
- orchestrating-subagentsSkill
- phase-wrapSkill
- pre-phase-briefingSkill
- qa-sweepSkill
- research-firstSkill
- specifySkill
- swarm-ci-monitorSkill
- swarm-implementSkill
- swarm-planSkill
- swarm-pr-feedbackSkill
- swarm-pr-reviewSkill
- swarm-pr-subscribeSkill
- swarm-resumeSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

