Create a verification skill

Every serious project needs a scripted way to drive the real system and prove behavior: launch it, exercise a feature the way a user would, and capture evidence. The system might be a software app, firmware on a board, an FPGA or RTL design, a simulator, or a lab bench. This skill generates that as a project-local skill (.cursor/skills/verify-<target>/) tailored to the repo. You write the generator's output for the next agent, not for a human: it will be read cold, mid-task, by an agent that has never seen the system.

1. Interview the repo, not the user

Answer these from the codebase and only ask the user what you cannot observe:

• Surface: what does a user actually touch? A web UI, a CLI/TUI, a desktop app, an API, a mobile app, a library, firmware on a board, an FPGA or RTL design, a simulator, or a lab bench? A repo can have several; pick the primary one and note the rest.
• Run: how does the system start locally? Prefer the repo's own documented command (package scripts, Makefile, README quickstart, flash or program step, simulator invocation). Note ports, env vars, seed data, auth, serial port, probe, bitstream, pin constraints, clock, and supply.
• Drive: how can an agent interact with it programmatically? Existing harnesses first: Playwright/Cypress specs, expect scripts, PTY helpers, curl-able endpoints, a debug port, OpenOCD, probe-rs, pyOCD, esptool, a cocotb or other testbench, a scripted instrument. Only then pick a generic recipe: browser/CDP for web and Electron, a tmux/PTY harness for CLI/TUI, plain HTTP for services, a serial console or JTAG/SWD session for firmware, the testbench for RTL, SCPI or the repo's fixture script for a bench.
• Observe: what evidence can be captured? Screenshots, terminal transcripts, response bodies, logs, exit codes, DB state, UART logs, register dumps, waveforms, logic-analyzer or scope captures, measured voltage or current, simulator logs.
• Isolate: can two instances run side by side (ports, data dirs, profiles, simulator processes, a second board)? A physical board, probe, or instrument usually cannot. Say so in the generated skill. Refusing to double-drive a shared board or session beats corrupting the user's setup. If only a simulator is available, the physical bench is unreachable until its prerequisite is present. Do not invent a board.

If the checkout doesn't build, flash, program, or start as-is, fix that first (or report it precisely) before generating; a skill written against a broken base teaches wrong steps. When an irrelevant missing asset blocks startup (a static dir the API never serves, a sample config, a missing constraints file the design never uses), the generated skill may create it, clearly marked as verification scaffolding, and remove it in cleanup.

2. Generate the skill

Write .cursor/skills/verify-<target>/SKILL.md with YAML frontmatter (name: verify-<target> and a description that names the system, the surface, and when to reach for it — without frontmatter the skill never registers) and these sections, each grounded in what the interview actually found (no placeholders left):