qa-root-cause-remediation

Estrelas12

Forks1

Atualizado22 de março de 2026 às 13:08

Enforce root-cause remediation for QA failures; no pass-by-patch, no test-to-green hacks, and no local suppressions without explicit approval.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

robkam

robkam/ytreenova

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

SKILL.md

readonly

name	qa-root-cause-remediation
description	Enforce root-cause remediation for QA failures; no pass-by-patch, no test-to-green hacks, and no local suppressions without explicit approval.

QA Root Cause Remediation

Use this skill whenever a QA gate fails (build, static analysis, sanitizer, valgrind, or pytest).

Mandatory Rules

Fix the underlying defect that caused the failure.
Do not patch around the check by weakening behavior or bypassing failing paths.
Do not change tests only to force green unless the test is demonstrably wrong against spec.
Do not add local suppressions (NOLINT, xfail, skip, ignore lists, disable flags) as a shortcut.
If temporary suppression is the only safe short-term option, stop and get explicit user approval first, with rollback plan.

Required Evidence

Failing gate command and concise failure summary (before fix)
Root-cause statement tied to code path or invariant
Minimal changes made and why they address the root cause
Passing rerun of the same failing gate
If suppression was approved, include scope and removal plan

Escalation

If remediation requires broad refactoring, present options and tradeoffs before changing architecture.
If failure indicates a spec mismatch, align spec, test, and code explicitly; do not silently alter tests.

Mais deste repositório

mesmo repositório

code-quality

robkam/ytreenova

Prevent and remove high-impact code-quality issues with principle-driven, risk-ranked recommendations and optional implementation.

2026-07-1912

architect-planning

robkam/ytreenova

Plan ytnova changes from behavior to implementation tasks with files, risks, invariants, and acceptance criteria. Use for design and technical-approach questions.

2026-07-1012

developer-implementation

robkam/ytreenova

Implement approved ytnova tasks in C with minimal coherent edits, architectural safety, and terminal-verified proof.

2026-07-0912

code-auditor-gate

robkam/ytreenova

Perform adversarial ytnova code review with severity-ranked findings, concrete fixes, and pass-fail gate decision.

2026-07-0412

bugfix-red-green-proof

robkam/ytreenova

Enforce strict ytnova bugfix loop: failing regression first, implementation second, passing proof third.

2026-06-1012

full-audit-gate-c

robkam/ytreenova

Run ytnova C quality gate for feature-sized changes using build, static analysis, valgrind, and pytest per docs/AUDIT.md.

2026-06-1012

name	qa-root-cause-remediation
description	Enforce root-cause remediation for QA failures; no pass-by-patch, no test-to-green hacks, and no local suppressions without explicit approval.

QA Root Cause Remediation

Use this skill whenever a QA gate fails (build, static analysis, sanitizer, valgrind, or pytest).

Mandatory Rules

Fix the underlying defect that caused the failure.
Do not patch around the check by weakening behavior or bypassing failing paths.
Do not change tests only to force green unless the test is demonstrably wrong against spec.
Do not add local suppressions (NOLINT, xfail, skip, ignore lists, disable flags) as a shortcut.
If temporary suppression is the only safe short-term option, stop and get explicit user approval first, with rollback plan.

Required Evidence

Failing gate command and concise failure summary (before fix)
Root-cause statement tied to code path or invariant
Minimal changes made and why they address the root cause
Passing rerun of the same failing gate
If suppression was approved, include scope and removal plan

Escalation

If remediation requires broad refactoring, present options and tradeoffs before changing architecture.
If failure indicates a spec mismatch, align spec, test, and code explicitly; do not silently alter tests.