full-qa-fix
Skill2 starsChanged 35 days agoMITView on GitHub
Orchestrator that fixes every bug found by /full-qa. Walks a full-app-qa session's MASTER_INDEX.md and, for each section that has bugs, spawns a serial sub-agent running /fix-bug-index on that section's INDEX.md. Verifies fixes with Playwright, then commits that section's changes. One commit per section.
- Reads credentials
- Commits and pushes
In this repository75 other files it gives its agents.
- acceptance-criteriaSkill
- architect-guideSkill
- architect-reviewSkill
- audit-fixerSkill
- avo-admin-expertSkill
- backend-services-expertSkill
- bug-hunt-allSkill
- bug-hunt-fixSkill
- bug-huntSkill
- build-feature-remoteSkill
- build-featureSkill
- codeSkill
- component-testSkill
- controller-expertSkill
- create-qa-documentSkill
- debugSkill
- devops-expertSkill
- execute-qaSkill
- feature-qaSkill
- fix-bug-indexSkill
- fix-honeybadgerSkill
- fix-spec-bugsSkill
- fix-system-testSkill
- frontend-expertSkill
- frontend-reviewSkill
- full-qaSkill
- full-reviewSkill
- green-ciSkill
- group-issuesSkill
- honeybadger-auditSkill
- ideateSkill
- impact-assessmentSkill
- improveSkill
- merge-mainSkill
- model-expertSkill
- model-testSkill
- native-bug-hunt-fixSkill
- native-bug-huntSkill
- page-speedSkill
- plan-questionsSkill
- planSkill
- plan-system-testsSkill
- policy-testSkill
- prdSkill
- prd-worktreeSkill
- product-questionSkill
- product-question-tldrSkill
- qa-branchSkill
- qa-testerSkill
- refactor-sweepSkill
- resolve-honeybadgerSkill
- resolve-issueSkill
- resolve-issuesSkill
- review-acceptance-criteriaSkill
- review-fixesSkill
- review-railsSkill
- rspec-test-expertSkill
- scale-reviewSkill
- service-testSkill
- settle-pr-reviewSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. About 0 are common, 4 are distinctive, and 14 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
14
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 18
A path to a
MASTER_INDEX.md: use it directly; the session dir is its parent. - Very specific: line 20
If no MASTER_INDEX.md can be located, stop with a clear message naming what you looked for.
- Very specific: line 28
After each section's sub-agent returns, the next thing you do — in the same response — is mark that section's task done and spawn the …
- Distinctive: line 39
If you feel the urge to write a sentence like any of these, instead spawn the next section's sub-agent.
- Very specific: line 43
Every non-skipped section in your TaskList shows completed or error → write FIX_ALL_SUMMARY.md, print the final recap, stop.
- Distinctive: line 50
If you reach this skill mid-run after a context compaction, or the user re-invokes it against a partially-fixed session:
- Very specific: line 61
If both retries fail, mark the section's task error with a one-line reason and move to the next section.
- Very specific: line 81
If not 200: start bin/dev in the background (it reads PORT= from .env) and wait until curl returns 200 (10–15s typical).
- Very specific: line 85
Read config/environments/development.rb and confirm the line ≈49 ENV["STAGING_MAGIC_LINK"] ||= "true" is present and uncommented.
- Very specific: line 101
Read MASTER_INDEX.md. Parse the ## Progress table.
- Distinctive: line 138
Do not ask the user to confirm.
- Very specific: line 213
Do not read the section's individual bug files or FIX_SUMMARY into your own context — you only need the one-line counts for the master …
- Distinctive: line 240
If the delta is empty (e.g.
- Very specific: line 255
Branch safety: before the first commit, check the current branch (git rev-parse --abbrev-ref HEAD).
- Very specific: line 260
If any section task remains pending, go back to Step 3.1 with the next section right now.
- Very specific: line 266
Only after every section task is completed or error:
- Very specific: line 270
Write to <session-dir>/FIX_ALL_SUMMARY.md.
- Very specific: line 341
After the last section: write FIX_ALL_SUMMARY.md, print the recap.
≈ “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
Full App QA Fix Command
You are the fix-side counterpart to /full-qa. Where /full-qa produced a full-app-qa-* session containing a MASTER_INDEX.md and one INDEX.md per feature section, this skill walks that session and fixes every reported bug, section by section. After each section's fixes are made and verified, you commit that section's changes as a single commit, then move to the next section.
This is a healthcare app. Fixes must be correct, minimal, and verified — not papered over. You delegate each section's fix-and-verify work to a fresh sub-agent so the orchestrator's context never fills with Playwright snapshots or code reads.
Argument
$ARGUMENTS
- Empty: auto-select the most recently modified
docs/bug-reports/full-app-qa-*/directory that contains aMASTER_INDEX.md. - A path to a
full-app-qa-*directory: use itsMASTER_INDEX.md. - A path to a
MASTER_INDEX.md: use it directly; the session dir is its parent.
If no MASTER_INDEX.md can be located, stop with a clear message naming what you looked for.
CRITICAL: Continuous Execution (Non-Negotiable)
This skill must run to completion in a single user invocation. The most common failure mode of orchestrator skills is stopping after one section and waiting for the user to say "continue." DO NOT DO THIS.
After each section's sub-agent returns, the next thing you do — in the same response — is mark that section's task done and spawn the sub-agent for the next pending section, until every non-skipped section in your TaskList is completed or error.
Banned phrasings (do not write any of these until the run is complete)
- "ready to continue?"
- "let me know if you want me to proceed"
- "I'll start the next section next"
- "should I continue?"
- "I'll pause here so you can review"
- "the next step would be to..."
If you feel the urge to write a sentence like any of these, instead spawn the next section's sub-agent.
Legitimate stop conditions (exhaustive — no others are valid)
- Every non-skipped section in your TaskList shows
completedorerror→ writeFIX_ALL_SUMMARY.md, print the final recap, stop. - The same hard environmental block occurs on three consecutive sections and cannot be auto-recovered (e.g., dev server unreachable after retries on three different section attempts) → write what's done clearly, stop.
"Wait for the user" is not a stop condition.
Resume-from-compaction / re-invocation
If you reach this skill mid-run after a context compaction, or the user re-invokes it against a partially-fixed session:
- Re-read
MASTER_INDEX.md. - A section counts as already fixed if its subdir contains a
FIX_SUMMARY.md(written by/fix-bug-index). Treat those ascompletedand do not re-run them. - Rebuild your TaskList from the remaining sections-with-bugs.
- Resume by spawning the next pending section's sub-agent. Do not ask the user "should I resume?" — you have enough info to act.
Retry policy for sub-agent failures
On any transient sub-agent failure (timeout, MCP error, browser crash, child skill error):
- Retry once immediately.
- Retry again after a 30-second wait.
- If both retries fail, mark the section's task
errorwith a one-line reason and move to the next section. - Never report run failure to the user unless an environmental block prevents progress on three consecutive sections.
Phase 0: Pre-flight
The sub-agents drive Playwright to verify fixes (via /bug-hunt-fix), so the dev server must be up.
Step 0.1: Base URL and dev server
This checkout may be the main repo (default port) or a /build-feature worktree with its own
server and database (PORT= in .env). Resolve the URL first — everything downstream,
including the sub-agent prompts, uses $BASE_URL.
BASE_URL="$(bin/dev-url)" # $PORT > PORT= in .env > 3000
curl -sk -o /dev/null -w "%{http_code}" "$BASE_URL" 2>/dev/null || echo "not running"If not 200: start bin/dev in the background (it reads PORT= from .env) and wait until curl returns 200 (10–15s typical). If after 60s the server is still unreachable, stop with: "Dev server failed to start. Run bin/dev in another terminal, then re-invoke."
Step 0.2: STAGING_MAGIC_LINK is true
Read config/environments/development.rb and confirm the line ≈49 ENV["STAGING_MAGIC_LINK"] ||= "true" is present and uncommented. If missing/commented, report the exact line to add/uncomment and stop — sub-agents need the dev-shortcut "Sign in now" button to authenticate.
Step 0.3: Print pre-flight summary
One line: "Pre-flight passed. Fixing bugs across <N> sections with reported bugs in <session-dir>." Do not ask the user to confirm. Proceed to Phase 1.
Phase 1: Locate the Session and Parse the Master Index
Step 1.1: Resolve the session
Per the Argument rules above, resolve to an absolute MASTER_INDEX.md path and its parent session directory. All section INDEX.md paths are relative to the session directory.
Step 1.2: Parse the Progress table
Read MASTER_INDEX.md. Parse the ## Progress table. Each row looks like:
| 01 | Client Management | done | admin, coordinator, ... | 0 | 3 | 4 | 1 | 8 | [01-client-management/](01-client-management/INDEX.md) |For each row extract:
number(e.g.01),title,status(e.g.done/pending/error)- the Total bug count (the column before the Subdir link)
- the Subdir INDEX.md path from the markdown link in the last column
Step 1.3: Determine which sections to fix
A section is in scope for fixing only if ALL of the following hold:
- Its
INDEX.mdfile actually exists on disk (resolve relative to the session dir). - Its parsed Total bug count is greater than 0 (a
donerow with Total0, or apending/–row, has no bugs to fix — skip it). - It is not skip-marked — the row line does NOT contain
[SKIP](case-insensitive),<!-- skip -->, or~~strikethrough~~. (Same skip conventions/fix-bug-indexhonors.) - Its subdir does NOT already contain a
FIX_SUMMARY.md(already fixed in a prior run — skip on resume).
Sections that are pending/error in the master index, have zero bugs, are skip-marked, or already carry a FIX_SUMMARY.md are excluded and recorded in the plan as skipped (with the reason).
Step 1.4: Preserve order
Process sections in numeric order (01, 02, …) — same order they appear in the Progress table.
Phase 2: Plan and Create the TaskList
Print a concise plan to the user:
- Session dir being processed
- Total sections in the master index
- Count to fix (sections with bugs, not skipped, not already fixed), with their numbers/titles and bug totals
- Count skipped, with reasons (no bugs / skip-marked / already fixed / INDEX missing)
Then immediately create a TaskList — one task per in-scope section, in numeric order. Use TaskCreate with titles like Fix-all section 01: Client Management (8 bugs). The TaskList is your loop state — it is how you know what is left when control returns from a sub-agent.
Do not ask the user to confirm. Proceed directly into Phase 3.
Phase 3: The Per-Section Fix Loop
Work through the TaskList one section at a time, in numeric order.
Step 3.1: Mark the section task in_progress
TaskUpdate the section task you are about to work on so the live TaskList shows which section is being fixed right now.
Step 3.2: Delegate the section to a sub-agent — MANDATORY
First, capture the git baseline so Step 3.5 can scope the commit to only this section's changes:
git status --porcelain > /tmp/full-qa-fix-before-NN.txtWhy a sub-agent: /fix-bug-index invokes /bug-hunt-fix once per bug, and each /bug-hunt-fix reads many code files and drives Playwright (accessibility snapshots can be 50K–400K characters). Running that inline in the orchestrator would exhaust the context window after one or two sections. The Agent tool exists exactly to protect the main context from these results.
Concurrency rule (CRITICAL): Playwright MCP is a single shared browser session. Sub-agents that drive Playwright must run serially — call Agent synchronously (do not set run_in_background: true). Concurrent agents will collide on the browser and corrupt each other's verification state.
How to spawn:
Agent(
description: "Fix-all section NN: <title>",
subagent_type: "general-purpose",
prompt: <the self-contained brief below>
)Self-contained agent prompt template (substitute the bracketed values):
You are the bug-fix execution agent for ONE feature section of a /full-qa-fix run.
CONTEXT:
- Section: [NN] — "[section title]"
- Section bug index (absolute path): [absolute path to docs/bug-reports/full-app-qa-TS/NN-slug/INDEX.md]
- This index lists [Total] bugs across severity buckets, plus any observations.
- Dev server is running at [the $BASE_URL from Step 0.1 — substitute the literal URL here] and STAGING_MAGIC_LINK=true, so the dev-shortcut "Sign in now" button is available after submitting the email on /passwordless/users/sign_in.
YOUR JOB (end-to-end):
1. Invoke the /fix-bug-index skill via the Skill tool, passing the absolute path to this section's INDEX.md as the argument.
2. /fix-bug-index will loop over every non-skipped bug and observation in the index, invoke /bug-hunt-fix on each (which fixes the code and verifies with Playwright), and finally write a FIX_SUMMARY.md into this section's subdirectory. Let it run to completion — do not stop it early.
3. After /fix-bug-index finishes, read the FIX_SUMMARY.md it wrote and extract the counts (Fixed / Attempted / Failed / Skipped).
CONTEXT DISCIPLINE (CRITICAL — you must follow these to fit):
- Do NOT take full-tree Playwright snapshots; use depth-limited snapshots (depth 4-6) and target=<ref> scoping, as /bug-hunt-fix and its children already do.
- Do NOT pull large file contents or Playwright output into a final message.
RETURN VALUE (this is what the orchestrator sees — keep it under 4 lines):
"Section [NN]: Fixed <f> | Attempted <a> | Failed <x> | Skipped <s>. Summary: [absolute path to that section's FIX_SUMMARY.md]"
ERROR HANDLING:
- If /fix-bug-index errors before writing a summary, retry it once, then once more after 30 seconds. After the second failure, return:
"Section [NN]: ERROR — <one-line reason>. No FIX_SUMMARY written."
NEVER:
- Run git commit / push / reset / stash / add. Leave the working tree dirty.
- Modify any skill file (/full-qa-fix, /fix-bug-index, /bug-hunt-fix).
- Edit the MASTER_INDEX.md or any INDEX.md (only /bug-hunt-fix's own bug-file edits and FIX_SUMMARY.md are allowed, and the child skill handles those).
- Commit, and do NOT close the browser at the end — the next section's agent reuses the session. (/bug-hunt-fix may close it during its own cleanup; that is fine, the next agent re-authenticates.)
- Spawn additional sub-agents — you ARE the sub-agent.Step 3.3: Parse the sub-agent's return value
The agent's final message will be one of:
Section NN: Fixed f | Attempted a | Failed x | Skipped s. Summary: <path>→ success. Capture the counts.Section NN: ERROR — <reason>. No FIX_SUMMARY written.→ apply the retry policy; if still failing, mark the section taskerrorand continue.
Do not read the section's individual bug files or FIX_SUMMARY into your own context — you only need the one-line counts for the master rollup.
Step 3.4: Mark the section task completed (or error)
- Success line →
TaskUpdatethe section task tocompleted, recording the counts in your tracking. - ERROR line (after retries) →
TaskUpdatetoerrorwith a one-line reason. Skip the commit step for an errored section (there may be partial, unverified changes — leave them for the user) and continue to the anti-stop check.
Step 3.5: Commit this section's changes
After a section completes successfully, commit exactly the files that changed during this section's run — and nothing else. The working tree is dirty with unrelated noise (other untracked docs/bug-reports/* directories from prior runs, stray .yml files, etc.); a blanket git add -A would sweep that junk in. Scope the commit precisely using a before/after snapshot.
Before spawning the section's sub-agent (back in Step 3.2), capture the baseline:
git status --porcelain > /tmp/full-qa-fix-before-NN.txtNow, after the sub-agent returns successfully, capture the current state and commit only the delta:
git status --porcelain > /tmp/full-qa-fix-after-NN.txt
# Paths that are new or newly-changed relative to the baseline:
comm -13 <(sort /tmp/full-qa-fix-before-NN.txt) <(sort /tmp/full-qa-fix-after-NN.txt) \
| sed 's/^...//' > /tmp/full-qa-fix-delta-NN.txtThen:
- If the delta is empty (e.g. every bug was skipped or failed with no edits), skip the commit — there is nothing to commit. Note "no changes" in your tracking and continue.
- Otherwise, stage exactly those paths and commit:
Substitute the real section number, title, and counts. The delta naturally includes the code fixes, the per-bug "Fix Applied" edits, and that section'sgit add --pathspec-from-file=/tmp/full-qa-fix-delta-NN.txt git commit -m "$(cat <<'EOF' fix(qa): section NN <title> — <f> fixed, <a> attempted Bug fixes from /full-qa-fix for section NN of MASTER_INDEX.md. Verified via /fix-bug-index → /bug-hunt-fix (Playwright). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> EOF )"FIX_SUMMARY.md, while excluding pre-existing untracked junk. - Branch safety: before the first commit, check the current branch (
git rev-parse --abbrev-ref HEAD). If it is the default branch (main), create and switch to a working branch first (e.g.qa-fixes-<session-timestamp>). On any non-default branch, commit in place. - Never
git push,git reset, orgit stash. Committing locally is the only git-write action; pushing is the user's call.
Step 3.6: Anti-stop check
If any section task remains pending, go back to Step 3.1 with the next section right now. Do not pause, summarize, ask the user, or write the rollup.
Phase 4: Final Rollup
Only after every section task is completed or error:
Step 4.1: Write FIX_ALL_SUMMARY.md
Write to <session-dir>/FIX_ALL_SUMMARY.md. Keep it short — it is an index over the per-section FIX_SUMMARY.md files, not a restatement of them.
# Full App QA — Fix Rollup
**Source session:** MASTER_INDEX.md
**Date:** [YYYY-MM-DD HH:MM local]
**Sections fixed:** X of Y in-scope (Z skipped, E errored)
## Totals
| Outcome | Count |
|---------|-------|
| Fixed | F |
| Attempted (not verified) | A |
| Failed | X |
| Skipped (within sections) | S |
## By Section
| # | Section | Fixed | Attempted | Failed | Skipped | Summary |
|---|---------|-------|-----------|--------|---------|---------|
| 01 | Client Management | 6 | 1 | 1 | 0 | [FIX_SUMMARY](01-client-management/FIX_SUMMARY.md) |
| ... |
## Errored Sections
- **NN — <title>** — <one-line reason> (no FIX_SUMMARY written)
## Skipped Sections
- **NN — <title>** — <reason: no bugs / [SKIP] / already fixed / INDEX missing>
---
## Commits
Each fixed section was committed as one local commit (`fix(qa): section NN ...`) on branch `<branch>`. Nothing was pushed. Review with `git log --oneline` / `git diff origin/main`, then push or amend as you see fit. Errored sections (if any) left their partial changes uncommitted — review those with `git status`.Step 4.2: Final message to the user
Two lines:
Full-QA-Fix done. Sections fixed: X | Skipped: Z | Errors: E | Bugs fixed: F | Attempted: A | Failed: XnRollup: <session-dir>/FIX_ALL_SUMMARY.md — X commits on <branch>, nothing pushed
Important Guidelines
- Commit once per section, scoped to that section's changes only. Use the before/after
git statusdelta so unrelated untracked files (other bug-report dirs, stray.ymls) are never swept in. Nevergit push,git reset, orgit stash— local commits only; pushing is the user's call. The sub-agents themselves never commit; the orchestrator commits at the section boundary so each commit is atomic and follows verification. - One sub-agent per section. The sub-agent runs
/fix-bug-indexfor the whole section; that child loops over bugs via/bug-hunt-fix. Do not spawn a sub-agent per bug, and do not run/fix-bug-indexinline in the orchestrator. - Sub-agents run serially. Playwright is a single shared browser — never
run_in_background: truefor these. - The orchestrator never drives Playwright and never reads bug files. It reads only the one-line summary each sub-agent returns. This is what keeps the run inside the context budget.
- Respect skip markers exactly as
/fix-bug-indexdefines them:[SKIP],<!-- skip -->,~~strikethrough~~— applied here at the section-row level inMASTER_INDEX.md. - Skip sections with zero bugs and sections still
pending/errorin the master index — there is nothing to fix. - Resume is automatic. A section with a
FIX_SUMMARY.mdis already done; skip it. - Process sections in numeric order.
- Keep going on failures. One section erroring does not abort the batch.
- Never write the banned phrasings until the run is complete.
Execution Flow (Summary)
- Pre-flight (dev server,
STAGING_MAGIC_LINK). - Resolve session dir +
MASTER_INDEX.mdfrom$ARGUMENTS(or most-recent session). - Parse the Progress table → sections, totals, INDEX.md paths.
- Filter to sections with bugs that aren't skip-marked or already fixed.
- Print plan;
TaskCreateone task per in-scope section in numeric order. - Loop: while any section task is
pending: snapshot the git baseline, markin_progress, spawn a serialgeneral-purposesub-agent that runs/fix-bug-indexon that section's INDEX.md and returns ONE LINE of counts, parse it, markcompleted/error, commit that section's delta (one commit per section, scoped via the before/aftergit statusdiff), immediately continue to the next section. - After the last section: write
FIX_ALL_SUMMARY.md, print the recap. Each section's fixes are already committed; nothing is pushed.
Why this fits in context: the orchestrator spawns ~one sub-agent per section (typically 20–30) and reads ~one line back from each. Each sub-agent gets a fresh context for one /fix-bug-index run — and all the /bug-hunt-fix code reads and Playwright snapshots stay inside that sub-agent. The orchestrator's running cost is ~30 short summaries plus scaffolding.
Anti-stop checklist (run after every sub-agent returns)
- Did I parse the sub-agent's one-line counts (or ERROR sentinel)?
- Did I mark the current section task
completed(orerror)? - Did I commit this section's delta (scoped via the before/after
git statusdiff), or correctly skip the commit (errored section, or empty delta)? - Are there any
pendingsection tasks left? - If yes → snapshot the next section's git baseline and spawn its sub-agent RIGHT NOW. Do not summarize, do not ask, do not write the rollup.
- If no → write
FIX_ALL_SUMMARY.mdand print the recap.
Begin by running the Phase 0 pre-flight.
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.

