Design the system before building it: module boundaries, data model, integration contracts, environments, threat model. Use after stack choice and before the first build session, and again when a change would cross or move a boundary. Produces docs/product/ARCHITECTURE.md and decision records.
Start a project on Groundwork. Use when docs/state/STATE.md says NOT STARTED, when the user says "begin", "start", "nieuw project", or asks how to get going in an empty copy - also when they lay Groundwork over a project that already exists (adopt, retrofit, brownfield), and when they open with an existing PRD…
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…
Flush a lean mid-session handoff into STATE.md so you can clear the context and resume the same work in a fresh, cheap session. Load when one chat session has used roughly 15% of the context window (the activation point; past 40% it is urgent), when the session feels long or slow, or when the user says "checkpoint"…
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…
Compliance review against Dutch and EU law: GDPR/AVG, EU AI Act, accessibility (EAA/WCAG), NIS2, CRA, licensing. Use at project start (begin flags it), before first delivery, when new personal-data or AI processing is added, and at the quarterly audit. Verifies current rules against authoritative sources, never from…
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…
Systematic debugging when a failure's cause is unknown: reproduce first, isolate, fix the root cause once, prove it with a regression test. Use when a bug, crash, failing test or wrong output has no obvious cause, when a fix attempt did not work, or before claiming a stubborn bug fixed. For production incidents…
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.
Judgment check before delivering user-facing output the installed design method does not carry: generated documents, e-mails, exports, error and CLI output, and interfaces on platforms it has no guidance for (game engines, console, embedded, print). For a frontend it re-checks the render against its direction contract…
Stand up this project's design system and voice, and run the making of an interface through impeccable, the installed design method. Covers brand intake, the UI foundation choice (component library or bespoke), voice and wording, and the owner's three decision points: the visual direction, the rendered compositions…
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.
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…
Keep a shipped product healthy: monitoring, updates, incidents, debt, periodic audits, retirement. Use after first production release, on a maintenance session, when dependencies need updating, when something broke in production, to harvest defer: markers into the debt ledger, or when a product, environment or…
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.
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.
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.
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).
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…
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.
Instructions for Tradebaas/Groundwork, covering groundwork: the operating system for this project, session protocol, decision ladder: run before writing anything, hard rules and efficiency.