# QA > > **Gemini CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — the automated review step in `/submit-for-review` must be done manually using the review-agent prompt in a separate session. - Skill: `lightbridgelab/qa-2` (Agent Skill) - Install (CLI): `npx skillmds@latest add lightbridgelab/qa-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/lightbridgelab/qa-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: LightbridgeLab (https://skillmd.com/u/lightbridgelab) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/lightbridgelab/qa-2 --- > **Gemini CLI:** This skill is triggered by description matching. State any arguments in your message. Sub-agent spawning is not supported — the automated review step in `/submit-for-review` must be done manually using the review-agent prompt in a separate session. --- ## What `/qa` does `/qa` has two modes: - **No argument** — show all issues awaiting QA. - **Numeric argument** — walk through QA review for a specific issue. --- ## Mode A — No argument: QA queue view Run: ``` gh issue list --label "ready-for-qa" --state open \ --json number,title,url,labels,milestone,assignees ``` Display as a numbered list. For each issue show: issue number, title, milestone (if set), and URL. If the list is empty, say: > "No issues are currently waiting for QA." Do not take any other action. --- ## Mode B — Numeric argument: Review a specific issue The argument is an issue number. Work through the following steps. ### Step 1 — Load context ``` gh issue view --json number,title,body,labels,url,comments ``` Display the issue title and body. Check whether `ready-for-qa` is currently applied to the issue. If it is **not** present, warn: > "Issue #N does not have the ready-for-qa label. It may not be deployed to preview yet. Continue anyway? (yes/no)" Wait. If the user says no, stop. --- ### Step 2 — Review prompt Say: > "Test this feature on the preview environment. When you're done, describe what you tested, what you found, and your verdict (pass or fail). Include screenshots if you have them — paste image links or drag-and-drop into GitHub directly." **Stop. Wait for the QA person's input. Do not proceed until they provide a verdict.** --- ### Step 3 — Post findings as issue comment Build a structured comment from their input: ``` ## QA Review **Verdict:** PASS (or FAIL) **What was tested:** **Findings:** **Screenshots:** ``` Show the comment to the user before posting. Ask: > "Post this to issue #N? (yes/no)" Wait for confirmation. On yes: ``` gh issue comment --body "" ``` On no, stop — do not post and do not apply labels. --- ### Step 4 — Apply verdict label Based on the verdict: **PASS:** ``` gh issue edit --add-label "qa-passed" --remove-label "ready-for-qa" ``` **FAIL:** Before applying labels, fetch the issue's current assignees: ``` gh issue view --json assignees ``` If one or more assignees are found, prepend the following line to the comment body (above the `## QA Review` heading) in the comment that was already posted: > cc @ — this issue needs attention. If there are multiple assignees, include one `cc @` per line. If the command errors or returns no results, omit the line silently. ``` gh issue edit --add-label "qa-failed" --remove-label "ready-for-qa" ``` If the `gh issue edit` command fails because a label does not exist in the repo, report the error and say: > "The label does not exist in this repository. Create it in GitHub Settings → Labels, then re-run `/qa ` from Step 4." Do not retry automatically. After applying labels, tell the user what was done: - On PASS: "Issue #N marked as QA passed. The developer can now close it or promote to production." - On FAIL: "Issue #N marked as QA failed. The developer will see the findings in the issue comments." --- ## Hard rules - Never close an issue — verdict recording and closure are separate concerns. - Never post the comment without showing it to the user first. - Never apply labels without user confirmation (the confirmation in Step 3 is the single gate for both posting the comment and applying labels). - Never merge, deploy, or take any action beyond labeling and commenting.