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.

评论

支持 Markdown