praxis

Reasoning router — invoke before starting any non-trivial task: designing a system or feature, debugging a failure, architecture decisions, security-sensitive code, trade-off choices, significant refactors, reviewing a design or plan, or strategy. Classifies the problem, routes to the matching reasoning protocol, and validates conclusions before they are final. Skip only for trivial mechanical work: typo fixes, renames, one-liners, factual questions, running commands.

MANDATORY comprehension protocol. You MUST invoke this skill before changing code you did not write or do not already understand — modifying, fixing, extending, or refactoring an existing file, function, or module whose behavior you have not traced. Do NOT edit from pattern-matching. Do NOT claim "nothing else is affected" without checking. Invoke BEFORE proposing the edit. Does NOT apply to greenfield code you are writing from scratch, or to diagnosing a runtime failure (use diagnostic-reasoning).

MANDATORY modeling protocol. You MUST invoke this skill when designing a data model, domain model, database schema, or the core entities and relationships of a system — "design the schema", "model this domain", "what tables/entities do we need". Do NOT jump to tables or classes before the invariants are named. Do NOT leave illegal states representable. Invoke BEFORE writing migrations, ORM models, or type definitions for the domain. Does NOT apply to choosing a database engine (use architecture-reasoning).

MANDATORY planning protocol. You MUST invoke this skill when turning a decided goal into an execution plan — breaking a project or feature into sequenced tasks, milestones, or a roadmap; "plan this out", "what's the build order", "break this into steps". Do NOT hand back a flat to-do list. Do NOT bury the riskiest work in the middle. Invoke BEFORE presenting any multi-step plan. Does NOT apply to estimating effort (use estimation) or choosing between approaches (use decision-analysis).

MANDATORY prompt-design protocol. You MUST invoke this skill when writing or revising a prompt, system prompt, agent instruction, or LLM task specification meant to run repeatedly — "write a prompt that...", "improve this prompt", "the model keeps doing X, fix the instructions". Do NOT ship a prompt tested only on the happy path. Do NOT finalize before adversarial inputs are run against it. Invoke BEFORE handing over the prompt. Does NOT apply to a one-off question you are asking a model right now, or to ordinary application code.

MANDATORY scoping protocol. You MUST invoke this skill when turning a vague or open-ended request into a defined build scope — "what should the MVP be", "scope this feature", "what should we build first", or any request to build something whose boundaries are fuzzy. Do NOT start building until the cut line is drawn. Do NOT leave what is OUT of scope unstated. Invoke BEFORE design or implementation. Does NOT apply to sequencing already-scoped work (use project-planning) or estimating it (use estimation).

MANDATORY authoring protocol. You MUST invoke this skill when creating a new agent skill (a SKILL.md behavioral protocol) or substantially rewriting one — for any repo or harness that consumes the Agent Skills format. Do NOT write a skill as a reference document. Do NOT publish a skill whose trigger description was never tested against prompts that should NOT fire it. Does NOT apply to ordinary code, docs, prompts, or config — only to authoring skills themselves.

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.

MANDATORY validation. You MUST invoke this skill before presenting any design, plan, architecture decision, or significant recommendation as final. Runs 7 cognitive debiasing checks: inversion, second-order effects, MECE coverage, map vs territory, adversarial, simplicity, and reversibility. Do NOT present conclusions without running all 7 checks. Invoke after brainstorming produces a design, after a plan is drafted, before any irreversible action, or when asked to validate or review an approach.

MANDATORY convergence step. You MUST invoke this skill FIRST — before problem-classification — whenever a non-trivial request's scope or goal could plausibly be read more than one way. Do NOT start substantive work on your own reading of an ambiguous request. Do NOT assume the most reasonable interpretation is the user's. Trivial, unambiguous requests skip this per the using-praxis complexity gate: typo fixes, renames, one-liners, factual questions, running commands.

MANDATORY optimization protocol. You MUST invoke this skill when something works but needs to be faster, cheaper, or smaller — latency reduction, cost cuts, memory limits, throughput targets. Do NOT change code before capturing a baseline measurement that names the actual bottleneck. Do NOT optimize a guessed hot spot. Invoke this BEFORE touching any code on an OPTIMIZE problem.

MANDATORY first step. You MUST invoke this skill before brainstorming, designing, or planning any non-trivial work. Do NOT start asking clarifying questions on your own — this skill's gates ARE the clarifying questions. Invoke when the user asks to build, design, plan, create, architect, or implement anything substantial. Do NOT skip this because the task seems straightforward. Straightforward-seeming tasks with wrong framing produce the most expensive failures.

MANDATORY threat analysis. You MUST invoke this skill before writing or approving ANY code involving authentication, authorization, cryptography, input handling, payment processing, PII, secrets management, API endpoints, or trust boundaries. Do NOT write security-sensitive code without running STRIDE analysis first. Do NOT say you will add security later. Auth is a design decision, not a feature to bolt on.

MANDATORY strategic analysis. You MUST invoke this skill for business decisions, product strategy, competitive analysis, roadmap prioritization, or any decision about WHAT to build rather than HOW to build it. Do NOT skip SWOT analysis. Do NOT present strategy without measurable OKRs. Invoke when the problem is about direction, positioning, or priorities rather than implementation.

MANDATORY test design protocol. You MUST invoke this skill before writing tests for new code, deciding test scope for a feature, or declaring any bug fixed. Do NOT chase coverage percentages. Do NOT call a bug fixed without a regression test that fails on the old code. Invoke this BEFORE writing the first test, not after the suite exists.