agentleFS
prateekjainprateekjain/ChiefOfStaff/skills/qa-check/SKILL.md

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

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
  1. Distinctive:

    Run a comprehensive QA check on a deployed venture site and generate a report.

    line 16
  2. Distinctive:

    Read the venture's CLAUDE.md to understand:

    line 25
  3. Very specific:

    Read docs/ in the venture repo for feature specs and expected behavior.

    line 31
  4. Distinctive:

    Create the report directory if it doesn't exist:

    line 33
  5. Distinctive:

    Start a preview of the deployed URL:

    line 40
  6. Very specific:

    Use mcp__Claude_Preview__preview_start with the venture URL

    line 41
  7. Distinctive:

    Check for redirects and verify final URL is correct.

    line 49
  8. Very specific:

    Check console logs with mcp__Claude_Preview__preview_console_logs — flag any errors or warnings

    line 58
  9. Very specific:

    Check network requests with mcp__Claude_Preview__preview_network — flag any failed requests (4xx, 5xx)

    line 59
  10. Distinctive:

    Use realistic but clearly test data (e.g., "QA Test User", "qa-test@example.com")

    line 82
  11. Distinctive:

    Test with invalid data:

    line 88
  12. Distinctive:

    Verify validation messages appear

    line 92
  13. Distinctive:

    Test at mobile width (375px):

    line 111
  14. Distinctive:

    Check for horizontal overflow

    line 116
  15. Distinctive:

    Verify navigation works (hamburger menu if applicable)

    line 117
  16. Distinctive:

    Test at tablet width (768px):

    line 119
  17. Distinctive:

    Test at desktop width (1024px):

    line 123
  18. Very specific:

    Check page load metrics using mcp__Claude_Preview__preview_eval:

    line 129
  19. Distinctive:

    Check for large resources:

    line 134
  20. Very specific:

    Write the report to qa/reports/YYYY-MM-DD.md in the venture repo using the QA agent's output format

    line 146
  21. Distinctive:

    If FAIL: Log critical issues so the builder agent can address them in the next cycle

    line 152
  22. Distinctive:

    If PASS: Note in the venture's changelog that QA passed

    line 153
  23. Distinctive:

    Stop the preview session

    line 157
  24. Distinctive:

    Commit and push the QA report:

    line 158

≈ “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.

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

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

  1. Read the venture's CLAUDE.md to understand:
    • What the site does
    • Expected pages and routes
    • API endpoints
    • Known issues or limitations
  2. Read docs/ in the venture repo for feature specs and expected behavior.
  3. Create the report directory if it doesn't exist:
    mkdir -p $PROJECTS_DIR/$ARGUMENTS.venture/qa/reports

Step 2: Site Availability

  1. Start a preview of the deployed URL:
    • Use mcp__Claude_Preview__preview_start with the venture URL
    • Take a screenshot of the homepage with mcp__Claude_Preview__preview_screenshot
  2. Check HTTP status:
    curl -s -o /dev/null -w "%{http_code}" $ARGUMENTS.url
  3. Check for redirects and verify final URL is correct.

Step 3: Page-by-Page Review

For each major page/route on the site:

  1. Navigate to the page using mcp__Claude_Preview__preview_click or direct URL
  2. Take a screenshot with mcp__Claude_Preview__preview_screenshot
  3. Get the DOM snapshot with mcp__Claude_Preview__preview_snapshot
  4. Check console logs with mcp__Claude_Preview__preview_console_logs — flag any errors or warnings
  5. Check network requests with mcp__Claude_Preview__preview_network — flag any failed requests (4xx, 5xx)

Step 4: Link Validation

  1. From the DOM snapshot, extract all links (<a href="...">)
  2. Categorize them:
    • Internal navigation links
    • External links
    • Anchor links
    • CTA buttons
  3. Click each internal link and verify it loads correctly
  4. Flag any href="#" placeholders
  5. 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:

  1. Identify all form fields from the DOM snapshot
  2. Fill the form with valid test data using mcp__Claude_Preview__preview_fill:
  3. Submit the form using mcp__Claude_Preview__preview_click
  4. Check for:
    • Success feedback (toast, redirect, thank you message)
    • Network request to API endpoint (should be 200)
    • No console errors
  5. Test with invalid data:
    • Empty required fields
    • Invalid email format
    • Very long strings (500+ characters)
  6. Verify validation messages appear

Step 6: Content Scan

Using the DOM snapshots collected, scan for:

  1. Placeholder text — Search for:
    • "Lorem ipsum"
    • "TODO", "FIXME", "HACK"
    • "[Name]", "[Company]", "{placeholder}"
    • "example.com" in visible text (not code)
  2. Fabricated content — Flag anything that looks fake:
    • Testimonials with stock photo avatars
    • Statistics without sources
    • Company logos that don't match real companies
  3. Spelling and grammar — Note obvious errors

Step 7: Responsive Testing

  1. 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)
  2. Test at tablet width (768px):
    • Take screenshot
    • Check layout transitions
  3. Test at desktop width (1024px):
    • Take screenshot
    • Verify full layout

Step 8: Performance Check

  1. Check page load metrics using mcp__Claude_Preview__preview_eval:
    JSON.stringify(performance.getEntriesByType('navigation')[0])
  2. Check for large resources:
    performance.getEntriesByType('resource')
      .filter(r => r.transferSize > 500000)
      .map(r => ({ name: r.name, size: r.transferSize }))
  3. Flag any resources over 500KB.

Step 9: Generate Report

  1. Compile all findings into a QA report
  2. Write the report to qa/reports/YYYY-MM-DD.md in the venture repo using the QA agent's output format
  3. 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)
  4. If FAIL: Log critical issues so the builder agent can address them in the next cycle
  5. If PASS: Note in the venture's changelog that QA passed

Step 10: Cleanup

  1. Stop the preview session
  2. 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.