verify-change

Files (14)

• SKILL.md
• openai.yaml · agents/
• behavior-review.md · references/
• browser.md · references/
• capture.md · references/
• evidence.md · references/
• local-display-test.md · references/
• video.md · references/
• browser-session.py · scripts/
• capture.mjs · scripts/
• offline-exec.py · scripts/
• render-video.py · scripts/
• test_capture.mjs · scripts/
• test_video.py · scripts/

SKILL.md (first lines)

1. Define expected behavior, entry point and side effects. Prove it through the running API, worker, CLI or actual browser UI. Compare bugs on equivalent failing-base and fixed-head fixtures, and refactors on matching base/head scenarios and side effects; label missing baselines. Cover happy paths, common failures, handled edge cases and, when relevant, flag states, old/new records and affected product modes. Through the running entry point, prove allowed access, same-org other-user denial for user-scoped data, and cross-org denial for tenant-scoped data; check denied responses expose no protected content. Focused tests support runtime checks. For shared-code changes, refactors and lint migrations, use [behavior review](references/behavior-review.md) to map affected entry points to expected effects and evidence in the existing verification report.
2. When implementation, verification and babysitting are requested together, verify after implementation and after babysitting completes; use focused checks during fixes. Reuse unaffected proof with a reason and rerun changed or uncertain behavior. Keep tested revisions separate from assessed revisions, verify stack layers with ancestors only, and satisfy required CI.
3. Read the target project’s verification instructions for runtime setup, authentication, fixtures, feature gates and cleanup. Use its documented runtime and health checks; establish tested revisions, service health and resource ownership before collecting evidence and after runtime changes. Keep project-specific configuration outside this skill.
4. Exercise the relevant entry point: API requests with responses and persisted effects; worker jobs with correlated completion, output and side effects; CLI commands with exit status and actual output/files. Confirm expected outcomes and relevant errors; inspect generated/downloaded artifacts and relevant UI transitions when those are in scope. For UI checks only, follow [browser](references/browser.md), [capture](references/capture.md) and [video](references/video.md) for native computer-use controls, the virtual-display workflow, task-owned recording and OpenScreen edits. UI checks are only accepted when the user has explicitly requested them.
5. Follow [evidence and delivery](references/evidence.md). Fix findings within the authorized scope, then report verified, partially verified or blocked with tested revisions, fresh/reused/untested checks, later fixes and limits. When authorized, publish a new PR evidence comment with GitHub attachments. Release owned resources, restore local gates, remove ephemeral credentials and apply the evidence retention policy.

From AmitRockBear/skills, MIT.

More from AmitRockBear/skills