Turn anemic data structures whose fields are read and written directly across the codebase into Abstract Data Types — types defined by their *operations*, with representation hidden behind a small interface and invariants enforced inside. Use when callers reach into a struct's fields, when invariants are re-checked at every call site, when changing the internal representation would ripple through the codebase, or when you see "anemic" records carrying logic that lives in their callers. Skip for transparent data containers (DTOs, value objects, on-the-wire payloads) where representation IS the contract.
Plan by reasoning backwards from a vivid success outcome to the goals that produce it. Use when the user wants to "plan", "figure out how to get to X", "work backward", "start with the end in mind", "what needs to be true for", or when scoping a feature, project, migration, or roadmap. Especially useful when the destination is clearer than the path, or when forward brainstorming is producing scattered tasks without a shared target.
Restore module-boundary discipline — one public surface per module, dependencies flowing one direction, internals not imported across modules. Use when you see circular imports, deep relative paths (`../../../foo/bar`), confusion about "where does this live", helpers from one module imported all over the codebase, or a "utils" / "common" / "shared" module that has become the de-facto kitchen sink. Skip for single-file scripts and very small projects (< ~5 modules).
Set up or extend a project's design-system definitions — color, spacing, typography/styles, and fonts — with light and dark themes and a theming structure ready for more variants. Emits a framework-agnostic token source plus CSS and/or Flutter adapters, and writes a self-contained context card documenting them. Use this whenever the user wants to scaffold design tokens, a theme, a color/spacing/type scale, dark mode, or a "design system" — even if they only mention one piece like "set up my colors" or "add dark mode tokens".
Solidify ONE bounded concept (an Order, a Cart, a Document, a Job, a Subscription …) by applying state-machines, adt-types, and clean-modules together as an ordered recipe. Use when a single entity simultaneously has flag-soup lifecycle (`isPaid`, `isShipped`, `isCancelled`), anemic data with logic scattered across callers, AND no clear module ownership — so fixing any one alone leaves the other two still leaking. Skip when only one of the three smells is present (route to the individual skill instead) or when the concept isn't actually bounded yet.
Create or extend a project Makefile that acts as a single consolidated action script — a numbered menu plus short targets for the project's real commands (start, test, build, deploy, setup). Use when the user wants a Makefile, a "make deploy"/"make start" entry point, a task runner, or one place to discover and run a project's common actions.
Generate a compact architecture digest of an unfamiliar codebase via tree-sitter — entry points, hot internal API, per-file class/function map, external deps, orphan callables. Use when the user asks to explore, orient on, summarize, or get an overview of a repo, or when starting work on a project you haven't seen before. Supports Python, JS, TS, Go, Ruby, Rust, Java, C, C++.
Replace boolean-flag soup (`isLoading`, `isError`, `hasData`, `isComplete` …) with an explicit state machine — a named state enum plus a transition table that rejects illegal moves. Use when an entity carries 3+ correlated booleans, when impossible combinations are reachable in production (`isLoading && isError`), when transitions are scattered across the codebase, when bug reports describe "stuck in X" or "shouldn't be possible to be in Y while Z", or when a workflow has steps that must happen in order. Skip for entities with one boolean or genuinely independent flags.