qa-check
Skill4 starsChanged 8 months agoMITView on GitHub
Run quality assurance checks on a deployed venture site
- Commits and pushes
3 other projects use a version of this.
Adopted by
Most recently taken up by
- Jeric1223/my-claude-skillstheir own version, first seen Oct 13, 2026
- nek1987/auto-agent-harnesstheir own version, first seen Oct 11, 2026
- Joshua-Palamuttam/workbench-templatetheir own version, first seen Mar 7, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- nek1987/auto-agent-harness★ 4same name
- Joshua-Palamuttam/workbench-template★ 3same name
- Jeric1223/my-claude-skills★ 1same name
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.
In this repository14 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- brand-setupSkill
- daily-digestSkill
- deploySkill
- ecosystem-scoutSkill
- process-approvalsSkill
- publish-contentSkill
- send-outreachSkill
- submit-for-approvalSkill
- venture-bootstrapSkill
- venture-health-checkSkill
- venture-intakeSkill
- venture-staffingSkill
- weekly-reviewSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. About 0 are common, 18 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈18
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Run a comprehensive QA check on a deployed venture site and generate a report.
- Distinctive: line 25
Read the venture's CLAUDE.md to understand:
- Very specific: line 31
Read docs/ in the venture repo for feature specs and expected behavior.
- Distinctive: line 33
Create the report directory if it doesn't exist:
- Distinctive: line 40
Start a preview of the deployed URL:
- Very specific: line 41
Use mcp__Claude_Preview__preview_start with the venture URL
- Distinctive: line 49
Check for redirects and verify final URL is correct.
- Very specific: line 58
Check console logs with mcp__Claude_Preview__preview_console_logs — flag any errors or warnings
- Very specific: line 59
Check network requests with mcp__Claude_Preview__preview_network — flag any failed requests (4xx, 5xx)
- Distinctive: line 82
Use realistic but clearly test data (e.g., "QA Test User", "qa-test@example.com")
- Distinctive: line 88
Test with invalid data:
- Distinctive: line 92
Verify validation messages appear
- Distinctive: line 111
Test at mobile width (375px):
- Distinctive: line 116
Check for horizontal overflow
- Distinctive: line 117
Verify navigation works (hamburger menu if applicable)
- Distinctive: line 119
Test at tablet width (768px):
- Distinctive: line 123
Test at desktop width (1024px):
- Very specific: line 129
Check page load metrics using mcp__Claude_Preview__preview_eval:
- Distinctive: line 134
Check for large resources:
- Very specific: line 146
Write the report to qa/reports/YYYY-MM-DD.md in the venture repo using the QA agent's output format
- Distinctive: line 152
If FAIL: Log critical issues so the builder agent can address them in the next cycle
- Distinctive: line 153
If PASS: Note in the venture's changelog that QA passed
- Distinctive: line 157
Stop the preview session
- Distinctive: line 158
Commit and push the QA report:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
QA Check — Run Quality Assurance on a Deployed Venture
Run a comprehensive QA check on a deployed venture site and generate a report.
Input
- Venture:
$ARGUMENTS.venture - URL:
$ARGUMENTS.url
Step 1: Prepare
- Read the venture's
CLAUDE.mdto understand:- What the site does
- Expected pages and routes
- API endpoints
- Known issues or limitations
- Read
docs/in the venture repo for feature specs and expected behavior. - Create the report directory if it doesn't exist:
mkdir -p $PROJECTS_DIR/$ARGUMENTS.venture/qa/reports
Step 2: Site Availability
- Start a preview of the deployed URL:
- Use
mcp__Claude_Preview__preview_startwith the venture URL - Take a screenshot of the homepage with
mcp__Claude_Preview__preview_screenshot
- Use
- Check HTTP status:
curl -s -o /dev/null -w "%{http_code}" $ARGUMENTS.url - Check for redirects and verify final URL is correct.
Step 3: Page-by-Page Review
For each major page/route on the site:
- Navigate to the page using
mcp__Claude_Preview__preview_clickor direct URL - Take a screenshot with
mcp__Claude_Preview__preview_screenshot - Get the DOM snapshot with
mcp__Claude_Preview__preview_snapshot - Check console logs with
mcp__Claude_Preview__preview_console_logs— flag any errors or warnings - Check network requests with
mcp__Claude_Preview__preview_network— flag any failed requests (4xx, 5xx)
Step 4: Link Validation
- From the DOM snapshot, extract all links (
<a href="...">) - Categorize them:
- Internal navigation links
- External links
- Anchor links
- CTA buttons
- Click each internal link and verify it loads correctly
- Flag any
href="#"placeholders - For external links, verify they resolve:
curl -s -o /dev/null -w "%{http_code}" {external_url}
Step 5: Form Testing
For each form on the site:
- Identify all form fields from the DOM snapshot
- Fill the form with valid test data using
mcp__Claude_Preview__preview_fill:- Use realistic but clearly test data (e.g., "QA Test User", "qa-test@example.com")
- Submit the form using
mcp__Claude_Preview__preview_click - Check for:
- Success feedback (toast, redirect, thank you message)
- Network request to API endpoint (should be 200)
- No console errors
- Test with invalid data:
- Empty required fields
- Invalid email format
- Very long strings (500+ characters)
- Verify validation messages appear
Step 6: Content Scan
Using the DOM snapshots collected, scan for:
- Placeholder text — Search for:
- "Lorem ipsum"
- "TODO", "FIXME", "HACK"
- "[Name]", "[Company]", "{placeholder}"
- "example.com" in visible text (not code)
- Fabricated content — Flag anything that looks fake:
- Testimonials with stock photo avatars
- Statistics without sources
- Company logos that don't match real companies
- Spelling and grammar — Note obvious errors
Step 7: Responsive Testing
- Test at mobile width (375px):
mcp__Claude_Preview__preview_resize with width=375- Take screenshot
- Check for horizontal overflow
- Verify navigation works (hamburger menu if applicable)
- Test at tablet width (768px):
- Take screenshot
- Check layout transitions
- Test at desktop width (1024px):
- Take screenshot
- Verify full layout
Step 8: Performance Check
- Check page load metrics using
mcp__Claude_Preview__preview_eval:JSON.stringify(performance.getEntriesByType('navigation')[0]) - Check for large resources:
performance.getEntriesByType('resource') .filter(r => r.transferSize > 500000) .map(r => ({ name: r.name, size: r.transferSize })) - Flag any resources over 500KB.
Step 9: Generate Report
- Compile all findings into a QA report
- Write the report to
qa/reports/YYYY-MM-DD.mdin the venture repo using the QA agent's output format - Set overall status:
- PASS — No critical issues, 0-2 minor warnings
- WARN — No critical issues but 3+ warnings
- FAIL — Any critical issue (broken pages, form failures, console errors, placeholder text)
- If FAIL: Log critical issues so the builder agent can address them in the next cycle
- If PASS: Note in the venture's changelog that QA passed
Step 10: Cleanup
- Stop the preview session
- Commit and push the QA report:
cd $PROJECTS_DIR/$ARGUMENTS.venture git add qa/reports/ git commit -m "QA report: $(date +%Y-%m-%d) — {PASS/WARN/FAIL}" git push
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

