> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/gea/start-here/how-to-use-the-plays.md).
# How to use the plays
The mechanics of a play β what it is, what input it needs, and the rhythm of running one. Read once, apply in all four Knowledge Products.
Every subtopic in every Knowledge Product ends with a **play**: a prompt you run in an AI assistant against your own country's context, a worked example on Progressa, and an annotated reading of the result. This page is the mechanics. The trust rules are next door on [Working with AI](/experience-digital-transformation/gea/start-here/working-with-ai-the-ground-rules.md); the prompt shape is on [Prompting techniques](/experience-digital-transformation/gea/start-here/prompting-techniques.md).
## What a play is β and is not
A play is not content to be shown. It is something you *do*. The video gives you the concept and the motivation; the play is where your own situation enters, and the learning happens in the back-and-forth with the assistant and in judging what it produced. Watching someone else paste a prompt teaches nothing; reading an output the way an architect would teaches a lot. That is why every *completed* play page has a **Reading the output** tab, and why it is the longest one.
## The three kinds
Each play carries a kind badge so you know what to bring:
| Badge | Kind | You bring | You get |
| ----- | --------------- | --------------------------------------------- | -------------------------------------------- |
| π | **Diagnostic** | 1β3 paragraphs describing your situation | An assessment with evidence and gaps |
| βοΈ | **Drafting** | A few facts β posts, institutions, programmes | A first draft of a document you will edit |
| π | **Translation** | A question in one group's language | The same question restated for another group |
## What the box at the top of each play tells you
Every play opens with the same six-line box. It is the whole contract:
| Line | Means |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Kind Β· artefact** | which badge, and which numbered artefact the play adds to your workbook |
| **Bring** | the input, and which section of A0 it comes from |
| **Get** | the output shape β always text, so it can feed the next play |
| **Time** | how long the run takes, including reading the result |
| **With the kit** | the optional [ea-plays](/experience-digital-transformation/gea/start-here/the-ea-plays-kit.md) skill for this play; ignore it if you are not using Claude |
| **Watch for** | the one specific way *this* play can mislead you |
## The rhythm: build the input, then run the play
Every play asks you to paste context β a landscape brief, a programme list, a roles register. You will not have it to hand. In practice each play is two steps: first a research prompt that builds the input from public sources, then the play itself. The research prompts are collected on one page, [Play 0 β Build your country context](/experience-digital-transformation/gea/start-here/play-0-build-your-country-context.md); run it once and the **country context pack (A0)** feeds every play in every module.
## Five habits from the test runs
**Text in, text out.** Ask for the output as text in the chat β not a file, a screenshot or a chart. A table trapped in an image cannot be pasted into the next play; a .docx cannot be read by the assistant that runs 1.7 after 1.6.
**Expect clarifying questions.** Some plays (tool selection, cost cases) will ask you two or three questions before answering β repository size, budget posture. Answer them and record the answers with the input; they are part of the artefact.
**Strip the assistant's reasoning before you paste.** "The search confirms⦠let me produce the table" is the model talking to itself. Cut it before the output becomes the next input.
**Posts, not names.** Context prompts pull real office-holders' names from the web. The plays need posts; remove names before an artefact goes into a briefing or onto a shared page.
**Shorten the brackets.** The bracketed placeholders are suggestions. "For an Education minister in \[country X]" works as well as the full list β a leaner prompt with your real context beats a complete template with none.
## How the plays chain
The plays are not a prompt library. In each module the outputs feed each other β the fragmentation diagnostic feeds the business case, the RACI feeds the Board terms of reference β and a learner who runs a whole module leaves with a set of artefacts about their own country. The chain is written out in each Knowledge Product's workbook: for *Developing a Gov Enterprise Architecture (GEA)* it is [Your country workbook](/experience-digital-transformation/gea/your-country-workbook.md). If you have no country to hand (a student, a donor analyst), run the plays on [**Progressa**](/experience-digital-transformation/gea/start-here/progressa-the-demonstration-country.md), the fictional demonstration country used in every Knowledge Product; the worked examples show you what to expect.
π The ea-plays kit
The optional Claude layer: sixteen skills in two plugins.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/gea/start-here/how-to-use-the-plays.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.