Tradebaas

calibrate

Pick the model and effort level for a work session BEFORE it starts, matched to the work planned and to token cost. Load when the user asks which model or effort to use, says "which model", "calibrate", "pick a model", "effort", or describes the next session's work and wants the cheapest setup that will finish it in one pass. Never for switching mid-session; the prompt cache is per model, so a mid-session switch re-reads the whole history at full price.

Code & Development Listed

code-review

Review the diff of substantial work before it is committed, after `verify` has passed. A gate-weakening scan first, then two always-on review axes with fresh eyes (standards conformance, and spec plus commit-message fidelity), plus a security axis that fires only on auth, payments, PII, external input, crypto or uploads, each reported by severity and never merged into one list. Use before committing any change bigger than a trivial fix.

critical-thinking

Think hard about an idea, plan, or decision before committing to build it - the counterweight to AI's built-in pull toward agreeing, praising, and building whatever is asked. Load when the user proposes a solution, feature, approach, or "wouldn't it be great if", when begin's challenge step hands over a fresh product idea, when weighing options in scope/spec/architect/design, and any time you notice yourself about to agree enthusiastically or open with praise. Forces a named alternative, surfaces the load-bearing assumption, separates preference from requirement, and asks what would prove the idea wrong - then commits to the user's call. The judgment layer at the entrance to building; mirror of scope-guard at the exit.

deliver

Release, deploy, or hand over a milestone in a disciplined, repeatable way. Use when shipping to users, deploying to an environment, tagging a release, or closing out a milestone. Nothing ships that verify hasn't passed.

Data & Documents Listed

ingest

Convert non-Markdown source files (PDF, Word, PowerPoint, Excel, images, audio, HTML, CSV/JSON/XML, ZIP, EPub) to Markdown with Microsoft markitdown before reading them, so tokens are spent on content and not on binary bulk. Use when a task needs the contents of such a file, when adding reference material to docs/design/reference or a spec, or when the product itself must parse uploaded documents at runtime.

scope

Define, sharpen, or change project scope, and triage docs/state/INTAKE.md. Use when scope is unclear or contested, when new wishes/feedback arrive, when the owner asks for "more" mid-build, or when work doesn't trace to BRIEF.md. Scope changes only happen here, never silently during a build task.

API & Backend Listed

skill-author

Create a new project-fitting skill correctly, or decide that none is needed. Use when the project repeatedly needs expert guidance the existing skills don't carry, when the user asks for a new skill, or when the same correction has been given three times.

spec

Right-size and write the spec before building any change. Use before starting non-trivial work, when the user requests a feature, or when deciding whether something needs a spec at all. Prevents both drift (building unspecified things) and ceremony (specs for bugfixes).

stack

Choose the tech stack or target platform and make the project idiomatic for it. Covers classic code stacks and hosted/low-code platforms alike (own servers, Microsoft Power Platform/Dataverse, ServiceNow, Salesforce, Google, or whatever exists by then). Use when the target platform/stack must be decided, when generating docs/standards/<stack>.md, or when wiring stack-specific quality gates into CI and hooks. Requires live research. Never stack facts from model memory.

verify

Prove a change actually works before it counts as done. Use after building any non-trivial change, before deliver, and whenever claiming something works. Exercises real behavior end-to-end. Green tools alone are not verification.

handover

Make the project fully transferable to another human or agent with zero verbal context. Use at milestones, before breaks, when a new person/tool joins, or when the owner asks "can someone else take this over?". Also the end-of-session discipline when significant work happened.

scope-guard

Judgment check before calling substantial work done or proposing a commit. Use before "done", before committing more than a trivial change, and whenever you notice yourself building something nobody asked for. The judgment layer above the automated gates, not a duplicate of them.