Maintain a verification skill

A feature map rots the moment the system changes. The system might be a software app, firmware on a board, an FPGA or RTL design, a simulator, or a lab bench. This skill is the upkeep loop for a skill generated by /create-verification-skill (or any project-local verification skill with a feature map). The unit of rigor is the feature, not every sentence: cover every feature file from source and exercise every feature live, without terminalising every bullet.

Outcomes

Pick one, and say which:

• clean — every feature got source and live coverage and the verification skill needs no change. No verification PR. A product gap still leaves its own red test when a suite exists.
• changed — one PR ships proven doc, harness, or map corrections.
• blocked — coverage could not finish or a proven fix could not ship safely. Say exactly what blocked it.

Edit scope

Only edit the verification skill's own directory (its SKILL.md, features/, and any harness scripts it owns). The one exception is a product gap: you may add one new test per gap in the project's existing suite, and no other file outside that directory. Never change product behavior during a run, including firmware, RTL, and constraints. A behavior the map describes that the system no longer does is either doc drift (fix the map) or a product regression (keep the map describing the intended behavior).

Pass

0. Locate the target. Find the verification skill to maintain: the project-local skill whose body has launch/drive sections and a feature map (usually .cursor/skills/verify-*/). Several candidates → ask which one; none → stop and point at /create-verification-skill instead of inventing a target.