Name: ork-verify
Author: yonatangross

Imported from yonatangross/orchestkit (plugins/ork-codex/skills/ork-verify/SKILL.md). Install upstream with npx skills add yonatangross/orchestkit --skill ork-verify. Copyright stays with the author.

Ork Verify

Write the evidence contract first: target, required checks, environment, success condition, and budget. Read the repository instructions for canonical commands and run the narrowest relevant checks before broad suites.

Report each command and its summary exactly. When a check depends on a third-party command or API surface, confirm its current flags and semantics with the context7 MCP server (resolve-library-id, then query-docs); a flag you only remember is a gap, not evidence. A passing test or check proves only the path it executed; verify that every required signal actually ran. Treat missing logs, unavailable external services, and skipped gates as unknown, not as success.

For material changes, use a separate ork_verifier role when installed (or a fresh Codex reviewer) with the original task and final artifacts, not the implementer's reasoning. Return a binary verdict—PASS, FAIL, or BLOCKED—with evidence, gaps, and the next action. Do not change source files or tests.

# after Install: the listing is in your workspace's routing pool - a plan picks it for its slot curl -s -X POST https://api.opensmartroute.ai/api/v1/route -H 'Authorization: Bearer $OSR_API_KEY' -H 'Content-Type: application/json' -d '{"text": "...", "plan": true}'

Install ork-verify and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

{ "ocm": "1", "id": "yonatangross-orchestkit-ork-verify", "kind": "skill", "name": "ork-verify", "description": "Verify that existing work is ready to merge, release, or hand off using an explicit evidence contract. Use when a request asks to verify, validate, prove, check readiness, run the relevant tests, or distinguish a claimed result from an observed one. Do not use to write missing tests or fix failures.", "publisher": "yonatangross", "version": "1.0.0", "capabilities": { "domains": [ "coding", "math" ], "tags": [ "skill-md", "skills-sh" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "Verify that existing work is ready to merge, release, or hand off using an explicit evidence contract. Use when a request asks to verify, validate, prove, check readiness, run the relevant tests, or distinguish a claimed result from an observed one. Do not use to write missing tests or fix failures." ], "primary": false, "metadata": { "source": { "provider": "skills.sh", "repository": "https://github.com/yonatangross/orchestkit", "path": "plugins/ork-codex/skills/ork-verify/SKILL.md", "ref": "HEAD", "url": "https://github.com/yonatangross/orchestkit/blob/HEAD/plugins/ork-codex/skills/ork-verify/SKILL.md", "key": "yonatangross/orchestkit/plugins/ork-codex/skills/ork-verify/SKILL.md" } }, "instructions": "# Ork Verify\n\nWrite the evidence contract first: target, required checks, environment, success condition, and budget. Read the repository instructions for canonical commands and run the narrowest relevant checks before broad suites.\n\nReport each command and its summary exactly. When a check depends on a third-party command or API surface, confirm its current flags and semantics with the context7 MCP server (`resolve-library-id`, then `query-docs`); a flag you only remember is a gap, not evidence. A passing test or check proves only the path it executed; verify that every required signal actual", "cost": { "context_tokens": 252 } }

ork-verify

About

Ork Verify

Use it

Install ork-verify and it becomes one more candidate the router can pick - when it fits.

Manifest

Reviews