Code Review & Refactoring Skills

Use when working with the faultline-eval evaluation harness: ingesting a labelled dataset into a normalised corpus, running coverage measurement against faultline playbooks, producing a coverage report, identifying high-value gap clusters, comparing baseline versus current results in CI, and generating playbook stubs from gap data. Trigger it for requests about running the eval pipeline, measuring playbook coverage, finding gaps, or promoting eval results as baselines.

Use this skill to run a full false-positive reduction cycle on the bundled playbook set. It extracts patterns shared across two or more playbooks, classifies which conflicts are genuine risks, fixes them by adding match.none discriminators, adds adversarial fixture logs and test cases to defend the boundary, and verifies with make review-update and make test. Trigger it when the baseline is green but you want to proactively narrow ambiguous pattern overlaps. Do not use it when a specific fixture is already failing — use playbook-refinement or baseline-regression instead.

Use when the task is a coverage improvement sprint driven by the eval corpus gap report — starting from an existing results.jsonl, identifying the highest-value unmatched clusters, deciding whether each gap warrants a new playbook or an extension to an existing one, authoring or extending the playbook, verifying the change against samples, and re-running the eval to measure improvement. Trigger it for requests like "close coverage gaps", "extend coverage from the eval corpus", "author playbooks from the gap report", or "improve the match rate". Do not trigger it for general playbook authoring from fixtures, for the ingestion pipeline, or for CI baseline comparisons — use the eval-corpus, new-playbook-authoring, or baseline-regression skills for those.

Use this skill as the quality gate immediately before running make review on any new or modified playbook. Trigger it after drafting or editing playbook YAML to catch determinism failures, weak matchers, missing negative coverage, ontology incompleteness, and fixture quality problems. Always run it before make review. It replaces ad-hoc subjective judgment with a grounded, repeatable checklist. A FAIL verdict blocks make review — all critical issues must be resolved first.

Use when refining or authoring bundled source playbooks from repository-local findings surfaced by inspect or guard. Trigger it for requests about source-detector tuning, adding new bundled source rules, improving workflow guidance on source playbooks, or maintaining paired source fixtures under internal/engine/testdata/source. Use it instead of the ingestion-pipeline skill when the evidence comes from repository inspection rather than public log intake.