# verification-skill-example
**Private reference.** Heavily fictionalized example of a project-local verification skill + behavior-level feature map for a large desktop app.
Nothing here is a real product. "Atlas" / "Harbor Labs" / `control-atlas` are made up. The shape is what matters.
## Layout
```text
.cursor/skills/verify-atlas/
SKILL.md # launch, doctor, drive, prove, clean up
# control-atlas.mjs # CLI omitted on purpose; usage only in SKILL.md
references/features/
README.md # index, conventions, sweep order
*.md # one file per feature area (~30)
```
## Why not a wiki?
A wiki is great for humans. Agents pay for every token they reread. A skill + feature map is:
- **Scoped.** Open one feature file for the change under test, not the whole corpus.
- **Actionable.** Each file answers the same four questions: what exists, how a user reaches it, how to drive it with the harness, what usually lies.
- **Sweepable.** `features/README.md` is a top-to-bottom regression order for "did we break the app broadly?"
- **Maintained as code.** Drift gets fixed in the same PR as the UI change, or by a maintain-verification pass.
## How an agent uses it
1. Match the change to one or more feature files.
2. Run `doctor` so the instance is fresh.
3. Drive every reachable entry point the file lists (and the success / cancel / error / empty / persistence paths the change can affect).
4. Capture evidence (screenshot, DOM assertion, clipboard, network, reload round-trip).
5. For broad sweeps, walk the README top to bottom, finish with `multi-surface-journeys.md`.
## Scale
This sample is sized like a large app: ~30 feature files across account/chrome, left rail/sessions, prompt/replies, layout, source control, app panes, hosted/remote, preferences/extensibility, and system UX. Keep entries behavior-level and short enough to run without reading source. Split a file when a section starts needing its own preconditions.
Driver scripts are intentionally omitted. The skill shows the command surface and example invocations only.