개인 참조. Heavily fictionalized example of a project-local Verified skills + 큰 데스크톱 응용 프로그램에 대한 동작 수준의 기능 맵.

아무것도 여기에 진짜 제품입니다. “Atlas” / “Harbor Labs” / control-atlas가 만들어졌습니다. 모양은 무슨 사정입니다.

배치

왜 위키가 아닌가?

wiki는 인간에게 좋습니다. 에이전트는 모든 토큰을 지불합니다. 기술 + 특징지도는:

• **Scoped. ** 테스트의 밑에 변화를 위한 1개의 특징 파일을, 전체적인 corpus 아닙니다 엽니다.
• Actionable. 각 파일은 동일한 네 질문에 답합니다. 무엇 존재, 사용자가 어떻게 도달하는지, 마구로 구동하는 방법, 일반적으로 거짓말.
• Sweepable. features/README.md는 "did we break the app widely?"를 위한 top-to-bottom 회귀 순서입니다.
• 코드로 유지. Drift는 UI 변경으로 동일한 PR에 고정되거나 유지 보수 검증 패스로 고정됩니다.

대리인이 그것을 사용하는 방법

1. 하나 이상의 기능 파일에 변화를 일치합니다.
2. 실행 doctor 그래서 인스턴스는 신선합니다.
3. 모든 도달 가능한 입력점을 드라이브 파일 목록 (및 성공 / 취소 / 오류 / 빈 / 지속 경로 변경에 영향을 미칠 수 있음).
4. 캡처 증거 (스크린 샷, DOM assertion, 클립 보드, 네트워크, 다시로드 왕복).
5. 명세.

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

.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.