Use the RAPID toolkit

The handbook explains what RAPID requires and why. The toolkit contains the operational artefacts you instantiate or an agent loads verbatim. This page joins the two: start with the job in front of you, then open the smallest useful bundle.

Pick the right kind of artefact

If you need to…	Use	What it gives you
Decide whether work may move forward	Gate card	Checklist, evidence, owner, automation and waiver rules
Create a durable delivery output	Template	Fillable structure for a PFD, ADR, runbook, design pack or evidence pack
Give an agent one bounded job	Prompt	Versioned instructions with a defined input and output contract
Invoke a repeatable capability	Skill spec	Behaviour, checks and golden-test intent for an agent capability
Start a product in the right shape	Project scaffold	Repo context, memory, ADR/runbook directories, CI shape and agent configuration
Choose or challenge technology	Tech radar	Adopt, trial, assess and hold decisions as code
Keep a living risk or signal view	Register	Versioned schema for debt, exceptions, commitments, waivers and market signals
Build capability or measure the system	Training and metrics	Curriculum and measurement foundations

What exists today

Availability and maturity are different. An artefact can be rendered and usable while still awaiting trial evidence, evaluation fixtures or a named approval.

Family	Available	Current maturity
Gate cards	10 + template	Operational v1
Templates	26	Mostly v1; some need Legal, Commercial, DPO or Leadership approval
Prompts	7	Draft 0.1.0
Skill specs	13 + template	Draft specs; golden fixtures and evaluation remain
Registers	8	Schemas available; most populate through STOP activity
Project scaffold	1	Skeleton; no runnable golden-path stack yet
Tech radar	1	Seed data; portfolio evidence still needs to populate it
Training	1	Scaffold
Metrics	1	Scaffold

The 64 core gate cards, templates, prompts, skill specs and register schemas are available to inspect. Catalogue complete does not mean proven. Check the artefact’s front matter and lifecycle before treating it as a default.

Start with the phase you are in

STOP · stabilise before acceleration

Use STOP when the estate is not safe to accelerate. Capture what exists, make debt visible and meet the Definition of Stable before entering the delivery lifecycle.

• Understand the estate: legacy knowledge pack, code archaeology and characterisation tests.
• Make exposure visible: tech-debt, security-debt, test-debt and EOL inventory.
• Plan difficult exceptions: risk acceptance and EOL upgrade prompt.
• Communicate the pause: STOP comms pack.
• Exit: Definition of Stable.

1 · Definition

Turn prioritised evidence and domain insight into a plan an agent can build from.

• Create: PFD, PFD rubric, domain brief, competitive teardown and DPIA where required.
• Direct the agent: PFD first draft.
• Invoke: PFD drafting, PFD review and edge-case red team.
• Exit: Definition of Ready.

2 · Design

Make behaviour, data and key screens explicit so Build does not invent them.

• Create: UX flow, data model, screen spec, design context pack, design handoff pack and test plan.
• Direct the agent: design critique.
• Invoke: design generation.
• Exit: Design Review.

3 · Tech selection

Choose the default-first stack, record the decision and give Build a known starting shape.

• Decide: tech radar and tooling scorecard.
• Record: ADR and stack playbook.
• Invoke: ADR writing and scaffold from radar.
• Exit: Tech Selection sign-off.

4 · Build

Run the director–builder loop inside a repo structure and merge policy that keep changes bounded and reviewable.

• Start from: RAPID project scaffold.
• Direct the agent: task brief, tests from acceptance criteria and ASVS self-review.
• Invoke: test-suite generation, characterisation tests and ADR writing.
• Pass every PR through: Merge gate.

5 · Refinement

Raise acceptable to good through named passes with measurable exit bars.

• Invoke: refactor to standard and security review.
• Check against: the test plan and the relevant handbook standards.
• Exit: Refinement Exit.

6 · Flow-state

Remove friction and deposit capital so the next turn of the loop starts faster.

• Run: Flow-state playbook.
• Capture: runbook, handoff note and the scaffold’s memory/gotcha structure.
• Invoke: runbook generation.
• Measure: metrics framework.
• Exit each release through: Production Readiness.

Dedicated prompt and skill coverage is thinner here than in Definition and Build. Treat that as a visible toolkit gap, not an invitation to invent a local process silently.

7 · Production

Release with security, observability, support and reversal already in place.

• Prove readiness: release evidence pack, runbook and incident comms.
• Prepare the market and support: demo script, beta agreement and release-notes prompt.
• Invoke: release notes.
• Enter: Production Readiness.
• When selling or scaling: GTM Readiness and CXsmart scale-up.

Adoption and operating-model artefacts

These sit around the lifecycle rather than inside one phase:

• Start a pilot: pilot charter, squad charter and Intake gate.
• Review the operating model: operating-model retrospective.
• Capture the commercial signal: signal register and client-commitment register.
• Make waivers explicit: gate-waiver log and security exceptions.

Use an artefact without creating drift

1. Open the rendered page and check the lifecycle, owner and version.
2. Instantiate templates; load prompts and skills verbatim. Do not quietly rewrite their contract inside a product repo.
3. Keep the source link with the instance so a reviewer can see which version governed the work.
4. Attach the evidence to the gate, not to a meeting invite or chat thread.
5. Feed improvements back by PR. Written rules change in the handbook; operational counterparts change in toolkit/.

Need a rule rather than an artefact? Use Standards. Need a procedure? Use Playbooks. Need to change either? Read Contributing.