Generate a project-local verification skill that drives the real app and captures evidence for factory lifecycle gates. Use when a project has no scripted way to prove UI, CLI, or service behavior.
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
Write .factory/skills/verify-<repo>/ for the next agent, not as a human tutorial. Interview the repo before asking the user.
Answer these from the checkout:
Then generate the files:
node <skill-dir>/scripts/write-verification-skill.mjs \
--code-root <code-root> \
--factory-root <factory-root> \
[--repo <repo-name>]Replace the generated placeholders with commands and selectors you actually observed. The skill needs Launch, Doctor, Drive, Evidence, and Cleanup. Evidence goes to .factory/evidence/<ticket>/<task>/ and must survive cleanup.
For a web UI, the Drive section must use a unique SURF_SESSION, a worktree-owned free port, surf session.ensure, surf go, surf wait.ready, surf read, desktop and narrow screenshots, surf console, surf network.stats, surf smoke --screenshot, and --auto-capture on failure.
Run the generated skill once: launch, doctor, drive one feature, capture evidence, clean up, then confirm the evidence file is still there. Fix the skill if that fails. A skill that was never executed is a draft.
Store project checks in FACTORY.json as validation.work.commands. Each command has a name, an argv array, and an optional timeoutMs. The controller runs those commands in the ticket worktree. It does not read verification.command or an evidence manifest.
geut/factory-skills
6f119c3
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.