oboard Verify
Use this skill when a task is not finished until the change is exercised.
Goal
Produce a short verification result grounded in execution, not inference. Prefer the narrowest check that proves the changed behavior works.
Workflow
- Identify the changed surface area.
- Pick the smallest realistic verification path.
- Run the relevant command or request flow.
- Capture the observable result: exit status, key output, HTTP status, or changed behavior.
- Report what passed, what was not verified, and any remaining risk.
Rules
- Do not claim success without running something.
- Prefer focused checks over broad smoke tests.
- If the repo has no formal test target, use the nearest runnable workflow.
- If a check is blocked by environment limits, state that explicitly.
- Include exact commands when they are useful to repeat the verification.
Verification Patterns
CLI changes
- Run the exact command path affected by the edit.
- Check help text, flags, output formatting, exit codes, and side effects.
- For interactive flows, prefer the most scriptable subcommand first.
See examples/cli.md.
Server changes
- Start only the needed service.
- Exercise the changed route, handler, or background path.
- Validate status code, response shape, logs, and failure handling.
See examples/server.md.
Reporting Format
Verified:what you ran and what passed.Not verified:anything you could not run.Risk:the main remaining uncertainty, if any.