Read the review workflow explanation
Follow a pagination review from contract to finding.
Open this resource →Workbook · Resource approval
Decide what a new resource should let the team do.
Evaluate an agent resource through its instructions, dependencies, required operations, and supported runtime controls.
A useful resource needs a clear job. Describe that job first, then examine the content and permissions needed to carry it out.
01 / Workbook · Resource approval
A review workflow for search-api
The Search team wants help reviewing pagination changes. A developer proposes a workflow that reads the patch and traces affected callers.
The team wants a local review report. Posting comments to a pull request is outside the proposed task.
This fictional situation gives reviewers a concrete decision. They can assess the workflow's advice without granting every operation an agent might attempt.
Start with the output the team expects. Then identify the tools, accounts, shell programs, and external changes needed to produce it.
This approach also works for an agent role or integration. A broad resource name is less useful than a precise description of the proposed work.
Keep the desired workflow separate from its permission requirements throughout the review. Neither decision should become invisible inside the other.
02 / Workbook · Resource approval
Read the resource as a set of commitments
Instructions describe how the agent should approach its work. They may introduce supporting references, task assumptions, or requests for external action.
Read the entry point and supporting files together. A short skill description can omit a dependency that changes the final result or required setup.
Catalog readiness means an entry can enter selection. The company still needs to review its chosen version and publish the resulting configuration.
Some entries require organization values or integrations. Resolve those requirements through supported setup rather than inventing an undocumented helper.
A supporting executable file is not automatically a registered hook. Discovering resource files should not cause those files to execute.
Record what the resource actually contributes. It may provide advice, a repeatable workflow, a reference, or an executable addition with separate grants.
03 / Workbook · Resource approval
Prepare the proposed workflow
- 01
Define the output
Describe the local review report your team expects.
- 02
List required operations
Identify source reads, diagnostic execution, and any proposed external changes.
- 03
Inspect supporting content
Read the selected resource and its declared dependencies.
- 04
Check client support
Compare the intended native agent with the resource’s declared clients.
- 05
Check required grants
Inspect organization grants for any executable team addition.
- 06
Choose a harmless evaluation
Prepare a small patch in an isolated repository without production credentials.
04 / Workbook · Resource approval
Select a precise reviewed version
Evidence-based PR review 1.0.0 fits the example task. Its declared clients are Claude Code and Codex, and it depends on Delivery evidence 1.0.0.
The workflow directs attention to behavior, callers, compatibility, errors, and tenant boundaries. The reference supports an accurate account of the review result.
Its availability does not authorize publishing a finding. Keep the task's local report boundary explicit when the developer starts the evaluation.
Select the exact versions through the company configuration process. Review the exported files and manifest at the proposed revision before release.
If the team adds an executable hook, rule, or role, inspect the organization grant at the team's company baseline.
After the accepted release reaches the device, verify retrieval independently from the task result. Missing content and ineffective instructions require different investigation.
05 / Workbook · Resource approval
Give the agent a narrow review assignment
The sample change alters the cursor used by search-api pagination. Ask the agent to investigate page boundaries and the relevant callers.
Practice assignment:
Examine the proposed pagination patch.
Trace how callers obtain and reuse the cursor.
Describe defects supported by the available source or checks.
Prepare the report locally.
Leave the pull request unchanged.A useful report explains a trigger and its consequence. It should distinguish a demonstrated pagination problem from a preference for different code style.
If the agent needs a tool that is unavailable, identify that requirement. Do not interpret the resource’s selection as authorization to bypass native permission.
When a later task explicitly authorizes posting comments, evaluate that operation separately. Keep the authority for publication clear in the session.
06 / Workbook · Resource approval
Evaluate a supported shell restriction safely
Runtime checks need a client that covers the relevant operation. Consult the compatibility details before selecting a test for a particular gate.
For a small shell exercise, allow rg while excluding ls in the example configuration. Every applicable restriction must permit the allowed operation.
Prepare a local fixture directory with harmless sample files. Keep network access, deletion, and production systems outside this exercise.
Ask the agent to enumerate the fixture with rg. The operation needs both the matching shell permission and permission to use the tool.
Next request ls against the same fixture. Under the stated restriction, the covered gate should reject that executable.
Inspect what actually happened in both cases. A missing decision report cannot by itself establish whether the host attempted or completed an operation.
07 / Workbook · Resource approval
Understand exactly what that test covers
The managed shell boundary accepts one literal executable with arguments. Covered adapters reject ambiguous syntax and executable names outside the allowed set.
Quoted arguments and escaped spaces remain supported. Chaining, pipelines, redirects, expansions, and command substitutions are rejected at that boundary.
An allowed executable may itself run code or start another program. A successful program-name check therefore cannot establish containment of all descendant processes.
Tool permissions remain independent of the shell restriction. A permitted executable does not grant access to a separately denied tool.
Native plugin coverage also depends on trust, activation, and correct host execution. A native hook failure can allow work to proceed.
rg --files fixture08 / Workbook · Resource approval
Use an unexpected result to narrow the investigation
Preserve the diagnostic output before changing setup. Otherwise, a repair can remove the evidence needed to explain the original result.
Avoid widening policy merely to obtain a successful demonstration. The useful result is understanding whether the intended operation has the intended boundary.
| Result | Question to answer | Next decision |
|---|---|---|
| Selection reports a missing prerequisite. | Which dependency, parameter, or client declaration is unmet? | Resolve that prerequisite before release. |
| An integration remains unavailable. | Has its separate authentication and native discovery completed? | Repair access without broadening resource approval. |
| An intended executable addition is rejected. | Does the pinned company revision grant it? | Revise the proposal or review the required grant. |
| The allowed sample is denied. | Which applicable tool or shell restriction rejected it? | Inspect that exact restriction. |
| The denied sample executes. | Did the intended host boundary run with valid policy? | Investigate activation and host behavior before relying on it. |
09 / Workbook · Resource approval
Keep the approval record useful after rollout
Save the chosen resource identity, dependencies, client version, and tested operations. That record gives later reviews a concrete starting point.
Repeat relevant checks when a host version or policy release changes. Earlier behavior does not establish the state of a new installation.
Personal resources may remain discoverable beside selected content. Approval of the company workflow does not create device-wide exclusion of other local skills.
Doctor can report detectable unmanaged sources without uploading their paths or content. Use that information to investigate a discrepancy in the local environment.
Mimir is another available runtime with different supported native gates. Choose it only after comparing those controls with the team's actual task requirements.
Keep any unsupported mandatory operation visible. An approved instruction cannot supply a runtime event that the selected client does not expose.
10 / Workbook · Resource approval
Questions during resource approval
Does a role resource grant delegation permission?
No. It supplies reviewed role instructions. Delegation still requires its own authority under the task and applicable controls.
Can a hook grant an operation that native approval denies?
No. A covered hook can restrict work; it cannot override native permission or manufacture authorization.
What if the resource is useful but the runtime control is missing?
Document the separate outcomes. The content may remain useful while a mandatory control still prevents the proposed rollout.
Should an unexpected denial lead to broader permissions?
First identify the rejecting boundary. Repair an incorrect setup or narrow mismatch before changing reviewed company requirements.
11 / Workbook · Resource approval
Close the resource decision
Write the permitted job, reviewed content version, required operations, and observed evaluation results in one review record.
Use that record when deciding whether to release, revise, or defer the proposal. Keep external publication as a separately authorized action.