Menu
Reusable QA orchestration skill for GitHub PRs. Use for multi-pass QA, CI monitoring with `atm gh monitor`, one-shot PR reporting with `atm gh pr report`, and template-driven findings/final quality reports.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Create or harden CLIs intended primarily for AI or system consumption and secondarily for humans. Use when designing or implementing a JSON-first CLI with an MCP-ready contract seam, where every command supports machine output, errors are typed and actionable, mutating commands are auditable via corresponding read commands, and external integrations need simulator-backed testing. Do not use for human-first shell utilities, one-off scripts, or text-only CLIs.
Design stateful simulators for AI-facing CLIs that integrate with devices, networks, services, or databases. Use when a CLI needs realistic simulator-backed testing, configurable fault injection, persistent state, and a swappable adapter boundary so the same business logic runs against live and simulated backends. Do not use for shallow mocks, stateless test doubles, or CLIs with no external integration.
Critically review an existing CLI, MCP wrapper, or CLI plan for AI-first contract quality. Use when evaluating whether a CLI is JSON-first, has an MCP-ready contract seam without JSON reshaping, auditably models state changes, uses stateful simulator-backed testing for external integrations, and returns typed actionable errors. Do not use for general style review or human-first shell UX review.
Orchestrate multi-sprint phases where crap (Codex) is the sole developer, with pipelined QA via quality-mgr teammate. Team-lead chooses the review type; quality-mgr chooses the reviewers.
Review Rust architecture plans, crate boundaries, and code for structural design-pattern compliance. Use when the task involves typestate, sealed traits, error contracts, wrapper/newtype design, object safety, interior mutability, or other type-system-driven Rust correctness patterns that go beyond general style guidance.
Develop, review, and explore Rust code with strict adherence to Pragmatic Rust Guidelines. Use when the user mentions Rust, .rs files, Cargo, clippy, rustdoc, or requests Rust architecture, implementation, or review.
| name | quality-management-gh |
| version | 1.1.0 |
| description | Reusable QA orchestration skill for GitHub PRs. Use for multi-pass QA, CI monitoring with `atm gh monitor`, one-shot PR reporting with `atm gh pr report`, and template-driven findings/final quality reports. |
This skill defines a reusable quality-management workflow for teams that run QA across one or more passes before merge.
Use this skill when you need to:
IN-FLIGHT, FAIL, PASS),This skill is intentionally generic. Team-specific teammate names, branch policy, and background-agent ownership stay in the team's quality-mgr agent prompt.
Every QA update (ATM and PR) must include:
PASS | FAIL | IN-FLIGHT)blocking, important, minor)ready | not ready) + reasonUse fenced JSON for machine-readable status payloads:
{
"sprint": "P1.2",
"task": "issue-42",
"branch": "feature/p1-s2-slug",
"commit": "abc1234",
"pr": 57,
"verdict": "FAIL",
"findings": {
"blocking": 1,
"important": 2,
"minor": 1
},
"blocking_ids": ["QA-001"],
"next_action": "Fix failing validation",
"owner": "crap",
"merge_readiness": "not ready",
"merge_reason": "Blocking findings remain"
}
FAIL with findings.IN-FLIGHT or FAIL while fixes are in progress.PASS with final quality report and merge recommendation.Do not treat QA as single-shot.
Use daemon-backed monitoring for CI progression:
atm ghatm gh statusatm gh monitor pr <PR> --start-timeout 120atm gh monitor statusatm gh status pr <PR>If monitoring cannot start, include the failure in QA status and proceed with one-shot PR report data.
Use:
atm gh pr report <PR> --jsonUse report JSON to populate findings/final template fields (checks summary, review decision, merge readiness signals).
Template: .claude/skills/quality-management-gh/findings-report.md.j2
For FAIL — post as blocking review:
sc-compose render --root .claude/skills/quality-management-gh \
--file findings-report.md.j2 \
--var-file <vars.json> | gh pr review <PR> --request-changes --body-file -
For IN-FLIGHT — post as comment (do not oscillate review states):
sc-compose render --root .claude/skills/quality-management-gh \
--file findings-report.md.j2 \
--var-file <vars.json> | gh pr comment <PR> --body-file -
Fallback when sc-compose is unavailable:
gh pr review <PR> --request-changes --body-file <fallback.md>
<vars.json> must be a flat JSON map (string -> string). See template frontmatter for required variables.
Template: .claude/skills/quality-management-gh/quality-report.md.j2
sc-compose render --root .claude/skills/quality-management-gh \
--file quality-report.md.j2 \
--var-file <vars.json> | gh pr review <PR> --approve --body-file -
Fallback when sc-compose is unavailable:
gh pr review <PR> --approve --body-file <fallback.md>
Use the final template only for PASS closeout.
FAIL → must use --request-changesPASS closeout → must use --approveThis creates the default lifecycle: blocking review on findings, then approval on successful re-review so the PR can merge.
Never overwrite history silently — each update should be clearly timestamped and tied to a pass number. Rendered reports must include a fenced JSON block for machine parsing.
For each task:
No silent processing.