praxis

Classify a problem and select reasoning frameworks before starting work

Analyze a structural decision: reversibility, boundaries, and bottlenecks

Structured trade-off analysis for choosing between alternatives

Root-cause a bug before touching code: 5 hypotheses + a discriminating test

Bound an effort, time, or cost estimate with reference-class forecasting

You are a reasoning quality reviewer. Your job is to evaluate whether a solution was

MANDATORY architecture analysis. You MUST invoke this skill before making module boundary decisions, build-vs-buy choices, technology selections, data model designs, API contracts, or any structural decision that is expensive to reverse. Do NOT propose architecture without running reversibility classification, boundary analysis, and bottleneck identification. Invoke BEFORE writing implementation plans for non-trivial systems.

MANDATORY code review protocol. You MUST invoke this skill when writing significant code (not one-liners), reviewing PRs or diffs, refactoring modules, or when code quality is requested. Runs 15 structural checks across readability, structure, safety, purity, and design. Complements TDD — tests verify behavior, this verifies design quality. Do NOT ship code with 3+ safety failures without remediation.

MANDATORY trade-off evaluation. You MUST invoke this skill when the user faces a choice between alternatives — build-vs-buy, rewrite-vs-patch, technology selection, resource allocation, priority decisions. Do NOT default to the first reasonable option. Do NOT skip evaluating "do nothing" as a valid alternative. Invoke this to run weighted criteria analysis with second-order consequences before recommending.

MANDATORY debugging protocol. You MUST invoke this skill when debugging complex issues, investigating failures, diagnosing intermittent problems, or performing root cause analysis. Do NOT start changing code before collecting observations. Do NOT guess at causes — generate 5 competing hypotheses and design a discriminating test. Invoke this BEFORE touching any code when something is broken.

MANDATORY estimation protocol. You MUST invoke this skill before quoting effort, time, or cost for any non-trivial work — project plans, "how long will this take", migration sizing, budget requests. Do NOT give a single-point estimate. Do NOT estimate from first-principles optimism when comparable work exists to anchor on. Invoke this BEFORE committing to any plan with a number attached.

1 hook across 1 event