Inspect another resource purpose
Compare skills, references, workflows, and advisory guidance.
Open this resource →Skill explanation
Plan the change around a result you can show.
Understand Verified change through a search-order task, meaningful acceptance checks, and an evidence-based handover.
A useful patch answers the request completely. Follow how the Verified change skill connects that request with implementation and actual observations.
01 / Skill explanation
An implementation starts with the requested result
A developer asks an agent to correct the default order of Search results. Existing callers can also request an explicit sort order.
A patch that changes the default but breaks explicit ordering does not complete the request. Both behaviors belong in the acceptance conditions.
Verified change helps the agent connect its repository work with those conditions. It supplies a task approach rather than a new test framework.
This explanation uses a fictional search-api task. It is designed to help a team evaluate the skill, not to report a measured product result.
Start by identifying what a reader could observe after the change. That makes it easier to choose implementation scope and relevant checks.
A complete solution can span callers or migration work when the contract requires them. Scope should follow the request rather than a preferred diff size.
02 / Skill explanation
Catalog identity for this example
| Catalog property | Recorded value |
|---|---|
| Published resource name | Verified change |
| Catalog identifier | betterloop.verified-change |
| Type | Skill |
| Version | 1.0.0 |
| Maintainer | Betterloop platform catalog |
| Catalog state | Ready for selection |
| Company review state | Company approval is still required for release |
| Declared clients | Claude Code and Codex |
| Dependencies | Delivery evidence, version 1.0.0 |
| Required configuration | No company-specific values are declared |
| Permissions | Selection supplies no extra authority |
03 / Skill explanation
How to read the skill’s purpose
In editorial terms, the skill asks the agent to orient itself before editing. Repository guidance and existing behavior supply the context for a useful change.
The agent then needs a concrete picture of completion. Expected behavior should be clear enough to examine through source, execution, or another appropriate observation.
Implementation should address that behavior without taking over unrelated work. Existing edits deserve inspection before the agent decides which changes belong to its task.
Verification needs to match the changed contract. A successful build can establish compilation while leaving ordering or pagination behavior unresolved.
The final handover should connect the actual patch with the evidence obtained. Its Delivery evidence dependency supports that account.
This is a fresh explanation of the resource's intent. It is not a quotation of the selected SKILL.md or a substitute for reviewing its bytes.
04 / Skill explanation
Prepare an ordering task for evaluation
- 01
Read repository guidance
Find the instructions that govern search-api changes.
- 02
Inspect existing callers
Identify default-order callers and callers that supply a sort option.
- 03
Describe the expected default
Write the order users should receive without an explicit option.
- 04
Describe preserved behavior
Record the documented behavior for explicit sort requests.
- 05
Identify existing checks
Locate verification that exercises both contracts.
- 06
Inspect current edits
Separate prior work from the requested implementation.
05 / Skill explanation
Give the acceptance record enough detail
Use a small representative result set with distinguishable ordering. A fixture that looks identical under every sort cannot expose the regression.
Practice acceptance record:
Default request: results follow the documented relevance order.
Explicit sort request: the supplied sort option keeps its existing meaning.
Evidence: examine output from the repository’s ordering checks.
Handover: identify the source revision and actual release state.The record leaves the exact test command to the repository. A public example should not invent executable interfaces for a service it cannot inspect.
The explicit sort case matters because existing callers depend on it. Trace those callers before assuming that a default change is isolated.
Inspect the checks after execution. A green command is useful only when the assertions and sample data cover the behavior under discussion.
06 / Skill explanation
Review the implementation as a complete scoped change
Read the final patch beside the acceptance record. Check that the default behavior changed where intended and explicit ordering still reaches the correct implementation.
Look beyond the edited function when the request affects callers, serialized options, or stored configuration. A necessary companion change belongs in scope.
Preserve unrelated edits even when nearby code would be convenient to rewrite. The skill does not authorize taking ownership of another task.
When an acceptance check fails, inspect that result before declaring completion. Repair the relevant behavior and repeat the check after the change.
Do not add a test that merely repeats the new implementation. Choose evidence that would distinguish the intended behavior from the original defect.
A direct observation can suit a low-impact task. The method should be proportionate while still answering the request's actual acceptance question.
07 / Skill explanation
Evaluate the skill through the work it produces
| Point in the task | Useful observation | What remains separate |
|---|---|---|
| Orientation | Relevant guidance and callers informed the plan. | Reading files alone does not establish a working change. |
| Acceptance | Default and explicit ordering have distinct expected outcomes. | A broad statement of intent is insufficient evidence. |
| Implementation | The patch covers required behavior and necessary callers. | Unrelated edits remain outside the request. |
| Verification | Executed checks distinguish the desired behavior. | Compilation cannot establish every runtime property. |
| Handover | The report matches actual observations and release state. | A source change does not establish deployment. |
08 / Skill explanation
Check the selected resource before judging its advice
Confirm retrieval of betterloop.verified-change 1.0.0 and its declared Delivery evidence dependency. Compare those identities with the team's accepted configuration release.
If retrieval fails, investigate selection, required files, signed state, and declared client support. A task example cannot repair missing release content.
If retrieval succeeds but the acceptance record is weak, examine the task and the agent's use of the advice. Availability does not guarantee adherence.
Avoid changing runtime permissions simply because the report is unhelpful. The content's quality and the tool's authorization are different questions.
Use the same representative task when evaluating a proposed resource revision. Otherwise, task differences can obscure whether the new wording addressed the observed issue.
Keep the evidence bounded to the actual trial. The page does not claim that installing this skill makes every implementation correct.
09 / Skill explanation
Decide whether the skill fits your team
The skill is useful when requests need a clear route from implementation to demonstrated completion. It does not supply repository-specific acceptance criteria for you.
A repository without reliable checks still needs a verification method. Selecting additional instructions cannot make an unexamined test trustworthy.
A read-only patch review needs a review workflow rather than an implementation task. Backend changes may also need the relevant service boundary guidance.
External publication, deployment, and messaging retain their own authorization requirements. Selecting this skill grants none of those operations.
Keep the first evaluation small enough to inspect directly. Record which acceptance question the skill helped clarify and which repository work remains necessary.
10 / Skill explanation
Questions while evaluating Verified change
Does every task require a new automated test?
No. Choose meaningful verification for the changed behavior. A direct observation may be enough for a small reversible correction.
Why include the reporting reference?
Delivery evidence 1.0.0 is the declared dependency. Review it alongside the skill because it supports the final account of the work.
Can the skill decide that production changed?
It can guide the report, but a deployment claim still needs actual release evidence and separate authorization.
11 / Skill explanation
Take the example through your own review
The public explanation is a starting point for evaluation. Inspect the exact resource files selected by your company before accepting a configuration change.
Keep the catalog identity and dependency versions attached to that review. The reviewed release should supply the same content the owners examined.
Selection creates reviewable configuration content; it does not by itself approve or activate it. Follow the normal signing and team adoption process.
On the developer device, complete required native trust and session activation. Then examine resource retrieval and the representative task as separate observations.
A signed release establishes the reviewed content and scope. It does not guarantee that the native agent follows every instruction.
Use the approval workbook when the example requires additional operations. Resource advice and authority to execute a tool remain distinct decisions.