Keep the project's purpose, direction, constraints, current understanding, and next important question available to later sessions. A project is an objective, not necessarily a Git repository. Its code, data, experiments, documents, and live jobs may span several locations.
Recover the context
Inspect the existing intent document, project instructions, relevant decisions, current results, and resource locations. Reuse an equivalent maintained document instead of introducing a competing PROJECT.md. Ask only for missing user judgments that materially change the setup.
Separate user decisions from observations and agent proposals. Preserve the user's wording for goals and important limits where available; a useful synthesis may connect those statements without upgrading an inference into consent. Do not require a failure anecdote, a fixed number of pillars, or a negated definition for every goal.
Write the smallest useful project record
Use PROJECT.md, or the project's existing equivalent, for two kinds of content:
- User-owned direction: why the work matters, the question or outcome being pursued, priorities, meaningful exclusions, constraints, and the choices the user has settled. Mark this section clearly. A change of direction needs the user's decision; a previously accepted grant does not need repeating.
- Maintained understanding: what the work currently supports, important competing explanations, what has not been established, relevant abandoned approaches and why, the next decision, and links to the results that matter. Update this digest during authorized work without asking the user to approve every observation. Findings may challenge a decision; they do not silently replace it.
Give each material decision a concise reason and its source. Supersede outdated entries rather than making an old result look current. Record uncertainty where it affects the next action, not as a mandatory label on every sentence.
Map authoritative code, datasets, experiment records, documents, and remote resources only as needed to retrieve them. Reuse existing run registries, research indexes, and notebooks. Keep raw results in their own locations and link them; PROJECT.md is not a second experiment database.
State how progress is assessed for this project. This may be a working capability, a defensible finding, an excluded explanation, an evaluated dataset, a useful artifact, or a documented limit on what can be concluded. Test and lint requirements belong here when they apply to the project's implementation.
Connect later sessions
For an installation request, update the project's existing instruction entry points to locate the project record and consult it for consequential decisions and continuation. Preserve unrelated instructions and terminology pointers. Where the project uses both AGENTS.md and CLAUDE.md, maintain its supported shared-instruction bridge; do not promise that one file is automatically read by every harness.
When the project has or wants a terminology index, add curate-terminology's project instruction snippet to the instruction entry point. Link the canonical terminology index rather than copying definitions. Do not add universal writing defaults or an unrelated glossary survey.
An explicitly requested setup may create missing instruction files. An audit reports missing or stale wiring without changing it. A multi-repository project can keep its project record at an agreed workspace or research root and link it from participating repositories.
Audit and finish
Check whether the next session can locate the record, retrieve decisive sources, and distinguish established direction from current hypotheses. Compare the digest with actual results and live state where relevant. Git is one persistence mechanism; an uncommitted file is not automatically invalid, and a commit alone does not make a record accessible on another machine. Check actual storage, synchronization, access, and retention arrangements.
Deliver the updated record or audit findings and the next useful action. Do not require a plan, commit, or another interview merely to finish setup. When planning was also requested, continue through gigio-write-plan using established intent. Sufficient existing context does not need this setup process again.