菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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 build-time, inline, workspace, and generic-boundary guidance to eph. Use when changing Rust crate structure, public generic APIs,
| name | rust100k-testing-discipline |
| description | 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. |
Design tests around product behavior and data, keep them real, and avoid mocks.
This skill combines Matklad's Delete Cargo Integration Tests and How to Test
guidance with the eph conflict decisions in .agents/skills/readme.md.
.eph parsing, workspace identity, environment rendering, lifecycle state transitions, process control, CLI behavior, and live Docker resources.check(...) helper with data inputs and expected data outputs over many tests that call internal APIs directly.tests/integration.rs for CLI and live lifecycle behavior, and tests/stress.rs for ignored heavyweight concurrency and all-backend scenarios. Do not create another root integration crate without a distinct build or execution boundary.cargo fmt --check, cargo test, and cargo clippy --all-targets -- -D warnings.mockall, or fake boundaries for eph-owned behavior.src/.tests/integration.rs; keep resource-intensive, concurrent, and all-source cases in ignored tests/stress.rs tests.tempfile; network assertions speak to the real service on eph's assigned host port.cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo test -- --test-threads=1
cargo test --test stress -- --ignored --test-threads=1
No mocks, no mockall, executable doctests, the two deliberate root test
crates, and causality-preserving concurrency tests remain review rules.
Read references/article-notes.md for source notes and conflict context.