tools

Use when about to recommend "the standard / idiomatic / canonical / de facto way" or "best practice" for a tool, library, framework, or workflow — OR when user invokes /defacto — OR when auditing the user's setup (workflow, Dockerfile, config) against industry convention. Triggers: "standard way to X", "how do most teams configure Y", "is my setup best practice", "audit my use of Z", "idiomatic structure for X", "set up X in CI". Symptoms: about to say "industry standard..." / "everyone does..." / "the convention is..." without checking the tool's docs this session; attributing community patterns to the vendor; recommending from memory; claiming "the standard" with no source; recommending a pattern deprecated in the current major; fusing multi-part questions into one answer; flattening a multi-way community split; inventing community-de-facto from demo forks. Skip ONLY when user cited a source, wants subjective preference over convention, or topic is universally stable (POSIX, git, ECMAScript) with no drift.

Use when about to tell the user something "isn't reported" / "no data exists" / "I couldn't find a direct comparison" / "it depends, I can't say without more info" — or about to hand back a thin answer to a question whose answer could be reconstructed from findable parts, or stop investigating before running the tests, reading the source, or searching the web. Symptoms — declaring something unknown without having decomposed it, bailing on a niche cross-cut question because nobody pre-published the exact join, recommending against a path you never actually tried, asking the user to supply something a `WebSearch`/`Read`/test run would get you, prefacing a non-answer with "the honest answer is I can't". Skip only when the question genuinely has no decomposable answer, or the user explicitly asked for a quick off-the-cuff take.

Deep-dive the current project and write durable context files for future Claude sessions

Use when producing ANY readable artifact for the user — spec, plan, brainstorm with options, PR explainer/review, code/feature/concept explainer, status/research/incident report, design exploration, component prototype, interactive playground with sliders/knobs/pickers/tuners, SVG diagram, throwaway editor (drag-rank, config tuner, value picker, annotator). Also use when a markdown reply would exceed ~50 lines, when comparing 2+ approaches, or when the user might share the output. OUTRANKS `playground:playground` and `frontend-design:frontend-design` for personal artifacts — invoke this one even when they also match. Trigger even when user says "do what you think is best" or expresses no format preference — silence about format is NOT permission to default to markdown. Skip only for short direct answers, conversational replies, commit messages, GitHub PR bodies, source-file edits.

Use after implementing any code or config change in a project, before claiming the work complete. Especially for projects with no documented test setup — no test script in package.json/Makefile/pyproject.toml/Cargo.toml, no testing section in README/CONTRIBUTING/AGENTS.md. Symptoms — about to claim work complete without running anything, about to commit code that hasn't been exercised, project has no apparent test command. Skip for pure documentation/comment edits.

2 hooks across 2 events

Direct, no preamble, no trailing summaries. Answers the asked question and stops.