Inspect the resulting device setup
Connect each requirement to its local evidence.
Open this resource →Workbook · Shared rules
Move a company change into everyday work.
Plan a team baseline update, preserve reviewed resource versions, and check the resulting developer setup.
A company decision becomes useful when a developer receives the intended version. Follow that handover through review, team adoption, and a real task.
01 / Workbook · Shared rules
A Search team prepares its next baseline
Harbor maintains several services. Its Search team owns search-api and uses Claude Code alongside Codex. This situation is illustrative.
The company wants agents to distinguish checked behavior from source edits. Search already has useful repository instructions and wants to keep them.
The rule owner needs to understand the proposed company change before adopting it. Developers need a stable baseline while that evaluation happens.
The useful question is therefore precise: which reviewed company revision should Search use for its next release?
A newer company release can exist while Search continues with its current revision. That gives the team time to assess the change deliberately.
Keep that decision visible. If the baseline changes silently, a later task cannot easily explain why its instructions differ from an earlier session.
02 / Workbook · Shared rules
Understand the configuration relationship
Betterloop gives the organization one rules configuration. Each team also owns one rules configuration. Drafts, reviews, and releases represent its versions.
A team pins a company revision. The pin connects the team's reviewed configuration to a specific company baseline.
Refreshing the pin is an explicit team change. Reviewers can examine the effective result before accepting the new relationship.
Selected resources also have identities and versions. Their file checksums let the release process distinguish reviewed bytes from changed content.
A checksum describes file identity. It does not tell you whether a paragraph gives useful advice or whether an agent applied it correctly.
Keep ownership, file identity, and observed behavior in the evaluation. Each answers a different question about the handover.
03 / Workbook · Shared rules
Collect the inputs before opening a draft
- 01
Identify the owners
Find the company rule owner and the Search team rule owner.
- 02
Record the starting revision
Record the company baseline pinned by the current Search release.
- 03
Choose the review target
Identify the proposed company revision and its selected resource versions.
- 04
Confirm path ownership
Check eligible reviewers for the manifest and selected resource files.
- 05
Prepare a representative task
Choose a small search-api change with a direct observable result.
- 06
Record local conditions
Record the native client version and any personal instructions relevant to the task.
04 / Workbook · Shared rules
Follow the resource through company review
For this exercise, the company proposes Verified change 1.0.0. That skill has a declared dependency on Delivery evidence 1.0.0.
Read both resources before selection. The skill shapes implementation work; its reference helps the agent communicate what the available evidence establishes.
Selection exports the chosen dependency files into the company configuration repository. The resulting files still need the normal review and release process.
Reviewers examine the manifest and resource paths at the proposed Git revision. An earlier review of different bytes cannot establish approval for later edits.
After the approved change merges, the normal signing workflow prepares the company release. Search still has its existing pin at this stage.
The team owner can now open a baseline refresh draft. The effective preview shows the proposed company guidance together with the team's existing requirements.
05 / Workbook · Shared rules
Review the effect on Search
Ask whether the draft preserves instructions that Search still needs. A company update should not make the team forget its repository-specific responsibilities.
Inspect resources and their dependency versions together. A recognizable title alone does not show that the intended release contains the intended supporting files.
If the team proposal introduces executable additions, check the corresponding organization grant at the pinned revision. Content review cannot substitute for that grant.
A change to configuration repository settings does not relocate existing files. Resolve repository incompatibilities before treating selection as ready.
Submit the team draft through its review workflow. Publish the accepted team version only after the required review has covered the final proposed state.
The completed handover now has two reviewable decisions: the company release and Search's adoption of that baseline.
06 / Workbook · Shared rules
Try one task on a connected device
Refresh the developer’s signed state after the team release. Complete any required native trust or session restart before evaluating the change.
npx @betterloop/setup doctor --harness codex --project /path/to/repositoryRead the diagnostic results for team identity, project matching, signed state, and activation. Resolve an ambiguous project choice before requesting project knowledge.
For the example task, change the default sort order of a small search result. Preserve the documented ordering for an explicitly supplied option.
Ask for the expected default order and the preserved explicit order. Use existing repository checks to examine both outcomes.
Read the resulting report beside the actual check output. The new guidance should help the reader distinguish source changes, demonstrated behavior, and release state.
Do not score a report by its length. A short statement with the correct evidence is more useful than a detailed unsupported completion claim.
07 / Workbook · Shared rules
Locate the handover that needs attention
Keep unrelated native plugins and personal settings intact during diagnosis. A targeted problem usually needs a targeted repair.
Change a published resource through a new version when its bytes need revision. Preserve the identity of the content that earlier reviewers accepted.
| What you observe | What to inspect | Useful next step |
|---|---|---|
| Search still uses its earlier rules. | The team pin and published team revision. | Review whether baseline adoption actually occurred. |
| The resource title matches but its version differs. | Selection metadata and the signed release. | Compare exact versions with the accepted draft. |
| The right release appears on the wrong project. | Approved repository mapping and project selection. | Resolve the project identity first. |
| Files exist but the expected boundary never runs. | Native trust, activation, and session state. | Complete activation before retesting behavior. |
| The agent retrieves the guidance but misses the task condition. | Task wording and the resource’s applicability. | Evaluate a focused guidance revision. |
08 / Workbook · Shared rules
Keep repository behavior understandable
Approved project mapping supplies context for repository-specific rules and knowledge. It does not prevent the developer from opening another repository.
Unknown repositories use the reviewed organization behavior. New baselines default to reporting without company rules or knowledge being applied.
An administrator can choose reporting with team defaults instead. Teams inherit that organization choice, so check it when evaluating an unfamiliar repository.
Reports remain client-reported and best effort. Their absence cannot establish that no work occurred or that no different instructions were present.
Record any corrective release with the affected task. Refresh signed state after the correction, then repeat the observation that originally exposed the difference.
Keep the evaluation small until that result is understood. Expansion should follow evidence about the specific handover you changed.
09 / Workbook · Shared rules
Questions during baseline adoption
Can Search keep its current revision during evaluation?
Yes. The team retains its pin until it explicitly adopts another company baseline through its configuration workflow.
Should the team create a second rules profile for the trial?
No. Use a draft version of its one configuration. Drafts and releases are stages of that configuration.
What proves that the new guidance helped?
Inspect the relevant task and actual verification. Resource identity establishes what was supplied, while task evidence establishes the observed result.
Is Mimir required for this process?
No. Evaluate the native Claude Code or Codex setup against the controls your team needs.
10 / Workbook · Shared rules
Write down the adoption decision
Record the adopted company revision, team release, chosen resources, and the task used for evaluation. Include the native agent version that produced the observation.
Name unresolved questions before planning wider use. Another developer should be able to understand what you accepted and which behavior still needs checking.