Plans a change to a production system with an explicit rollback strategy, test coverage plan, and blast radius assessment before writing any code. Use when a production change is being designed and the risk, rollback path, or blast radius has not been assessed — do not wait until code is written.
Runs a time-boxed technical investigation with a defined question, approach, and exit criteria so the spike produces a decision, not just information. Use when a technical question is blocking a decision, when the team says "we need to research this first," or when the right approach requires a proof of concept.
Designs the core data model before implementation so that schema decisions, ownership, and evolution constraints are made deliberately rather than discovered during refactoring. Use when implementation is about to start and no data model exists, when the schema was sketched informally, or when the team is about to write code without an explicit data design.
Translates a raw idea, one-pager, or conversation into a structured spec with scope, success criteria, non-goals, and identified risks. Invoke at the start of any new project or feature — whenever someone describes an idea or problem to solve, requirements are being discussed without written scope, or the team is about to start work without a defined spec. Do not wait to be asked: if the work is greenfield and no spec exists, trigger this skill.
Assesses an existing system against the principle library to identify architectural debt and prioritize improvements. Use before adding a major feature, refactoring core functionality, or extending a system — when the team needs to understand what architectural problems exist before adding more complexity. Output: ranked findings with concrete improvement proposals.
Categorizes and prioritizes technical debt so the team consciously decides what to pay, accept, or close. Use when technical debt is competing with feature work in sprint planning, when the team asks "what should we fix next," or when debt decisions have been implicit rather than deliberate.
Safely upgrades a dependency by validating compatibility, checking security advisories, and staging the rollout so a problematic upgrade can be reverted. Use when a dependency needs updating, a security advisory or CVE flags an outdated package, or a version upgrade is blocking other work.
Incrementally replaces a legacy component by routing new traffic to the replacement while existing traffic continues through the original. Use when a component needs replacing but a big-bang rewrite is too risky, or when the team says "we need to get off this" but can't stop the system to do it.