AI forgetting your project? Build a short context package

Instead of "continue" — a clear work state

You open a new chat, ask to finish a website — and get a different design, an extra feature, or a broken login. Often, the assistant doesn't lack a beautiful prompt, but facts: what has already been done, what cannot be changed, and how to verify the result.

A context package is a short document that provides this support. It doesn't add memory to the model and doesn't guarantee correct code. Its task is to reduce the number of assumptions that will need to be fixed.

What to leave in the document

Describe the goal through a user action: "a visitor finds a service and sends a request." Next — current state, the single next change, technical boundaries, and criteria. If the immutability of registration is important, write it directly and name the scenarios that need to be re-verified.

Anthropic describes context engineering as working with information available to the model at the moment of task execution. Useful context is not just a longer history: you need to select relevant instructions, data, and results. Our template below adapts this principle to a small author project.

PROJECT CONTEXT PACKAGE Goal: [one result for the user] Current state: [what is already working] Environment: [technologies/browser/limitations] Task for this step: [one change] Do not change: [working scenarios] Relevant files or fragments: [only what is needed] Acceptance criteria: [3–5 observable checks] Data: [fictional or anonymized examples] Before working: name the gap and important assumptions. After working: show changes, performed checks, and what could not be verified. Do not declare a test passed if you did not run it.

Example: add FAQ without breaking the request

Goal — to help the visitor understand the repair terms. Current state — a single-page website with a working form. Next change — four questions, answers revealed on click. Do not change — the submission address, form fields, and its success message.

Criteria: all questions are accessible via keyboard; text does not overflow the screen; the form can be filled after opening the FAQ; if JavaScript fails to load, answers can still be read. These are specific observations that are easier to verify than a general "make it convenient."

What not to pass

Do not add passwords, API keys, private client correspondence, or full user databases. For a form error, an anonymized example and the error text are sufficient. If the file is large, start with a description of the structure and a relevant fragment; do not cut out dependencies without which the behavior is incomprehensible.

In projects with file access, you can specify specific paths to the assistant. In a regular chat, provide the necessary fragments yourself. Do not claim a file is available to the agent if you haven't uploaded it or provided the appropriate access.

Close each session with a brief handoff

Ask to record: what changed, which checks were performed, which remain, and what the next step is. Reread the summary: an error in it will become false context for the next conversation. Mark decisions with a date, and remove canceled requirements or explicitly mark them as outdated.

If the agent says "checked on phone," ask them to specify the environment and scenario. A CSS change is not proof of a browser test. Such a summary allows work to continue without exaggerated reports.

Where to store

For a small project, a text file next to the code is enough. If you are working with Git, save its versions along with the changes. Separate stable rules from a temporary to-do list. Before the next task, update the document: an outdated package can hinder more than it helps.

Source and next step

Anthropic: Effective context engineering for AI agents. Template and FAQ example prepared by the editorial team. Now check agent access or turn the scope of work into estimate and tasks.