Put durable context beside the code
A chat can explain a task, but the next collaborator may never see it. Keep lasting decisions in repository files that can be read, reviewed, and updated with the project. Start with a short overview, a contribution rulebook, and the commands that verify a change.
Shared files help tools and people find the same context. Each tool still has its own instruction discovery and precedence behavior. Confirm that the tool reads the relevant files, and check its output against them. Writing a rule does not guarantee compliance.
Reference: For Copilot on GitHub, follow GitHub's repository custom instructions documentation rather than assuming every instruction filename is discovered automatically.
README.md- The project goal, important paths, and local setup.
AGENTS.md- Task scope, working rules, verification, and human approval boundaries.
- Pull request guidance
- Changed behavior, checks, open risks, and the decision needed from the reviewer.
Example handoff
One tool starts a CSV export. Another continues it.
The first session adds an export button. The next session should know which columns are allowed, where the export code lives, and how to check the output. A useful instruction is concrete: “Keep the export limited to the approved columns. Follow the existing permission checks. Report the changed files and the checks run before requesting a merge.”
Keep actual customer data, tokens, and environment values out of these files. Record the data boundary and use an appropriate test fixture. When the accepted behavior changes, update the instructions in the same reviewed change so the next session gets current context.
Try a small rulebook before expanding it
An illustrative starting point for the CSV handoff is:
- Goal
- Export only approved columns, using synthetic rows for checks.
- Scope
- Follow the existing export path and preserve permission checks. Unrelated authentication or checkout changes need a separate decision.
- Before editing
- Identify the applicable instruction files and the repository's verification commands.
- After editing
- Report changed files, checks passed, failed or not run, open risks, and one next action.
- Approval
- Do not merge, deploy, or contact external services without approval.
Adapt this example to your repository and configure instruction discovery for the tool you use. Start a fresh session with a read-only question: where does the export live, which columns are allowed, and how is it checked? Compare the answer's references with the actual files. A plausible summary alone does not prove that future changes will follow the rules.
Check whether your rulebook is usable
- Make the task boundary explicit. Name the outcome and the areas that need a separate decision.
- Write runnable checks. Use the repository's actual commands and state when they apply.
- Assign approval. Identify who decides about merge, deployment, and external actions.
- Leave a useful handoff. Include changed files, evidence, unresolved risks, and one next action.
- Maintain the instructions. Review them when behavior, tooling, or responsibilities change.
A foundation you can review and adapt
Founder Repo OS is a product by SUPPE LABS. Guided project inputs inform the generated repository foundation, including plain AI-agent instructions and review guidance. Pro adds governance, a decision rhythm, and release and handoff documents. The setup guidance covers Codex, Claude Code, GitHub Copilot, Cursor, and comparable repository workflows.
Its own six-step setup leads from access and repository connection through scan, configuration, full-diff review, and an approved setup branch with a draft pull request. You control the merge. The installed files are operating guidance, not a service that supervises all your AI sessions or changes tool permissions. Use them with your existing review process and configured repository controls.