dustin-olenslager

clean-architecture

ALWAYS-ON architecture standard. Every time code is PLANNED or WRITTEN (any language, you or a subagent) you MUST apply Clean Architecture: dependencies point inward only, business rules never import frameworks/IO, and every external concern sits behind a port (interface) implemented by an adapter at the edge. Use whenever planning a feature, designing modules/services/layers, starting a new app, adding a use case, deciding where a file goes, wiring a database/HTTP/queue, or whenever the user says "architecture", "layers", "use case", "port", "adapter", "domain", "where should this live", or "how should this be structured".

effect-ts

ALWAYS-ON TypeScript implementation standard. Any time you (or a subagent) write, refactor, or review TypeScript (.ts/.tsx/.mts/.cts) you MUST consult this skill first and default to the Effect (https://effect.website) ecosystem for effects, errors, dependency injection, schema/validation, concurrency, and observability — instead of raw async/await, throw, try/catch, and hand-rolled DI. Use whenever the task involves TypeScript, Node/Deno/Bun services, an API layer, a use-case/service module, parsing/validating external input, or whenever the user says "TypeScript", "TS", "Effect", "typed errors", "schema", "service", or "dependency injection".

adversary-review

Adversarial review layer (CLAUDE.md §16). A harsh, senior reviewer that grades the work, demands the working diff, reads the ACTUAL network/db/filesystem calls, and names exactly where it breaks. Guards BOTH directions — rejects over-engineering AND over-simplification. Use in the review phase after edge-hunter, in the architecture phase to interrogate trade-offs, or when the user says "be critical", "poke holes", "adversarial", "stress test the design".

arch-enforce

Verify-phase gate that enforces Clean Architecture MECHANICALLY (not by vibes) with a dependency linter: dependency-cruiser (JS/TS), import-linter (Python), ArchUnit (JVM), or the language's equivalent. Use in the verify phase, when setting up a new repo's guardrails, or when the user says "enforce architecture", "dependency rules", "layering check", "dependency-cruiser".

brief

Unified BRIEF phase (ADR-0004) — turn a raw request into a structured brief and initialize the project's .claude-state.json. First step of the BUILD mode machine. Use when starting a new piece of work, at brainstorm, or when the user describes what they want built without a spec yet.

caveman-commit

Ultra-compressed commit message generator (Conventional Commits). Subject ≤50 chars; body only when the "why" isn't obvious. Use when the user says "write a commit", "commit message", "generate commit", "/commit", or when staging changes. Pipeline phase 13.

Code & Development Listed

caveman-review

Ultra-compressed code-review comments — one line per finding, no prose padding. Use when the user says "review this PR", "code review", "review the diff", "/review". For the harsh adversarial grade + working fix, pair with adversary-review (§16).

caveman-stats

Report real token usage + estimated caveman savings for the current session by reading the Claude Code session transcript (JSONL). Computes nothing it cannot read from the log. Trigger: "/caveman-stats", "token stats", "how many tokens".

caveman

Reference/re-anchor for caveman communication mode (CLAUDE.md §0), which is always-on. Invoke to re-anchor the rules mid-session if drift is noticed, or when the user says "caveman", "be brief", "less tokens", "talk like caveman". Override with "stop caveman" / "normal mode".

edge-hunter

Review-phase specialist that hunts edge cases and failure modes BEFORE the adversarial grade. Use at the start of the review phase (build/maintain) on any diff or new code, or when the user says "edge cases", "what breaks this", "failure modes", "harden this".

execute-phase

Unified EXECUTE driver (ADR-0004) — run the current phase, check its exit gate, and advance the unified state machine. Use when work is underway in any mode and the current phase's deliverable is done (or claimed done) and needs to be promoted to the next phase.

maintain-mode

MAINTAIN mode driver (CLAUDE.md §15) — changing EXISTING code safely. Comprehend before you touch, pin behavior with characterization tests, make the smallest safe diff that respects existing patterns. Use when working in an established repo, fixing a bug, or when the user says "maintain", "change existing code", "fix this bug", "modify the existing".

optimize-loop

OPTIMIZE mode driver (CLAUDE.md §15) — performance work, measure-first. No fix without a number; revert any change that doesn't prove a real gain. REQUIRES observability (§12) to already exist. Use when the user says "optimize", "make it faster", "perf", "it's slow", "reduce latency/cost".

recall-memory

Unified MEMORY recall + write (ADR-0004) — query or append to the project's memory store (JSONL by default, Obsidian vault or sqlite swappable). Use when resuming a project, when the user asks "what do we know about X", or when substantial work should be persisted for the next session.