mcpField
C
create-verification-skill

create-verification-skill

github.com/yeachan-heoOther40.7k7 installsUpdated today
Repository

About create-verification-skill

Generate the project's own verify skill: build/test/lint commands discovered by running them, a feature map of what each covers, manual checks, and an earned first verdict. Run once per repo.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/yeachan-heo/oh-my-claudecode --skill create-verification-skill

After installing, type/create-verification-skillin Claude Code to confirm it loaded.

Details

From the project README

Create Verification Skill

The bundled verify skill demands evidence but cannot know this repo's commands. This skill generates the project-local verify skill that makes verification concrete — by discovering the commands through execution, not by guessing from a README.

When to use

  • a repo has no .claude/skills/verify/ and work will be verified here more than once
  • the generic verification flow keeps guessing commands wrong for this repo

Workflow

  1. Discover by running. For each candidate surface — build, test, lint, typecheck, format, dev server, e2e — find the command (package scripts, Makefile, CI config) and run it. Record the real invocation, the expected passing output shape, the runtime, and the known gotchas (env vars, seed data, order dependence). A command you have not run is a hypothesis, not a check. Write-mode formatters (prettier --write, eslint --fix) mutate tracked files — record the read-only check form (prettier --check, eslint --check) as the verification command, never the mutating one.
  2. Record the manual surface. What cannot be checked by command here: the pages or flows a human (or run/visual-verdict) exercises, and what "looks right" means for each.
  3. Write the feature map. A table of what each check actually covers — which entry points, which layers, what it cannot see. The map is the skill's honesty: verification strength is knowable, not assumed.
  4. Generate .claude/skills/verify/SKILL.md containing: the exact commands with expected outcomes, the manual checks, the feature map, and the escalation path (which failure means what, who owns it). Keep it short enough that a fresh session reads it whole. If a verify skill already exists at the canonical root (.omc/skills/verify/SKILL.md or .claude/skills/verify/SKILL.md), respect it: update its commands and feature map in place rather than overwriting, and say what changed.
  5. Prove it. Run the generated skill's own flow once end to end on a real change and record the result through the ledger's locked writer — appendLedgerEntry and defaultLedgerPath from the installed package's dist/features/verification-ledger/index.js (babysit's ledger step demonstrates the exact invocation); never append raw rows to .omc/state/verification-ledger.tsv — the writer owns header creation, locking, and cell sanitization. The verdict is the one the flow actually earned: a real UI exercised is live-ui-verified, a test suite run is unit-test-verified, only build/lint/typecheck passed is type-check-only, and nothing runnable is no positive row at all.

Rules

  • Every command in the generated skill was executed this session, or is marked unverified with the reason.
  • The generated skill verifies; it never fixes. Fixes route to execute.
  • When the repo's commands change shape, maintain-verification-skill re-syncs this artifact.

Comments

Markdown supported