en un clic
doteph
doteph contient 7 skills collectées depuis attunehq, avec une couverture métier par dépôt et des pages de détail sur le site.
Skills dans ce dépôt
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,
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.