// Guide
Share CLAUDE.md and AGENTS.md across a team
A team can share agent instructions through Git. Commit the project file, review changes in a pull request, and make sure each teammate has the current version. When people outside the repository must review shared policies or plans, use a document review process alongside the repository.
The file name tells a tool where to find instructions. Your team still needs to decide who owns the content, who approves changes, and how teammates receive the approved version.
Choose the file your tool reads
CLAUDE.md holds project instructions for Claude Code. Current Claude Code documentation also supports AGENTS.md directly in version 2.1.277 and later. By default, an existing CLAUDE.md or CLAUDE.local.md in the working directory or above it takes priority over direct AGENTS.md discovery. Check the installed version and its Project instructions setting before choosing a layout. Claude Code documentation
Codex reads AGENTS.md before work starts. It combines global guidance with project guidance from the repository root down to the working directory. A more specific file can change the instructions for that part of the project. Codex documentation
For a team using both tools, start with one short repository-level AGENTS.md where the installed clients support it. Use a CLAUDE.md wrapper when the Claude environment needs one. Keep shared rules in one place and keep tool-specific rules separate. Confirm which files loaded in a fresh session.
Keep repository instructions in Git
Repository instructions should contain facts that a contributor needs for the current checkout. Include the build command, required checks, code conventions, and paths to relevant documentation. Use a normal pull request to change them.
Assign a reviewer to the instruction file. When a command changes, update the file in the same pull request as the command. Ask a second teammate to start a session from a clean checkout and confirm that the instructions name commands and paths that exist.
For one repository and a team comfortable with Git, this process may be sufficient. Adding another system does not replace code review or branch protection.
Keep shared business context in a reviewed document
A launch plan or company policy can have reviewers who do not use Git. ArtifactBridge gives those reviewers a browser view of proposed document changes. For governed documents, an agent proposes an edit and a person decides whether it becomes the next version. Approved managed-document changes retain attribution and version history. Review agent changes
Use the repository file for instructions about the checkout. Use a governed document for shared material that needs browser review. Keep a clear reference between them. Do not paste a large company handbook into every agent instruction file.
Connect the agent through the ArtifactBridge command-line interface or Model Context Protocol server URL. Model Context Protocol is the protocol that lets a connected agent use the workspace tools. The endpoint is https://app.artifactbridge.com/mcp. Connection instructions
Ask the agent to read the current approved document before a task that depends on it. Ask it to cite the document and version it used. A copied instruction file does not update itself when a shared document changes.
Review a change across two teammates
Use this sequence for a first trial:
- Put one small team policy in a governed managed document. Name its owner and reviewer.
- Ask one connected agent to read it and propose a specific edit.
- Have a second teammate read the diff in the browser. The teammate approves it or requests changes.
- Start a new task with another connected agent. Ask it to read and cite the current approved version.
- If the policy also belongs in a repository file, prepare a separate pull request for that file. Review the diff before merging it.
For repeatable procedures, ArtifactBridge's Skill Hub holds versioned skills that teammates and agents can install. Check the installed version when a procedure changes. Share Skills
Try a specific policy change
This practice example uses sample instructions. Use it to repeat the review process with your team. The completed sample run below records what we verified; it is not a customer result. Download the policy, proposed edit, and review prompts.
1. Create the starting policy
Create a governed managed document titled Team context review policy. Choose its owner and reviewer. Use this starting text:
# Team context review policy
Before a task, read the team's approved launch checklist.
Propose changes to governed documents for human review.
2. Ask an agent to propose one edit
Ask a connected agent to read the current version and propose the following change. The change makes the version used by the agent visible to the next teammate.
- Before a task, read the team's approved launch checklist.
+ Before a task, read the current approved launch checklist. Cite its document link and version in the task handoff.
The reviewer must confirm that the new rule applies to the team's work. The reviewer can approve it or request a revision. A pending proposal is not an approved policy.
3. Check the result with a second agent
After the reviewer approves the proposal, start a new task with another connected agent. Use this prompt:
Read the current approved Team context review policy.
Give its document link and version.
State the launch-checklist rule from that version.
If the proposed rule is still pending, report that status.
Compare the agent's citation with the document's current approved version in the browser. Record the proposal link, reviewer decision, and resulting version in the task handoff. If the reviewer requests changes, record that result and revise the proposal. Do not label it approved.
If this rule also belongs in AGENTS.md or CLAUDE.md, prepare a separate repository change. Review and merge that change through the team's Git process. A document approval does not update a repository file.
Verified practice run: a second agent read version 2
On October 15, 2026, we ran this exercise with a sample governed document in ArtifactBridge. One Codex agent proposed the edit above. The product owner accepted the proposal. A separate Codex agent then read the current document and the exact accepted version through ArtifactBridge's workspace tools. Both reads returned version 2 with the same content hash.
- Before review: version 1 contained the starting launch-checklist rule.
- Human decision: the proposal was accepted at , creating version 2.
- Separate agent check: the second agent retrieved version 2 and quoted the approved rule shown below.
Before a task, read the current approved launch checklist. Cite its document link and version in the task handoff.
Download the approved sample policy, version 2. The verification record contains the accepted version identifier, SHA-256 content hash, review time, and check method. The policy download preserves the document text so its hash can be compared with the record.
This check confirms that a separate agent retrieved the accepted version in this workspace. It does not test another account or client, later task compliance, or changes to repository instruction files. The sample contains no customer data. Repeat the exercise in your own workspace to check your connection and review settings.
Use a team context checklist
Download the team context review checklist.
Copy this checklist into the shared document. Replace each bracketed field with a real value.
## Team context review
- Owner: [person responsible for the content]
- Reviewer: [person who can approve a change]
- Scope: [teams and tasks that use this document]
- Approved document: [workspace document link]
- Approved version: [version number]
- Repository instructions: [path and commit, if applicable]
- Update process: [how readers receive an approved change]
Before work starts, read the current approved version and cite it.
If a rule conflicts with the task, identify the conflict before changing shared content.
Propose governed-document edits for human review.
Review repository instruction changes through the repository's pull request process.
Check the limits of instruction files
An instruction file guides an agent. It does not enforce every action. Use the client's permissions and the repository's controls for actions that must be blocked. Claude Code distinguishes instruction text from enforced settings. Claude Code documentation
In ArtifactBridge, a governed document and a working document can have different write rules. Confirm the document's review settings before relying on an approval requirement. How approval works
Start with one shared policy
Create a workspace, connect an agent, and test the review process with one policy and two teammates. Start with ArtifactBridge
Free while in beta. Team pricing arrives later and will be announced in advance.