Qa

Skill merllinsbeard/merlin-skills/skills/qa

Spec-first, skill-first, goal-first coding skill pack for Codex.

Install

npx -y skills add merllinsbeard/merlin-skills --skill qa

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Merlin-adapted QA gate for spec-kit/create-goal web coding. Use after implementation or before ship to verify behavior, run tests, collect browser proof, and fix in-scope bugs.

SKILL.md

2.6 KB, as published. Nobody here has run it

gstack-qa

Run the smallest rigorous QA loop for the active spec/goal. This skill is adapted from gstack QA, but it is standalone: do not call gstack runtime helpers, telemetry, browser daemons, review specialists, or gbrain.

When To Use

Use after implementation, before gstack-ship, or when the user asks whether the web app works.

Do not use as a replacement for tdd during implementation. If there is no implemented surface yet, route back to tdd or create-goal.

Inputs

Inspect, in order:

User's newest request and stated QA scope.
specs/<feature>/GOAL.md, then tasks.md, plan.md, and spec.md when present.
Existing test commands in package.json, Makefile, CI config, README, AGENTS.md, or repo-local docs.
Current git diff and recently changed files.
Existing QA reports, screenshots, Playwright traces, or release notes.

If the spec or goal is missing but the user wants autonomous QA for a feature, ask to run create-goal first unless the user explicitly says to QA the current diff only.

QA Loop

Define the acceptance checklist from the spec/goal. Keep it short and concrete.
Run the repo's relevant automated checks. Prefer existing scripts over inventing new commands.
For web behavior, use playwright-cli first. Use playwright-skill only when a reusable script is more appropriate.
Classify each finding as blocker, functional bug, regression risk, visual issue, or test gap.
Fix only in-scope bugs when the user asked for QA-and-fix. Keep fixes small and rerun the failing check after each fix.
Do not expand product scope during QA. If the spec is wrong or incomplete, report the spec gap instead of silently changing behavior.
Stop when all acceptance checks pass or when a blocker requires external input.

Evidence

Write or update a compact QA note next to the active feature when there is a spec directory:

specs/<feature>/qa-report.md

If there is no spec directory, report inline or use the repo's existing QA/report location.

The report should include:

scope tested;
commands run;
browser flows checked;
bugs found and fixed;
remaining risks or missing coverage;
final ship recommendation.

Output

End with:

QA Result: pass | pass-with-risks | blocked | fail
Evidence: <tests/browser/report paths>
Ship readiness: yes | no | needs user decision