Packs

Design context

What a design project needs an agent to read before it touches anything: the system, the accessibility floor it is held to, and where the work stops.

3 of these have fill-in fields. This pre-built archive ships them unfilled, because it is generated once for everyone. To get copies with your own values already in place — asked once per field, applied across every document that uses it — build this selection yourself.

Download 3 documents + MANIFEST

Contents

MANIFEST.md

Shipped inside the archive. Reproduced here so you can read it before downloading.

# Design context

What a design project needs an agent to read before it touches anything: the system, the accessibility floor it is held to, and where the work stops.

Source: https://the-handover.org/packs/design-context
Built: 2026-09-19
Documents: 3
Licence: Handover-1.0 (© Captivated Ltd) — https://the-handover.org/licence

## What this pack assumes

A design project with a token set, or the intention to have one. No repository required — a folder is enough. Three fields are shared across the set, so you answer each once.

## Fill-in placeholders

3 document(s) in this pack contain placeholders that have not been
filled in. They are written as double braces and are safe to leave — but they are
meant to be replaced with values for your project.

Either replace them by hand using the list below, or rebuild this selection at
https://the-handover.org/build, which asks once per field and applies each answer across every
document that uses it.

- docs/design-system-context.md
    {{tokens_path}} — Design tokens source of truth
    {{accessibility_standard}} — Accessibility standard
- docs/accessibility-commitment.md
    {{accessibility_standard}} — Accessibility standard
    {{assistive_tech_support}} — Assistive technology commitment
- docs/design-working-agreement.md
    {{tokens_path}} — Design tokens source of truth
    {{accessibility_standard}} — Accessibility standard
    {{ships_via}} — How a design change reaches a user, and who decides

## Contents

### docs/design-system-context.md

Title: Design system context for an agent building interfaces
Summary: Why an agent drifts a visual language one plausible value at a time, and the rules that stop it.
Authors: Leon Mallett, Founder of Captivated Ltd (captivated.online)
Source: https://the-handover.org/docs/design-system-context
Last confirmed working: 2026-08-15
SHA-256: 79506fce319d41163205ff3c5b309e01599e49f22c6c7f460da6087890e945f4

### docs/accessibility-commitment.md

Title: Accessibility for an agent building and testing interfaces
Summary: The conformance level, what gets verified and how, and the failures an agent introduces without noticing.
Authors: Leon Mallett, Founder of Captivated Ltd (captivated.online)
Source: https://the-handover.org/docs/accessibility-commitment
Last confirmed working: 2026-08-21
SHA-256: f2bae6c2e5b194878f56920f68f53dc8a29b4046ec04e7e517d3e373e9da24ff

### docs/design-working-agreement.md

Title: A design working agreement: propose, and do not ship
Summary: What an agent may change in a design system unattended, where it must stop, and how to tell a problem of taste from a problem of structure before spending a day on the wrong one.
Authors: Leon Mallett, Founder of Captivated Ltd (captivated.online)
Source: https://the-handover.org/docs/design-working-agreement
Last confirmed working: 2026-08-30
SHA-256: 9b0311a53ca5ff5a3e4e772e4eae5938b4c59feda8348c41db13e2e94f46623d

## Licence and attribution

Copyright is retained by the authors and Captivated Ltd. You may use these
documents in your own projects — private, public, commercial, client work —
and adapt them to fit. What is reserved is republishing the collection as a
collection: mirrors, or catalogues assembled out of these documents.

Each file carries an attribution header naming its authors, its source and the
date it was last confirmed. Keep it: once a file has been separated from this
pack, that header is the only thing that still credits the person who wrote it.

## Verifying this pack

Each SHA-256 above is of that file exactly as it appears in this archive. Verify one
with `shasum -a 256 <file>`; a file whose hash does not match was modified after
packaging.

Document files are byte-reproducible: the same source document, at the same
confirmation state, always produces the same bytes. The archive as a whole is not,
because this manifest records the build date above — two builds on different days
differ in that line and therefore in the archive, while every document file inside
stays identical. The per-file hashes are the thing to check.