qa-root-cause-remediation

Étoiles12

Forks1

Mis à jour22 mars 2026 à 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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

robkam

robkam/ytreenova

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.