# Full Qa

> Generic autonomous QA suite for any project — reads a test plan (markdown file or inline spec), runs all tests using Chrome CDP + iterate cycles, fixes bugs found, and produces a final QA report. Works with any web stack. Trigger with /full-qa [path-to-test-plan.md]. Use before releases, after significant changes, or whenever you want a full system health check.

- **Type:** Skill
- **Install:** `agentstack add skill-devotts-fable-it-full-qa`
- **Verified:** Pending review
- **Seller:** [DevOtts](https://agentstack.voostack.com/s/devotts)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [DevOtts](https://github.com/DevOtts)
- **Source:** https://github.com/DevOtts/fable-it/tree/main/plugins/fable-it/skills/full-qa

## Install

```sh
agentstack add skill-devotts-fable-it-full-qa
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## 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:
1. **Service URLs** — all `localhost:PORT` or external URLs mentioned
2. **Auth credentials** — any test user emails/passwords
3. **Test cases** — each scenario with its ID, steps, and pass criteria
4. **Setup steps** — any DB resets, seed commands, or imports required before tests
5. **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:
```bash
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

```bash
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

```bash
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 seed`
- `python 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:

1. Print `▶ Running [TEST_ID] — [Test Name]`
2. Execute all steps (API calls, DB queries, or browser actions — see section below)
3. Evaluate pass/fail criteria
4. Print result: `✓ PASS [TEST_ID]` or `✗ FAIL [TEST_ID] — [reason]`
5. 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)
```bash
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 `Explore` subagent 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 FROM` without 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)
```bash
# 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
```bash
# 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
```bash
# Health
curl -s http://localhost:PORT/health
# Logs
tail -50 /engine.log
```

### FastAPI / Python
```bash
# 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
```bash
# Django: python manage.py check; Rails: bin/rails db:migrate:status; Laravel: php artisan migrate:status
```

### Chrome CDP (canonical action template)
```bash
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](https://github.com/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](https://github.com/DevOtts)
- **Source:** [DevOtts/fable-it](https://github.com/DevOtts/fable-it)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** yes
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: flagged — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-devotts-fable-it-full-qa
- Seller: https://agentstack.voostack.com/s/devotts
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.