Selected skill delivery
Authenticated retrieval supplies the reviewed instructions. It cannot guarantee adherence or exclude all unmanaged skills available elsewhere.
Comparison · action boundaries
Decide what needs an instruction and what needs a check.
Design requirements around reviewed guidance, conditional native gates, and supported runtime controls.
Some requirements need an agent to interpret instructions. Others need a check at a named operation. Betterloop keeps those responsibilities visible when resources are selected and reviewed.
01 / Comparison · action boundaries
Specify the behavior before selecting the resource
A skill can explain when a workflow applies, how to approach the work, and which result to check. Its usefulness depends on the agent interpreting and following that content.
An action gate evaluates an operation at a supported event. Its ability to restrict that operation comes from the implemented boundary. Client version, mapping, native behavior, and activation still matter.
Signing authenticates selected content. It does not give prose an interception point or make an unsupported event available. A signed hook also needs the event where it can actually run.
Write the desired action in testable terms. Requiring a procedure in policy describes intent; it does not establish technical coverage. Reviewers should be able to name the evidence for the stated effect.
02 / Comparison · action boundaries
Four support categories to distinguish
| Support category | What the integration supplies | Condition to keep visible |
|---|---|---|
| Guidance | Approved instructional content made available to the agent | Delivery cannot guarantee model adherence |
| Conditional control | A native adapter check for an implemented event | Its effect depends on native coverage, trusted hooks, and required setup |
| Supported runtime control | A policy check performed within the enrolled runtime | The stated runtime, release, and operation define its scope |
| Unsupported | No implemented check for the requested requirement | Changing policy wording does not add adapter functionality |
03 / Comparison · action boundaries
Example: separate review advice from an operation restriction
This hypothetical team wants agents to inspect repository conventions before editing files. It also wants a particular tool operation restricted. The team writes two requirements because the effects need different evidence.
A reviewed skill can explain the convention checks and relevant sources. It can help an agent choose a sensible sequence. The reviewer tests whether that guidance is useful on representative tasks.
For the restricted operation, the reviewer checks adapter support and its event mapping. The developer completes native trust, then tests permitted and restricted inputs. Merely retrieving the skill would not exercise that gate.
The team may add a deterministic script for a repeatable check. A passing candidate receipt identifies the selected command and candidate bytes. It does not make an inadequate test comprehensive.
The resulting evaluation has three records: delivered guidance, an observed operation decision, and task acceptance. These can succeed or fail independently. Their corrections belong to the corresponding part of the setup.
04 / Comparison · action boundaries
Convert intentions into checks a reviewer can repeat
| Initial intention | Testable version | Observation to retain |
|---|---|---|
| Everyone uses the shared skill | The selected approved skill revision can be retrieved | Resource identity and retrieval result |
| No disallowed tool use | A named covered operation gets its expected decision | Client support, activation state, and decision reason |
| Use the chosen model | A supported model-change event applies the rule | Applicable client event and observed outcome |
| Finish the requested work | The output satisfies task-specific acceptance checks | Meaningful verification results and remaining failures |
Each row has its own denominator and failure modes. Combining them into a single compliance score would hide whether the problem was retrieval, activation, support, or task quality.
For shell-related restrictions, exercise representative syntax and interpreter forms. Mapping and parsing can limit conditional checks. One rejected command does not establish general isolation of arbitrary shell behavior.
Model and reasoning support must be read per client. Claude model-switch controls apply at specified events. The native Codex adapter does not currently implement model restrictions or reasoning caps.
05 / Comparison · action boundaries
Apply the current support distinctions
Native tool and shell events
Checks are conditional on event coverage, trusted hooks, mapped operations, syntax, and interpreter behavior.
Native model choices
Claude checks cover specified model-change events. Codex model restrictions and native reasoning limits are unsupported in the current contract.
Optional runtime checks
Mimir performs its supported program, tool, model, and reasoning checks within its own runtime boundary.
06 / Comparison · action boundaries
Plan for an unavailable check
Decide what the evaluation will do when required trust is missing, a resource cannot be retrieved, or an operation has no supported gate. These are different conditions and need different responses.
For advisory content, define a review or acceptance process that checks the result. For a conditional gate, document activation and recovery. For unsupported behavior, select another control or narrow rollout scope.
A failed task needs correction of the work. A rejected revision needs a review response. An inactive event needs integration diagnosis. Calling each one an agent failure obscures the next useful action.
Use an allowed case with the restricted case. A gate that blocks all operations can look effective when tested only for denial. The allowed case reveals unnecessary restriction and protects useful work.
- Name the operation and relevant client event.
- Read the current support category.
- Check the required client version.
- Complete native trust and integration setup.
- Exercise the permitted case.
- Exercise the restricted case.
- Compare recorded reasons with expected results.
- Follow recovery after a missing prerequisite.
- Evaluate the resulting work with its own acceptance checks.
07 / Comparison · action boundaries
Treat a runtime change as a separate adoption decision
Mimir provides its own supported gates inside its runtime. A native Claude Code or Codex integration works at another boundary. These paths are not interchangeable descriptions of one control.
If the runtime gates fit a requirement, evaluate the effect of changing clients as well. Developers must assess its setup, tools, and workflow. Keep those costs visible alongside any runtime behavior.
The September Mimir experiment describes a separate harness comparison. It does not measure the performance of Betterloop guidance or gates inside native agents. Native claims need native evaluation.
Document which path the team chooses and why its supported behavior fits the requirement. Keeping that decision explicit makes future review clearer when the chosen client or support contract changes.
08 / Comparison · action boundaries
Questions to resolve before writing a guarantee
Does a signature make prose enforceable?
It authenticates content. Enforceable action checks still require a supported runtime boundary; a model receiving instructions does not guarantee that it follows them.
Can a reviewed hook remove an approval prompt?
Native permissions and required approvals remain in force. A covered hook may impose an additional restriction, but it cannot grant permission.
Does approved retrieval exclude every other skill?
It identifies and delivers the selected reviewed content. It does not establish universal exclusion of unmanaged skills or every alternative instruction source.
How should the rollout describe its controls?
State the support category together with the client, operation, release, event, and setup prerequisites. Report only what the relevant cases demonstrate.