agentleFS
Sign inStart free
team-attentionteam-attention/hoyeon/skills/verify/SKILL.md

verify

Skill173 starsChanged 8 months agoMITView on GitHub

Run a full implementation verification pass after code or data changes. Use when the user asks to verify, QA, smoke test, run checks, validate a feature, inspect a local app in the browser, capture screenshots, or turn discovered QA issues into regression tests/checklists with user approval.

We split this skill into the rules it gives an agent

24 rules. 0 are common, 19 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 165 edited versions we read keep these.

  • 19

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill as a quality gate after implementation.

    line 12
  2. Distinctive:

    Run static and command checks.

    line 21
  3. Very specific:

    Use chromux for browser QA when available.

    line 22
  4. Distinctive:

    Do not change production code while verifying.

    line 25
  5. Distinctive:

    Add or update regression tests.

    line 29
  6. Distinctive:

    Add or update verification scripts.

    line 30
  7. Very specific:

    Add or update .hoyeon/verify/* profile/checklist/report artifacts.

    line 31
  8. Distinctive:

    Do not fix product code in this skill.

    line 34
  9. Distinctive:

    If the request is ambiguous, make a reasonable first pass from repo context.

    line 48
  10. Distinctive:

    Read the smallest useful context:

    line 53
  11. Distinctive:

    Prefer existing repo commands over inventing new ones.

    line 61
  12. Distinctive:

    Run applicable checks, usually in this order:

    line 65
  13. Distinctive:

    Do not assume all commands exist.

    line 83
  14. Very specific:

    Use chromux when available.

    line 87
  15. Distinctive:

    verify the target screen renders

    line 93
  16. Distinctive:

    test modals, links, menus, maps, zoom, or forms when relevant

    line 95
  17. Distinctive:

    test at least one mobile viewport for UI work

    line 96
  18. Very specific:

    If the repo has .hoyeon/verify/profile.json, follow its URL, command, and scenario hints.

    line 105
  19. Distinctive:

    If QA finds an issue that should be caught next time, ask the user before updating verification assets.

    line 128
  20. Distinctive:

    Do not apply these updates silently unless the user already asked for automatic verification asset updates.

    line 139
  21. Distinctive:

    test/checklist updates made or awaiting approval

    line 151
  22. Distinctive:

    If checks were not run, say exactly why.

    line 153
  23. Distinctive:

    When writing artifacts, prefer:

    line 157
  24. Very specific:

    Keep .hoyeon/verify/latest-report.md as a copy or short pointer to the newest run when useful.

    line 171

“Common” is measured: kept by at least 6 in 10 of the 165 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

verify

Use this skill as a quality gate after implementation. It combines automated command verification with live browser QA and produces evidence-backed results.

Role

You are a verification agent, not an implementation agent.

Default behavior:

  • Run static and command checks.
  • Use chromux for browser QA when available.
  • Capture screenshots and concrete evidence.
  • Report pass/fail, risks, and reproducible issues.
  • Do not change production code while verifying.

Allowed after explicit user approval:

  • Add or update regression tests.
  • Add or update verification scripts.
  • Add or update .hoyeon/verify/* profile/checklist/report artifacts.
  • Record known issues and reproduction steps.

Do not fix product code in this skill. If a product fix is required, hand off to an implementation workflow such as execute.

Workflow

1. Define Mission

Extract the verification target from the user request:

  • Feature or behavior being verified.
  • Expected outcome.
  • Relevant app URL, command, or route.
  • Any specific user acceptance criteria.

If the request is ambiguous, make a reasonable first pass from repo context. Ask only when the missing detail prevents verification.

2. Inspect Repo Verification Surface

Read the smallest useful context:

  • package.json
  • existing test/e2e scripts
  • existing verification scripts
  • .hoyeon/verify/profile.json or .hoyeon/verify/checklist.md if present
  • app startup docs or env hints only when needed

Prefer existing repo commands over inventing new ones.

3. Run Command Verification

Run applicable checks, usually in this order:

  1. install/dependency sanity if needed
  2. lint/static analysis
  3. typecheck
  4. build
  5. unit/integration tests
  6. existing e2e or smoke scripts

For JavaScript/TypeScript repos, common commands are:

  • pnpm lint
  • pnpm typecheck
  • pnpm build
  • pnpm test
  • pnpm test:e2e
  • pnpm verify

Do not assume all commands exist. Inspect scripts first.

4. Run Browser QA

Use chromux when available. If chromux is unavailable, use the best local browser tool and state the fallback.

Browser QA should exercise the actual user flow, not only page load:

  • open the app
  • verify the target screen renders
  • click key buttons/tabs/filters
  • test modals, links, menus, maps, zoom, or forms when relevant
  • test at least one mobile viewport for UI work
  • capture screenshots into a stable artifact directory

Default screenshot directory:

artifacts/screenshots/

If the repo has .hoyeon/verify/profile.json, follow its URL, command, and scenario hints.

5. Classify Findings

Classify every issue:

  • blocking: breaks the requested behavior or a core user path
  • major: important UX/data/reliability problem with a workaround
  • minor: polish, clarity, or low-risk issue
  • test-gap: behavior works now but lacks regression coverage

For each finding include:

  • title
  • severity
  • evidence
  • reproduction steps
  • expected vs actual
  • whether it should become a regression test/checklist item

6. Update Verification Assets With Approval

If QA finds an issue that should be caught next time, ask the user before updating verification assets.

Approval-gated updates may include:

  • adding a command check
  • adding a browser/e2e assertion
  • adding a scenario to .hoyeon/verify/checklist.md
  • updating .hoyeon/verify/profile.json
  • recording a known issue under .hoyeon/verify/runs/<timestamp>/

Do not apply these updates silently unless the user already asked for automatic verification asset updates.

7. Report

Final response should be concise and evidence-backed:

  • verdict: pass, pass_with_warnings, or fail
  • commands run and result
  • browser QA actions performed
  • screenshots captured
  • findings ordered by severity
  • test/checklist updates made or awaiting approval

If checks were not run, say exactly why.

Report Artifact Shape

When writing artifacts, prefer:

.hoyeon/verify/
  profile.json
  checklist.md
  runs/
    YYYY-MM-DD-HHMMSS/
      report.md
      findings.json
      command-log.md
      screenshots/

Keep .hoyeon/verify/latest-report.md as a copy or short pointer to the newest run when useful.

Verdict Policy

  • fail: any command fails, browser QA cannot complete a required path, or a blocking issue is found.
  • pass_with_warnings: commands pass, required paths work, but major/minor findings or test gaps remain.
  • pass: commands pass, browser QA passes, and no material findings remain.

Download now (ZIP)

  • Other versions187 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 187

    1. facebook/react★ 252ksame name
    2. react/react★ 251ksame name
    3. garrytan/gstack★ 139ksame name
    4. oven-sh/bun★ 96ksame name
    5. anthropics/financial-services★ 41ksame name
    6. anthropics/financial-services-plugins★ 41ksame name
    7. Yeachan-Heo/oh-my-claudecode★ 40ksame name
    8. Yeachan-Heo/oh-my-claude-sisyphus★ 40ksame name
    9. anthropics/claude-quickstarts★ 19ksame name
    10. NVIDIA-NeMo/NeMo★ 19ksame name

    177 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use build-fix, external-context and 9 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • diego-tobalinaSkill

      build-fix

      Fix build and compilation errors systematically. Run when build fails.

      Also in 6 projects that use this

    • Jurel89Skill

      external-context

      Invoke parallel document-specialist agents for external web searches and documentation lookup

      Also in 3 projects that use this

    • TheKREATORSSkill

      instinct-export

      Export instincts from project/global scope to a file

      Also in 3 projects that use this

    • TheKREATORSSkill

      instinct-import

      Import instincts from file or URL into project/global scope

      Also in 3 projects that use this

    • AviadPSkill

      risk-assess

      Assess the risk and blast radius of a proposed code change before implementing it. Evaluates CI impact, framework-wide vs localized scope, rollback path, and identifies blindspots. Use when user says "what's the risk", "is this safe", "assess the impact", "risk assess", "blast radius", or before applying framework-wide or CI-affecting changes. Do NOT use for code quality review (use code-quality) or plan validation (use design-validator).

      Also in 3 projects that use this

    • Jurel89Skill

      configure-notifications

      Wire Telegram / Discord / Slack notifications for copilot-omni run events (start, progress, completion, error)

      Also in 3 projects that use this

    • +2 more from Jurel89
  • In this repository27 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free