verify

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.