Install
$ agentstack add skill-devotts-fable-it-full-qa Open-source listing, not yet scanned by AgentStack. Follow the source repository for install instructions.
Security review
⚠ Flagged1 finding(s); flagged for manual review. · v0.1.0 How review works →
- • Prompt-injection patterns
- • Secret / credential exfiltration
- • Dangerous shell & filesystem operations
- • Untrusted network calls
- • Known-malicious package signatures
- high Destructive filesystem operation.
What it can access
- ● Network access Used
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
/full-qa — Autonomous Full QA Suite
You are running an autonomous, project-agnostic QA pipeline. You read a test plan, execute every test, fix bugs as you find them, and deliver a final pass/fail report — without stopping between steps unless a destructive or truly ambiguous action requires confirmation.
This skill incorporates Chrome CDP browser control and iterative bug-fix cycles natively. You do not need to invoke /chrome-cdp-control or /iterate separately.
Step 0 — INGEST THE TEST PLAN
First action: identify the test plan.
- If the user passed a file path (e.g.,
/full-qa ./E2E-test-plan.md), read that file immediately. - If the user pasted tests inline, extract them from the conversation.
- If neither: ask the user ONE question: "Where is the test plan? Paste it or give me a file path."
From the test plan, extract:
- Service URLs — all
localhost:PORTor external URLs mentioned - Auth credentials — any test user emails/passwords
- Test cases — each scenario with its ID, steps, and pass criteria
- Setup steps — any DB resets, seed commands, or imports required before tests
- Stack info — language, framework, DB type (for tailoring fix strategies)
If any of these are missing from the plan, infer reasonable defaults and state your assumptions before starting Phase 1.
Phase 1 — PREFLIGHT
Verify every service the test plan references is alive. Do this silently and fix anything that is down before proceeding.
1.1 Service health checks
For each URL in the test plan:
curl -s -o /dev/null -w "%{http_code}" /health
# or if no /health endpoint:
curl -s -o /dev/null -w "%{http_code}"
Expected: 200 (or the status code the plan specifies). Any non-200 is a failure to investigate.
1.2 Chrome CDP check
curl -s http://localhost:9222/json/version | python3 -c "import sys,json; d=json.load(sys.stdin); print('Chrome:', d.get('Browser','?'))"
If CDP fails, output exactly this and stop: > Chrome isn't running with remote debugging. Please launch it with: > ``bash > "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \ > --remote-debugging-port=9222 \ > --user-data-dir="$HOME/.chrome-automation" \ > --no-first-run & > `` > Then run /full-qa again.
1.3 Playwright check
python3 -c "import playwright; print('playwright ok')" 2>&1 || pip3 install playwright && python3 -m playwright install chromium
1.4 Preflight report
Print a compact table before moving on:
PREFLIGHT
✓ Service A http://localhost:XXXX 200
✓ Service B http://localhost:YYYY 200
✓ Chrome CDP localhost:9222 Chrome/XXX
✗ Service C http://localhost:ZZZZ ECONNREFUSED ← fixing...
Do not proceed to Phase 2 if any service is down after your fix attempt.
Phase 2 — SETUP / CLEAN SLATE
Run any setup steps from the test plan: DB resets, seed imports, migrations, fixture loading.
If the test plan has no explicit setup steps, check for common patterns:
docker exec ... psql(Postgres via Docker/Supabase)npm run seed/yarn seedpython manage.py migrate && loaddata- REST API seed endpoints (POST /seed, POST /admin/reset)
Important: If setup involves destructive operations (DROP, DELETE ALL, reset), print exactly what you're about to run and wait for a "yes" from the user before executing. Exception: if the test plan explicitly says "clean slate required", proceed without confirming.
After setup, verify the expected baseline state (row counts, seed user logins, etc.) using whatever the test plan specifies. If not specified, verify at minimum that auth works for the first test credential listed.
Phase 3 — TEST EXECUTION
Run every test case from the plan, in order. For each test:
- Print
▶ Running [TEST_ID] — [Test Name] - Execute all steps (API calls, DB queries, or browser actions — see section below)
- Evaluate pass/fail criteria
- Print result:
✓ PASS [TEST_ID]or✗ FAIL [TEST_ID] — [reason] - On FAIL: immediately enter the Bug Fix Cycle (Phase 4) before moving to the next test — unless the plan says to collect all failures first
API-only tests (curl + DB)
Use curl for REST/GraphQL endpoints and psql/sqlite3/mysql for DB verification. Collect concrete evidence — response bodies and row counts — not assumptions.
Browser tests (UI interactions)
Use this exact CDP loop. Every browser action follows this 5-step sequence — no exceptions:
Step 1 — Screenshot (see current state)
python3
HYPOTHESIS:
EVIDENCE:
FIX PLAN:
Rules:
- Read logs, check DB state, inspect API responses before touching code
- Form a hypothesis. Verify it with one targeted check before acting.
- Spawn an
Exploresubagent for broad codebase research (tracing data flows across >3 files). Keep yourself for reasoning.
FIX
- Change only what the diagnosis identified — no refactoring, no "while I'm here" cleanups
- If fix spans multiple files, apply all before re-testing
- If fix requires a service restart, wait for the startup confirmation message before re-testing
TEST
Re-run the specific test that failed. Collect concrete evidence: | Task type | Verification method | |-----------|-------------------| | API route | curl the route, check response code + body | | DB state | Query the specific table/row | | UI behavior | Screenshot + check URL + check text content | | Compilation | Run tsc --noEmit or the project's build command |
EVALUATE
RESULT: PASS | FAIL | PARTIAL
EVIDENCE:
REMAINING ISSUES:
NEXT ACTION: continue tests | new diagnosis cycle | escalate to user
Escalation rules
- After 3 distinct diagnosis attempts on the same bug → escalate to user with full diagnosis history
- If fix requires a product decision (e.g., "should this return 400 or silently default?") → escalate
- If fix requires a DB migration with DROP/ALTER → escalate before running
Regression check
After fixing any bug: re-run any previously-PASS test that touches the same service/component. A fix that breaks something else is worse than a known failure.
Phase 5 — EXPLORATORY TESTS
After all plan-specified tests complete, spawn an Explore subagent to find untested paths:
Explore subagent prompt:
"In [PROJECT_ROOT], identify likely bug-prone areas not covered by the existing tests.
Focus on:
- Unguarded edge cases in service/controller layers
- Missing error handling in critical flows
- Data display issues in UI components
- Race conditions or state management issues
For each suspicious area, propose a concrete test (what to click or API to call),
the expected behavior, and the likely failure mode.
Return a ranked list of 5 tests with: ID, description, steps, expected result."
Implement the top 3-5 tests the subagent identifies. Apply the same PASS/FAIL pattern.
Phase 6 — FINAL REPORT
When all tests complete (or you've exhausted fix cycles), output:
## QA Report — [Project Name] — [Date]
### Summary
| Metric | Count |
|--------|-------|
| Tests run | N |
| Passed | N |
| Failed | N |
| Bugs fixed | N |
| Exploratory tests | N |
| Deferred | N |
### Test Results
| ID | Test Name | Result | Notes |
|-----|-----------|--------|-------|
| T01 | [Name] | ✓ PASS | |
| T02 | [Name] | ✗ FAIL | [what failed] |
| T03 | [Name] | ⚠ SKIP | [reason] |
### Bugs Fixed
| # | File:Line | Description | Fix Applied |
|---|-----------|-------------|-------------|
| 1 | src/foo.ts:42 | [what broke] | [what changed] |
### Known Issues / Deferred
- [Item]: [why deferred — needs product decision / out of scope / requires manual action]
### Go-Live Readiness
**READY** / **NOT READY** — [one sentence verdict]
Autonomy Rules
Proceed without asking:
- Running any test (curl, DB query, browser action) against localhost services
- Reading logs, source code, DB state
- Taking screenshots
- Applying code fixes for clearly-diagnosed bugs
- Restarting local services after a fix
- Creating test data (users, records, sessions) within the test environment
Stop and confirm before:
- Any write to a non-localhost / production service
- Running
DROP TABLE,DELETE FROMwithout a WHERE, or other destructive DB commands that aren't part of an explicit seed/reset step in the test plan - Pushing code changes (git push)
- Running migrations that alter shared schema structure (ADD COLUMN with NOT NULL default is ok, DROP COLUMN needs confirmation)
- Killing OS processes with
pkill(exception: killing a service you just started for a resilience test) - Taking any action on the user's logged-in accounts in external services
Maximum autonomy: Fix bugs without asking. Re-run tests without asking. Restart services without asking. Only escalate when you've genuinely tried 3 different approaches and are stuck, or when the fix requires a product decision.
Quick Reference: Common Stack Commands
Supabase / Postgres (Docker)
# DB query
docker exec supabase_db_supabase psql -U postgres -c "SELECT ..."
# Apply migration
docker exec -i supabase_db_supabase psql -U postgres " -H "Content-Type: application/json" \
-d '{"email":"user@example.com","password":"password"}'
Next.js
# Build check
cd && npm run build 2>&1 | tail -20
# Type check
npx tsc --noEmit
# Logs (if running via pm2 or similar)
pm2 logs --lines 50
NestJS
# Health
curl -s http://localhost:PORT/health
# Logs
tail -50 /engine.log
FastAPI / Python
# Health
curl -s http://127.0.0.1:PORT/health
# Start if down
cd && python3 -m uvicorn main:app --host 127.0.0.1 --port PORT &
Django / Rails / Laravel
# Django: python manage.py check; Rails: bin/rails db:migrate:status; Laravel: php artisan migrate:status
Chrome CDP (canonical action template)
python3 << 'PYEOF'
import asyncio
from playwright.async_api import async_playwright
async def go():
pw = await async_playwright().start()
browser = await pw.chromium.connect_over_cdp('http://localhost:9222')
ctx = browser.contexts[0]
# List all tabs (always do this first)
for i, p in enumerate(ctx.pages):
print(i, p.url)
# Find target tab by URL fragment
page = next((p for p in ctx.pages if "TARGET_FRAGMENT" in p.url), None)
if page is None:
page = await ctx.new_page()
await page.goto("TARGET_URL", wait_until="domcontentloaded", timeout=30000)
# === ONE ACTION HERE ===
await page.wait_for_load_state("networkidle", timeout=15000)
await page.screenshot(path="/tmp/qa_action.png")
print("OK:", page.url)
await pw.stop()
asyncio.run(go())
PYEOF
Authored by DevOtts._
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: DevOtts
- Source: DevOtts/fable-it
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.