/qa
QA testing skill with real browser automation. Use when asked to "test this site", "QA this page", "check for visual bugs", "verify the deploy", or when Hydra needs browser validation for UI changes. Requires the browse binary.
$ npx -y skills add blueberrycongee/termcanvas --skill qa --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/qa
Context preview
The summary Claude sees to decide when to auto-load this skill.
QA testing skill with real browser automation. Use when asked to "test this site", "QA this page", "check for visual bugs", "verify the deploy", or when Hydra needs browser validation for UI changes. Requires the browse binary.
SKILL.md
qa.SKILL.mdname: qa
description: >-
QA testing skill with real browser automation. Use when asked to "test this
site", "QA this page", "check for visual bugs", "verify the deploy", or
when Hydra needs browser validation for UI changes. Requires the browse
binary.
QA
Browser-based QA testing with the `browse` CLI. Test real user flows, capture visual evidence, and fix issues with atomic commits.
Phase 0: Setup
1. Verify browse is available: `browse status` 2. If not found, report error — browse binary must be installed 3. Get the target URL from the task description or ask the user
Phase 1: Orient
1. Navigate to the target: `browse goto <url>` 2. Take a baseline snapshot: `browse snapshot -i` 3. Check console for errors: `browse console` 4. Extract navigation links: `browse links` 5. Build a site map of pages to test (limit to 10 most important pages)
Phase 2: Page-by-Page Audit
For each page in the site map:
1. Navigate: `browse goto <page-url>` 2. Snapshot interactive elements: `browse snapshot -i` 3. Check console for errors: `browse console` 4. Screenshot for evidence: `browse screenshot <page-name>.png` 5. Note issues found: broken links, console errors, missing elements, layout problems visible in snapshot
Phase 3: User Flow Testing
Test the primary user flows (signup, login, checkout, etc.):
1. Identify the flow steps from the snapshot 2. Execute each step using refs:
- `browse click @e3` — click buttons/links
- `browse fill @e5 "test@example.com"` — fill inputs
- `browse select @e7 "option-value"` — select dropdowns
- `browse press Enter` — submit forms
3. After each step, snapshot and verify the expected outcome 4. Screenshot at each step for evidence
Phase 4: Health Score
Rate the site on a 0-10 scale across these dimensions:
- **Console health**: errors / warnings count
- **Link health**: broken links / total links
- **Interactivity**: do buttons and forms work?
- **Visual completeness**: are there missing images, broken layouts?
Report format:
Health Score: 7/10
- Console: 9/10 (2 warnings, 0 errors)
- Links: 8/10 (1 broken link out of 45)
- Interactivity: 6/10 (signup form submit fails silently)
- Visual: 5/10 (hero image 404, footer misaligned on mobile)
Phase 5: Fix Loop
For each issue found (in severity order):
1. Locate the root cause in the source code 2. Write the minimal fix 3. Run the test suite 4. Commit atomically: one fix per commit 5. Re-test in the browser to confirm the fix: `browse goto <url>` + `browse screenshot` 6. Move to the next issue
Stop conditions:
- All Critical/High issues fixed
- 20-fix cap reached (report remaining as known issues)
- Test suite regression detected — stop and report
Phase 6: Report
Summarize all findings:
1. Pages tested (count and list) 2. Issues found (by severity) 3. Issues fixed (with commit hashes) 4. Issues remaining (if any) 5. Health score before and after 6. Screenshot evidence (file paths)
Rules
- Always take screenshots as evidence — never claim "it looks fine" without proof
- One fix per commit, atomic and revertable
- Do not fix style preferences — only fix real bugs and broken functionality
- If you cannot reproduce an issue in the browser, note it as "not reproduced"
- Stop after 20 fixes to avoid scope creep
Read more
name: qa description: >- QA testing skill with real browser automation. Use when asked to "test this site", "QA this page", "check for visual bugs", "verify the deploy", or when Hydra needs browser validation for UI changes. Requires the browse binary.
QA
Browser-based QA testing with the `browse` CLI. Test real user flows, capture visual evidence, and fix issues with atomic commits.
Phase 0: Setup
1. Verify browse is available: `browse status` 2. If not found, report error — browse binary must be installed 3. Get the target URL from the task description or ask the user
Phase 1: Orient
1. Navigate to the target: `browse goto <url>` 2. Take a baseline snapshot: `browse snapshot -i` 3. Check console for errors: `browse console` 4. Extract navigation links: `browse links` 5. Build a site map of pages to test (limit to 10 most important pages)
Phase 2: Page-by-Page Audit
For each page in the site map:
1. Navigate: `browse goto <page-url>` 2. Snapshot interactive elements: `browse snapshot -i` 3. Check console for errors: `browse console` 4. Screenshot for evidence: `browse screenshot <page-name>.png` 5. Note issues found: broken links, console errors, missing elements, layout problems visible in snapshot
Phase 3: User Flow Testing
Test the primary user flows (signup, login, checkout, etc.):
1. Identify the flow steps from the snapshot 2. Execute each step using refs:
- `browse click @e3` — click buttons/links
- `browse fill @e5 "test@example.com"` — fill inputs
- `browse select @e7 "option-value"` — select dropdowns
- `browse press Enter` — submit forms
3. After each step, snapshot and verify the expected outcome 4. Screenshot at each step for evidence
Phase 4: Health Score
Rate the site on a 0-10 scale across these dimensions:
- **Console health**: errors / warnings count
- **Link health**: broken links / total links
- **Interactivity**: do buttons and forms work?
- **Visual completeness**: are there missing images, broken layouts?
Report format:
Health Score: 7/10 - Console: 9/10 (2 warnings, 0 errors) - Links: 8/10 (1 broken link out of 45) - Interactivity: 6/10 (signup form submit fails silently) - Visual: 5/10 (hero image 404, footer misaligned on mobile)
Phase 5: Fix Loop
For each issue found (in severity order):
1. Locate the root cause in the source code 2. Write the minimal fix 3. Run the test suite 4. Commit atomically: one fix per commit 5. Re-test in the browser to confirm the fix: `browse goto <url>` + `browse screenshot` 6. Move to the next issue
Stop conditions:
- All Critical/High issues fixed
- 20-fix cap reached (report remaining as known issues)
- Test suite regression detected — stop and report
Phase 6: Report
Summarize all findings:
1. Pages tested (count and list) 2. Issues found (by severity) 3. Issues fixed (with commit hashes) 4. Issues remaining (if any) 5. Health score before and after 6. Screenshot evidence (file paths)
Rules
- Always take screenshots as evidence — never claim "it looks fine" without proof
- One fix per commit, atomic and revertable
- Do not fix style preferences — only fix real bugs and broken functionality
- If you cannot reproduce an issue in the browser, note it as "not reproduced"
- Stop after 20 fixes to avoid scope creep
Your terminals, on an infinite canvas. TermCanvas spreads all your terminals across an infinite spatial canvas — no more tabs, no more split panes. Drag them around, zoom in to focus, zoom out to see the big picture.
Repo: blueberrycongee/termcanvas
Other skills on termcanvas.
- /challenge
Adversarial review skill. Use when the user wants to stress-test an idea, argument, proposal, or opinion from multiple independent angles. Spawns parallel Hydra workers with orthogonal analytical methodologies.
Open skill - /code-review
Structured code review skill. Use when asked to "review this code", "review this PR", "check this diff", or when acting as a Hydra reviewer. Runs a multi-pass review with specialist focus areas and confidence-gated findings.
Open skill - /hydra
Use when a task should run through Hydra's Lead-driven workflow for multi-agent orchestration, or when an existing workflow must be inspected or cleaned up.
Open skill - /investigate
Systematic debugging skill. Use when encountering a bug, test failure, unexpected behavior, or when asked to "investigate", "debug", "diagnose", or "figure out why". Enforces root-cause-first discipline with structured hypothesis tracking.
Open skill - /security-audit
Security audit skill. Use when asked to "audit security", "check for vulnerabilities", "security review", "pentest", or when evaluating code that handles auth, user input, secrets, or external data. Runs a phased scan covering OWASP Top 10 and STRIDE threat modeling.
Open skill - /using-termcanvas
Use when starting work in a TermCanvas-managed repo to route between direct work, Hydra, or a narrow TermCanvas skill.
Open skill

