qa-plan

Draft two-phase QA plans from acceptance criteria into pull request bodies.

2|Updated May 13, 2026

Search Tags:#github #acceptance criteria #pull requests #qa planning #production checks #development verification

Ready to run

npx skills add https://github.com/mujtaba3B/gstack-extensions --skill qa-plan-mujtaba3b

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: qa-plan
Source: https://github.com/mujtaba3B/gstack-extensions/tree/main/qa/skills/qa-plan
Command: npx skills add https://github.com/mujtaba3B/gstack-extensions --skill qa-plan-mujtaba3b

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill turns a change's acceptance criteria into a structured two-phase QA plan before a pull request is reviewed or merged. It helps teams avoid vague test notes by separating merge-blocking development checks from post-deploy production checks.

Core Features & Use Cases

Acceptance-criteria mapping: Converts Given/When/Then or EARS statements into checkable QA rows.
Two-phase coverage: Builds Development QA for preview or local validation and Production QA for live verification after deploy.
PR-body automation: Writes or updates the QA section in the pull request, includes a QA driver, production artifacts, and approval posture.
Approval flow: Presents the plan for human review, then stamps approval only when explicitly approved.
Use case: Use it when a feature, bug fix, or UI change needs a clear QA plan that gates merge and release.

Quick Start

Ask me to write the QA plan for the current pull request and I will turn the acceptance criteria into a two-phase QA section in the PR body.

Frequently Asked Questions about qa-plan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I turn acceptance criteria into a pull request QA plan?▼

To turn acceptance criteria into a pull request QA plan, map Given/When/Then or EARS statements into checkable QA rows. This structures validation into Development checks for local preview and Production checks for post-deploy smoke tests directly in the PR body.

What is a two-phase QA plan for GitHub pull requests?▼

A two-phase QA plan for GitHub pull requests separates merge-blocking development verification from post-deploy production verification. It translates acceptance criteria into UI flow checks, backend side effect validations, and live smoke tests to gate releases.

How do I automate QA section updates in a pull request body?▼

You automate QA section updates in a pull request body using idempotent PR-body updates. The plan writes development and production verification steps, includes a QA driver, names production artifacts, and tracks approval posture metadata.

Does this QA planning approach require manual approval before merging?▼

Yes, this QA planning approach requires manual approval before merging. It presents the drafted plan for human review and only stamps approval when explicitly approved, using the QA posture metadata to gate merge and release workflows.

Can I use EARS statements to generate production checks for a release?▼

Yes, you can use EARS statements to generate production checks for a release. The system converts EARS or Given/When/Then formats into post-deploy verification steps, ensuring backend side effects and live smoke tests are validated after deployment.