Keeping Files Small
Use when about to add lines to an existing source file, when a single file passes ~400 lines, or when proposing where to put new code — prevents files from sprawling into multi-concern god-modules
Using Repo Hygiene
Use when starting any conversation in a repo — establishes the repo-hygiene skill set and the moments each sub-skill applies
Gating Commits
Use when about to commit, merge, or push — runs verification (tests, typecheck, lint), confirms focus, and checks sibling hygiene (docs, tests, docstrings) BEFORE the commit lands, so "user said commit" doesn't bypass quality
Using Second Thought
Use when starting any conversation and before major decisions to ensure second-thought critique is auto-applied before commitment, especially in brainstorming, convergence, and pre-execution phases.
Second Thought
Use when an idea, decision, design, plan, response, tool call, or action is about to be accepted or executed, especially during brainstorming, convergence, and pre-execution where shallow agreement or goal drift may occur.
Writing Commit Messages
Use when drafting any commit message — sets format (imperative subject under 72 chars, explanatory body when the why isn't obvious from the diff) and prevents the "Fix X" one-liner reflex for non-trivial fixes
Testing New Code
Use when adding or modifying business logic, branching code, public API, or fixing a bug in a repo using repo-hygiene — tests for the new code paths must exist before the change is committed, not "later" or "if the user asks
Keeping Docs Fresh
Use when changing a public API surface — renamed export, changed signature/return type, new or removed flag/route/env var, schema migration, deprecation — before committing, so README, docs/, CHANGELOG, and inline references stay coherent with the code
Writing Docstrings
Use when writing or modifying any function, method, class, or source file in a repo using repo-hygiene — public API, internal helpers, and new files all require docstrings; only one-line lambdas and trivial accessors are excluded
Stagecraft
Use when the user wants premium, keynote-style UI with refined motion — dark, minimal, cinematic reveals. Trigger words include "premium," "polished," "cinematic," "Apple-like," "keynote," "launch page," "product reveal," and "elevate this screen." Also use when asked to audit or restyle an existing screen to feel more restrained and intentional.
Orienting To Repo
Use when starting substantive work in an unfamiliar repo, before diving into task-specific grep or edits — especially when the task touches business logic, public API, build, or infra, or you don't yet know the repo's purpose, stack, conventions, or layout
Cleaning Existing Codebase
Use when the user asks to "clean up", "apply repo-hygiene to", or "fix the hygiene of" an existing codebase — orchestrates the other hygiene skills in a phased, reviewable order rather than firing a 200-file mega-diff