Menu
Turn raw CI/CD pipeline output into a readable report. Use when the user pastes build/pipeline logs or asks to summarize CI results.
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
| name | ci-cd-reporter |
| description | Turn raw CI/CD pipeline output into a readable report. Use when the user pastes build/pipeline logs or asks to summarize CI results. |
Analyze CI/CD pipeline outputs and generate human-readable test/build reports.
This skill transforms raw CI/CD pipeline outputs (test results, build logs, coverage reports) into clear, actionable reports. It parses JUnit XML, coverage data, build logs, and deployment outputs to give teams a quick understanding of pipeline health.
When the user provides CI/CD output or pipeline results:
# Pipeline Report
**Pipeline**: [name]
**Run**: #[number]
**Branch**: [branch]
**Commit**: [sha]
**Date**: [timestamp]
**Duration**: [time]
## Status: PASS / FAIL
## Summary
| Metric | Value | Threshold | Status |
|--------|-------|-----------|--------|
| Tests Passed | X/Y | 100% | OK/FAIL |
| Code Coverage | X% | 80% | OK/FAIL |
| Build Time | Xs | <300s | OK/FAIL |
| Lint Errors | X | 0 | OK/FAIL |
## Failed Tests (X)
### test_name
- **File**: [path]
- **Error**: [message]
- **Expected**: [value]
- **Actual**: [value]
- **Likely Cause**: [analysis]
## Coverage Breakdown
| Module | Statements | Branches | Functions | Lines |
|--------|-----------|----------|-----------|-------|
## Uncovered Critical Paths
- [file:line] - [description of uncovered code]
## Recommendations
1. [Prioritized action items]
## Flaky Test Candidates
- [Tests that passed/failed inconsistently]
Parse this JUnit XML and give me a summary of what failed and why:
[paste XML]
Here's the GitHub Actions output for our failing pipeline. What went wrong?
[paste log]
Full QA audit orchestrator. Use when the user asks to "test my app", "run a full QA audit", "test everything", or invokes /qa-audit. Discovers what kind of application this is, selects the relevant QA agents (ui-inspector, api-sentinel, security-scout, perf-guardian, data-validator, regression-watcher), runs them, and merges their reports into one master QA report.
Onboard the QA toolkit onto any project. Use on first contact with a new codebase, when the user says "set up QA", "qa init", "/qa-init", or when any QA agent finds no qa-profile.md. Studies the project deeply and writes the persistent QA profile that every other agent reads first — the toolkit's long-term memory for this project.
Wire the QA suite into CI. Use when the user wants tests running automatically on every PR or on a schedule: "add this to CI", "run tests on every push", "/qa-ci". Generates GitHub Actions workflows for the generated Playwright suite and (optionally) scheduled full audits.
Self-healing for the generated test suite. Use when previously-green Playwright tests are failing, the user says "my tests broke", "fix the tests", "/qa-heal", or after a UI refactor breaks selectors. Classifies each failure (real bug vs test drift) and repairs the drift — never papers over real bugs.
Compare two QA audit runs and report what improved, what regressed, and what persists. Use when the user asks "did it improve since last time?", "compare audits", "QA trend", or invokes /qa-trend. Requires at least two timestamped runs under qa-reports/runs/.
Audit web pages for WCAG 2.1 compliance. Use when the user asks about accessibility, a11y, WCAG, screen readers, or contrast issues.