alinafe82

alternatives-before-code

Compare viable solution paths before implementation. Use when architecture, refactors, data model changes, workflow changes, tool choices, or irreversible decisions make the first idea too sticky. NOT for one-line fixes, constrained chores, or changes with only one safe path.

assumption-audit

Find and challenge hidden assumptions in a plan, prompt, bug report, design, or AI-generated answer. Use when claims are unverified, something is called obvious or safe, or a plan depends on external behavior. NOT for confirmed requirements or tiny mechanical edits.

complexity-budget

Challenge unnecessary abstraction, dependencies, and indirection before adding them. Use when a solution adds modules, frameworks, queues, caches, state machines, agents, configuration layers, or hard-to-delete architecture. NOT for small local changes, deletion-only refactors, or accepted ADRs.

debugging-lab-notebook

Debug hard failures with reproduction, hypotheses, instrumentation, experiments, and regression proof. Use when bugs are flaky, poorly understood, production-facing, performance-related, or AI starts guessing fixes. NOT for simple bugs that already have a deterministic failing test.

problem-framing

Turn an unclear request into a concrete engineering problem statement before implementation. Use when the user jumps to code, proposes a solution without the underlying problem, or asks for a fix without reproduction. NOT for pure formatting, copy edits, or already-scoped mechanical changes.

read-the-docs-first

Check local docs, ADRs, interfaces, schemas, and primary upstream sources before guessing. Use when work depends on APIs, frameworks, repo conventions, architecture decisions, or policy. NOT for purely local refactors or cases where code is the only source of truth.

diff-interrogation

Review a human or AI-generated diff as an untrusted claim. Use when merging, committing, or accepting changes that may hide regressions, missing tests, security risk, data loss, or unexplained behavior. NOT for formatting-only diffs or already-reviewed changes with no new code.

explain-without-ai

Require a plain-language mechanism explanation before shipping, handoff, or review. Use when changes are largely AI-generated, learning-focused, or the developer may not understand the code. NOT for trivial edits, generated artifacts, or explanations already captured in a thinking ledger.

failing-test-first

Require a failing signal before bug fixes or behavior changes. Use when fixing a bug, adding behavior, changing edge cases, or reviewing AI code that lacks proof. NOT for docs-only edits, generated snapshots, or emergency hotfixes with a tracked follow-up test.

trace-the-code

Trace existing execution paths before changing unfamiliar behavior. Use when editing unknown code, debugging, reviewing AI-generated changes, or when a plan depends on current state, side effects, or error flow. NOT for greenfield files, pure docs, or already-traced isolated changes.