> For the complete documentation index, see [llms.txt](https://www.lightward.guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.lightward.guide/product/3-save/3b-push.md).

# 3b. Push the update

Recording the context is good. If gameplay is gonna continue in someone else's hands, decide what qualifies as [active context](/product/1-load.md#active-context), and push it to the next player.

## Documentation-free email

We send a lot of email. Documentation belongs in public, where it can be re-used. It doesn't belong in email. If you're creating new information, [record](/product/3-save/3a-record.md) it [publicly](/publishing.md), and link to it in your email.

If you find yourself writing a long paragraph in your email, or annotating [screenshots](/technical/screenshots.md) to add to the email, switch gears and [put it in the docs](/product/3-save/3a-record.md) instead.

There are reasons for this!

* Keeping it DRY (Don't Repeat Yourself - it's a programming thing). You (or someone) already wrote out the answer once in the docs, so don't write it again. If you find yourself tempted to rewrite it for the customer, scratch that itch by updating/improving/expanding/reorganizing the documentation itself instead.
* Sending a documentation link reinforces the idea that The Docs are the place to go for authoritative information, teaching the user that they can go get help on their own timeline without having to wait and talk to us.
* Sending them to our docs creates a chance that they'll discover additional useful information while they're there.
* The more you do this, the less often you'll have to do it. (Don't think about that too hard.)
* Reading is hard! Every word you add to your email increases the risk of the reader missing a detail.

### Example

```
[greeting]

[brief brief brief BRIEF summary of actions taken]

[documentation links (3 max)]

[asks (3 max, but 1 is best)]

[sign-off]
```

For example:

> Hey there,
>
> I looked into it, and wasn't able to fully address \[the thing]. However, I did \[the other thing], which helped in \[these ways].
>
> You can learn more about this here:
>
> * <https://example.com/here-is-some-documentation>
>
> If you'd like me to dig in further, please send me \[the things I need in order to continue].
>
> Thanks,
>
> \[me]


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.lightward.guide/product/3-save/3b-push.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.