Write .claude/skills/verify-<app>/: a SKILL.md and a CLI. The CLI is the point. A command costs one tool call and a few lines of output. The same step written as prose costs a re-read, a throwaway script, and a page dump every session, and drifts between sessions.

You write for an agent that reads the skill cold, mid-task, and has never seen the app.

1. Read the repo, not the user

Answer from the code. Ask the user only what you cannot observe.

Surface. What does a user touch? A web UI, an API, a CLI, a worker. Pick the primary one and note the rest.
Run. How does it start? The repo's own commands first: package scripts, compose files, the README, any skill or doc that explains how to run it. Note env vars, seed data, auth, and services it needs from other repos.
Drive. How can a script interact with it? Existing tooling first: Playwright or Cypress specs, HTTP endpoints, a debug port. Then a generic recipe: Playwright as a library for a web UI, plain HTTP for a service, a PTY for a CLI.
Evidence. What proves a behaviour? Screenshots, response bodies, rows in the database, logs, exit codes.

If the checkout does not build or start as it is, fix that first or report it precisely. A skill written against a broken base teaches wrong steps.

2. Write only what the agent cannot find

Agents copy the patterns the repo already has and solve what they see when it happens: a port in use, a stale container, a missing dependency. Do not write rules for those. Write what the agent cannot see in the repo or discover by running:

create-verification-skill

1. Read the repo, not the user

2. Write only what the agent cannot find