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.