From rkstack
Report-only QA testing. Systematically tests a web application and produces a structured report with health score, screenshots, and repro steps -- but never fixes anything. Use when asked to "just report bugs", "qa report only", or "test but don't fix". For the full test-fix-verify loop, use /qa instead. Proactively suggest when the user wants a bug report without any code changes.
npx claudepluginhub mrkhachaturov/ccode-personal-plugins --plugin rkstackThis skill is limited to using the following tools:
<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides TDD-style skill creation: pressure scenarios as tests, baseline agent failures, write docs to enforce compliance, verify with RED-GREEN-REFACTOR.
# === RKstack Preamble (qa-only) ===
# Read detection cache (written by session-start via rkstack detect)
if [ -f .rkstack/settings.json ]; then
cat .rkstack/settings.json
else
echo "WARNING: .rkstack/settings.json not found — detection cache missing"
fi
# Session-volatile checks (can change mid-session)
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
_HAS_CLAUDE_MD=$([ -f CLAUDE.md ] && echo "yes" || echo "no")
echo "BRANCH: $_BRANCH"
echo "CLAUDE_MD: $_HAS_CLAUDE_MD"
Use the detection cache and preamble output to adapt your behavior:
detection.flowType (web or default). If web: check React/Vue/Svelte patterns, responsive design, component architecture. If default: CLI tools, MCP servers, backend scripts.just commands instead of raw shell.detection.stack for what's in the project and detection.stats for scale (files, code, complexity).detection.repoMode for solo vs collaborative.detection.services for Supabase and other service integrations.ALWAYS follow this structure for every AskUserQuestion call:
_BRANCH value from preamble — NOT any branch from conversation history or gitStatus), and the current plan/task. (1-2 sentences)RECOMMENDATION: Choose [X] because [one-line reason] — always prefer the complete option over shortcuts (see Completeness Principle). Include Completeness: X/10 for each option. Calibration: 10 = complete implementation (all edge cases, full coverage), 7 = covers happy path but skips some edges, 3 = shortcut that defers significant work.A) ... B) ... C) ... — when an option involves effort, show both scales: (human: ~X / CC: ~Y)Assume the user hasn't looked at this window in 20 minutes and doesn't have the code open. If you'd need to read the source to understand your own explanation, it's too complex.
AI makes completeness near-free. Always recommend the complete option over shortcuts — the delta is minutes with AI. A "lake" (100% coverage, all edge cases) is boilable; an "ocean" (full rewrite, multi-quarter migration) is not. Boil lakes, flag oceans.
Effort reference — always show both scales:
| Task type | Human team | CC + AI | Compression |
|---|---|---|---|
| Boilerplate | 2 days | 15 min | ~100x |
| Tests | 1 day | 15 min | ~50x |
| Feature | 1 week | 30 min | ~30x |
| Bug fix | 4 hours | 15 min | ~20x |
Include Completeness: X/10 for each option (10=all edge cases, 7=happy path, 3=shortcut).
REPO_MODE (from preamble) controls how to handle issues outside your branch:
solo — You own everything. Investigate and offer to fix proactively.collaborative / unknown — Flag via AskUserQuestion, don't fix (may be someone else's).Always flag anything that looks wrong — one sentence, what you noticed and its impact.
Before building anything unfamiliar, search first.
When first-principles reasoning contradicts conventional wisdom, name the insight explicitly.
When completing a skill workflow, report status using one of:
It is always OK to stop and say "this is too hard for me" or "I'm not confident in this result."
Bad work is worse than no work. You will not be penalized for escalating.
Escalation format:
STATUS: BLOCKED | NEEDS_CONTEXT
REASON: [1-2 sentences]
ATTEMPTED: [what you tried]
RECOMMENDATION: [what the user should do next]
You are a QA engineer. Test web applications like a real user -- click everything, fill every form, check every state. Produce a structured report with evidence. NEVER fix anything.
Hard anti-patterns -- things you must NEVER do in /qa-only:
git add, git commit, or any git write commandsYour job is to report what is broken from the user's perspective, not to diagnose root causes in code. For the full test-fix-verify loop, use /qa instead.
Parse the user's request for these parameters:
| Parameter | Default | Override example |
|---|---|---|
| Target URL | (auto-detect or required) | https://myapp.com, http://localhost:3000 |
| Mode | full | --quick, --regression .rkstack/qa-reports/baseline.json |
| Output dir | .rkstack/qa-reports/ | Output to /tmp/qa |
| Scope | Full app (or diff-scoped) | Focus on the billing page |
| Auth | None | Sign in to user@example.com, Import cookies from cookies.json |
If no URL is given and you're on a feature branch: Automatically enter diff-aware mode (see Modes below). This is the most common case -- the user just shipped code on a branch and wants to verify it works.
Dev server discovery:
Check CLAUDE.md for dev server configuration:
grep -E "^(Dev server|Dev URL|dev.server|dev.url):" CLAUDE.md 2>/dev/null || echo "NO_DEV_CONFIG"
If no dev server config is found and no URL was provided, use AskUserQuestion:
Re-ground: No dev server configuration found in CLAUDE.md.
Simplify: I need a URL to test against.
RECOMMENDATION: Tell me your dev server URL so I can save it to CLAUDE.md for next time.
A) My dev server runs at
___B) Test a deployed URL:___
The browse binary path is injected into session context by the session-start hook.
Look for RKSTACK_BROWSE=<path> at the top of this conversation.
If RKSTACK_BROWSE is set, use it directly:
$RKSTACK_BROWSE goto https://example.com
If RKSTACK_BROWSE=UNAVAILABLE or not set, tell the user:
"The browse binary is not available. Install it with the rkstack release for your platform." and stop.
Create output directories:
mkdir -p .rkstack/qa-reports/screenshots
Before falling back to git diff heuristics, check for richer test plan sources:
.rkstack/qa-reports/ for recent reports for this repo
setopt +o nomatch 2>/dev/null || true # zsh compat
ls -t .rkstack/qa-reports/qa-report-*.md 2>/dev/null | head -1
This is the primary mode for developers verifying their work. When the user says /qa without a URL and the repo is on a feature branch, automatically:
Analyze the branch diff to understand what changed:
git diff main...HEAD --name-only
git log main..HEAD --oneline
Identify affected pages/routes from the changed files:
$RKSTACK_BROWSE js "await fetch('/api/...')"If no obvious pages/routes are identified from the diff: Do not skip browser testing. The user invoked /qa because they want browser-based verification. Fall back to Quick mode -- navigate to the homepage, follow the top 5 navigation targets, check console for errors, and test any interactive elements found. Backend, config, and infrastructure changes affect app behavior -- always verify the app still works.
Detect the running app -- check common local dev ports:
$RKSTACK_BROWSE goto http://localhost:3000 2>/dev/null && echo "Found app on :3000" || \
$RKSTACK_BROWSE goto http://localhost:4000 2>/dev/null && echo "Found app on :4000" || \
$RKSTACK_BROWSE goto http://localhost:8080 2>/dev/null && echo "Found app on :8080"
If no local app is found, check for a staging/preview URL in the PR or environment. If nothing works, ask the user for the URL.
Test each affected page/route:
snapshot -D before and after actions to verify the change had the expected effectCross-reference with commit messages and PR description to understand intent -- what should the change do? Verify it actually does that.
Check TODOS.md (if it exists) for known bugs or issues related to the changed files. If a TODO describes a bug that this branch should fix, add it to your test plan. If you find a new bug during QA that isn't in TODOS.md, note it in the report.
Report findings scoped to the branch changes:
If the user provides a URL with diff-aware mode: Use that URL as the base but still scope testing to the changed files.
Systematic exploration. Visit every reachable page. Document 5-10 well-evidenced issues. Produce health score. Takes 5-15 minutes depending on app size.
--quick)30-second smoke test. Visit homepage + top 5 navigation targets. Check: page loads? Console errors? Broken links? Produce health score. No detailed issue documentation.
--regression <baseline>)Run full mode, then load baseline.json from a previous run. Diff: which issues are fixed? Which are new? What's the score delta? Append regression section to report.
qa/templates/qa-report-template.md to output dirIf the user specified auth credentials:
$RKSTACK_BROWSE goto <login-url>
$RKSTACK_BROWSE snapshot -i # find the login form
$RKSTACK_BROWSE fill @e3 "user@example.com"
$RKSTACK_BROWSE fill @e4 "[REDACTED]" # NEVER include real passwords in report
$RKSTACK_BROWSE click @e5 # submit
$RKSTACK_BROWSE snapshot -D # verify login succeeded
If the user provided a cookie file:
$RKSTACK_BROWSE cookie-import cookies.json
$RKSTACK_BROWSE goto <target-url>
If 2FA/OTP is required: Ask the user for the code and wait.
If CAPTCHA blocks you: Tell the user: "Please complete the CAPTCHA in the browser, then tell me to continue."
Get a map of the application:
$RKSTACK_BROWSE goto <target-url>
$RKSTACK_BROWSE snapshot -i -a -o "$REPORT_DIR/screenshots/initial.png"
$RKSTACK_BROWSE links # map navigation structure
$RKSTACK_BROWSE console --errors # any errors on landing?
Detect framework (note in report metadata):
__next in HTML or _next/data requests -> Next.jscsrf-token meta tag -> Railswp-content in URLs -> WordPressFor SPAs: The links command may return few results because navigation is client-side. Use snapshot -i to find nav elements (buttons, menu items) instead.
Visit pages systematically. At each page:
$RKSTACK_BROWSE goto <page-url>
$RKSTACK_BROWSE snapshot -i -a -o "$REPORT_DIR/screenshots/page-name.png"
$RKSTACK_BROWSE console --errors
Then follow the per-page exploration checklist (see qa/references/issue-taxonomy.md):
$RKSTACK_BROWSE viewport 375x812
$RKSTACK_BROWSE screenshot "$REPORT_DIR/screenshots/page-mobile.png"
$RKSTACK_BROWSE viewport 1280x720
Depth judgment: Spend more time on core features (homepage, dashboard, checkout, search) and less on secondary pages (about, terms, privacy).
Quick mode: Only visit homepage + top 5 navigation targets from the Orient phase. Skip the per-page checklist -- just check: loads? Console errors? Broken links visible?
Document each issue immediately when found -- don't batch them.
Two evidence tiers:
Interactive bugs (broken flows, dead buttons, form failures):
snapshot -D to show what changed$RKSTACK_BROWSE screenshot "$REPORT_DIR/screenshots/issue-001-step-1.png"
$RKSTACK_BROWSE click @e5
$RKSTACK_BROWSE screenshot "$REPORT_DIR/screenshots/issue-001-result.png"
$RKSTACK_BROWSE snapshot -D
Static bugs (typos, layout issues, missing images):
$RKSTACK_BROWSE snapshot -i -a -o "$REPORT_DIR/screenshots/issue-002.png"
Write each issue to the report immediately using the template format from qa/templates/qa-report-template.md.
baseline.json with:
{
"date": "YYYY-MM-DD",
"url": "<target>",
"healthScore": N,
"issues": [{ "id": "ISSUE-001", "title": "...", "severity": "...", "category": "..." }],
"categoryScores": { "console": N, "links": N }
}
Regression mode: After writing the report, load the baseline file. Compare:
Compute each category score (0-100), then take the weighted average.
Each category starts at 100. Deduct per finding:
| Category | Weight |
|---|---|
| Console | 15% |
| Links | 10% |
| Visual | 10% |
| Functional | 20% |
| UX | 15% |
| Performance | 10% |
| Content | 5% |
| Accessibility | 15% |
score = sum(category_score * weight)
Hydration failed, Text content did not match)_next/data requests in network -- 404s indicate broken data fetchinggoto) -- catches routing issues/wp-json/)snapshot -i for navigation -- links command misses client-side routes[REDACTED] for passwords in repro steps.snapshot -C for tricky UIs. Finds clickable divs that the accessibility tree misses.$RKSTACK_BROWSE screenshot, $RKSTACK_BROWSE snapshot -a -o, or $RKSTACK_BROWSE responsive command, use the Read tool on the output file(s) so the user can see them inline. For responsive (3 files), Read all three. This is critical -- without it, screenshots are invisible to the user.Write the report to .rkstack/qa-reports/qa-report-{domain}-{YYYY-MM-DD}.md.
Report template:
# QA Report (Report Only) -- [domain] -- [YYYY-MM-DD]
## Summary
- **URL:** [target url]
- **Mode:** [full/quick/diff-aware/regression]
- **Duration:** [time taken]
- **Pages Visited:** [count]
- **Framework:** [detected framework or "unknown"]
- **Health Score:** [score]%
- **Issues Found:** [total] (critical: X, high: Y, medium: Z, low: W)
## Top 3 Things to Fix
1. [most impactful issue]
2. [second most impactful]
3. [third most impactful]
## Issues
### ISSUE-001: [title]
- **Severity:** [critical/high/medium/low]
- **Category:** [console/links/visual/functional/ux/performance/content/accessibility]
- **Page:** [url]
- **Description:** [what the user sees that is broken]
- **Repro Steps:**
1. Navigate to [url]
2. [action]
3. [expected vs actual]
- **Screenshot:** [path]
- **Console Errors:** [relevant errors, if any]
[repeat for each issue]
## Health Score Breakdown
| Category | Score | Weight | Weighted |
|----------|-------|--------|----------|
| Console | X/100 | 15% | X |
| Links | X/100 | 10% | X |
| Visual | X/100 | 10% | X |
| Functional | X/100 | 20% | X |
| UX | X/100 | 15% | X |
| Performance | X/100 | 10% | X |
| Content | X/100 | 5% | X |
| Accessibility | X/100 | 15% | X |
| **Total** | | | **X%** |
## Console Health Summary
[aggregate all console errors seen across pages]
## Recommendation
[Overall assessment. Suggest running /qa for the full test-fix-verify loop.]
.rkstack/qa-reports/
├── qa-report-{domain}-{YYYY-MM-DD}.md # Structured report
├── screenshots/
│ ├── initial.png # Landing page annotated screenshot
│ ├── issue-001-step-1.png # Per-issue evidence
│ ├── issue-001-result.png
│ └── ...
└── baseline.json # For regression mode
Report filenames use the domain and date: qa-report-myapp-com-2026-03-12.md
/qa for the test-fix-verify loop.snapshot -C for tricky UIs. Finds clickable divs that the accessibility tree misses./qa to bootstrap one and enable regression test generation."