Shared team context for coding agents

Give each kind of context a clear home

Consider a team adding a timezone selector to a reporting dashboard. The agent needs to know which date library to use, how to verify a report, and where the current reporting schema lives. It also needs the product decision about whether timezone changes affect scheduled emails. Those facts have different owners and lifetimes.

This is an illustrative division of context. Adapt the names to your tools, but avoid copying everything into every location. Conflicting copies force the agent to choose which instruction to believe, and make it harder for a maintainer to fix the source.

Write rules that someone can act on

A useful repository rule names the constraint and where to verify it. "Keep dates consistent" leaves too much interpretation. "Use the shared date formatting helper in the reports package; do not format report timestamps in individual components" gives the contributor a next step.

Include the setup and check commands that repeatedly matter. Link to longer architecture explanations when the reason for a rule needs space. Remove instructions for deleted packages in the change that deletes them. An old command can waste an entire attempt before someone realizes the guidance is wrong.

Uno supports repository rules for conventions and architectural boundaries. Its rules and skills guide recommends concise, current instructions that point to the source of truth. Keep one-off product decisions in the task until the team decides they should become lasting policy.

Make a skill a procedure with a stopping point

A reporting-verification skill could tell an agent how to load fixture data, run the app, inspect dates around midnight, and compare the result with the requested timezone. It should say what evidence to return and what to do when the fixture cannot start. "Test thoroughly" cannot replace that procedure.

Keep the skill scoped to the tasks it helps. The date-formatting workflow has little value in a dependency-only change. Anthropic's context engineering guidance treats context as a finite resource that needs curation across an agent's run. Loading relevant guidance when it is needed is a useful consequence of that model. See Anthropic's explanation.

Version procedures with the code they describe where practical. Review changes to the procedure when the app's startup command or fixture data changes. A skill that depends on an unavailable service should return a clear limitation and leave the acceptance decision to the task owner.

Use MCP for access to capabilities and current facts

MCP servers can expose tools, resources, and prompt templates. Tools perform defined operations; resources supply context; prompts provide reusable instructions. The protocol describes how applications discover and use those capabilities. See the MCP server concepts guide.

A connection to an issue tracker can supply the latest acceptance criteria. It does not resolve a disagreement between the issue and an engineer's instruction. Give the task a decision owner and record the resolution. Similarly, a tool that can modify a service needs an access policy appropriate to that operation.

Test a connection with the kind of request the task will actually make. A listed server may still lack the relevant tool or permission. Uno's workspace MCP guide explains how external tools fit into a workspace. Add connections because a task needs them, and inspect what each one permits.

Hand over the state another contributor needs

When another agent or engineer takes over the timezone task, retain the starting point and the current patch revision. State which behavior is complete, what was checked, and which decision remains open. Link to the source of a decision instead of passing along an unattributed summary.

Goal: display report dates in the selected timezone.
Decision: scheduled emails retain their current behavior; see the task discussion.
Current patch: link to the branch and commit.
Verified: fixture rows around midnight display the expected calendar date.
Unverified: saved preference after a fresh sign-in; test account unavailable.
Next action: restore the test account, then check persistence before review.

A handoff is a claim about the work. The next contributor should inspect the patch and rerun affected checks when it changes. Keep a missing verification step visible; a concise summary should not turn partial evidence into a completed task.

Repair context where the mistake began

If agents repeatedly select the wrong date library, check whether the rule names the right helper and whether that helper still exists. If they understand the rule but cannot run the fixture, repair the environment or skill. More instructions will not resolve a missing test account.

Ask a teammate to start the next reporting task using only the shared material. Note what they have to ask you privately. Move reusable answers to their proper source and leave task-specific judgment with the task. That exercise exposes context gaps before several agents repeat them at once.