القائمة
Apply Matklad Rust100k build-time, inline, workspace, and generic-boundary guidance to eph. Use when changing Rust crate structure, public generic APIs,
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | rust100k-build-performance |
| description | Apply Matklad Rust100k build-time, inline, workspace, and generic-boundary guidance to eph. Use when changing Rust crate structure, public generic APIs, |
Keep Rust build time and hot-path performance visible together. This skill covers Matklad's Inline In Rust, Large Rust Workspaces, and Fast Rust Builds posts, with eph's small-project conflict decisions documented in .agents/skills/readme.md.
cargo metadata plus targeted cargo commands.#[inline] as cross-crate body exposure, not a magic speed switch. In applications, add it reactively after profiling or for tiny public wrappers.#[inline(always)] rare and evidence-backed. Prefer #[cold] or #[inline(never)] for error/cold paths only when profiling or layout concerns justify it.impl Trait or generics when they improve clarity or runtime performance. Split crates only when measurements or independent ownership boundaries justify it.crates/* layout, a virtual root manifest, folder names matching crate names, and a dedicated automation crate rather than scattered scripts.cargo fmt --check, cargo test, and cargo clippy --all-targets -- -D warnings.cargo fmt --check, cargo test, and cargo clippy --all-targets -- -D warnings as the ordinary gate.Makefile.impl Trait where it improves current clarity or runtime performance.cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo test -- --test-threads=1
Generic boundary and inline tradeoffs remain review rules. The crate-level lint attributes and CI commands are the executable policy.
Read references/article-notes.md for source notes and tool suggestions.
Use when working in a repository that uses eph for ephemeral dev services (a `.eph` file exists, or `eph` is on PATH). Covers workspace detection, strict .eph parsing, auto-assigned ports, up/env/down/clean, roles, hooks, one-off commands, foreground and watch sessions, logs, and stale-workspace pruning.
Use when working in a repository that uses eph for ephemeral dev services (a `.eph` file exists, or `eph` is on PATH). Covers workspace detection, strict .eph parsing, auto-assigned ports, up/env/down/clean, roles, hooks, one-off commands, foreground and watch sessions, logs, and stale-workspace pruning.
Apply Alexis King's "Names are not type safety" advice in eph. Use when adding, reviewing, or refactoring Rust newtypes, wrapper structs, workspace or process identities, service names, paths, command text, state records, domain enums, smart constructors, or APIs that rely on naming conventions for correctness.
Apply Alexis King's "Parse, don't validate" design rule in eph. Use when adding or reviewing Rust boundary code for .eph text, persisted JSON state, CLI arguments, environment variables, process identities, Compose output, release metadata, or any function that checks input validity before deeper processing.
Maintain eph's Rust architecture documentation in the Matklad Rust100k style. Use when changing module boundaries, the CLI/library split, parsing, workspace identity, lifecycle or state ownership, process control, pruning, bundled skills, updates, docs/developer-guide/architecture.md, docs/developer-guide/internals.md, or when reviewing whether code structure and architecture docs agree.
Apply Matklad Rust100k testing discipline to eph. Use when adding, reviewing, or reorganizing Rust tests, choosing unit versus Docker integration or stress coverage, designing fixtures, rejecting mocks, adding doctests, or changing Makefile and CI test coverage.