mcpField
C
create-verification-skill

create-verification-skill

github.com/yeachan-heoその他40.7k7 回インストール今日更新
リポジトリ

create-verification-skill について

プロジェクト独自の verify スキルを生成します。build/test/lint コマンドを実際に実行して特定し、それぞれの対象範囲を示す機能マップ、手動チェック、実際に得られた初回判定を含めます。リポジトリごとに一度実行します。

インストール

コマンドをコピーしてターミナルで実行します。

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

インストール後、Claude Code で/create-verification-skillを入力して読み込まれたか確認します。

README(原文)English

プロジェクトの README より

この 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.

コメント