faultline

Apply disciplined engineering principles to general software projects. Adapted from TigerBeetle's TigerStyle. Use whenever writing, reviewing, designing, or maintaining production code, scripts, libraries, services, tools, tests, or project infrastructure.

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 this skill when the task is to audit playbook coverage by collecting a broad, stratified sample of real CI failure evidence from public sources. Trigger it for requests about finding coverage gaps, sampling CI failures across ecosystems, measuring catalog robustness against external evidence, identifying unmatched or weakly matched failure classes, or building an evidence batch for playbook discovery. Do not trigger it for promoting a specific known fixture (use ingestion-pipeline) or for refining an individual playbook (use playbook-refinement).

Use this skill 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 when the task is to author a new Faultline playbook after a gap has already been explicitly justified. Trigger it only when triage-unmatched-log, collect-coverage-evidence, or a confirmed fixture regression has established that a new playbook is warranted and the nearest existing playbook cannot cover the case. Covers placement decision (bundled vs extra pack), required YAML field authoring, pattern discipline for match.any and match.none, fixture pairing, and the full make review / make test / make fixture-check validation sequence. Do not trigger it speculatively or as a first step — refinement should always be ruled out first.

Use this skill 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 this skill to fill coverage gaps with validated playbooks. Can run without any input — when called with no target it runs coverage-gaps.md to identify the highest-priority gap, then executes the full sprint for that gap. Can also be called with a specific failure type, coverage gap name, or public failure URL to skip directly to Phase 2. Composes coverage-gaps, coverage-evidence, fixture-generation, new-playbook-authoring, and playbook-linter into a single end-to-end chain. Do not trigger it when triage has already justified a gap and you just need the YAML — use new-playbook-authoring directly in that case.

Use this skill when a playbook needs realistic paired fixtures before validation. Trigger it during new-playbook-authoring when no staged fixture exists, or during playbook-refinement when existing fixtures need new variants (noisy, near-miss, adversarial). The playbook YAML must be drafted before calling this skill — fixtures defend specific patterns, not hypotheses. Do not trigger it speculatively or as a standalone corpus-enrichment activity.

Use this skill when improving Faultline playbooks from fixture evidence, especially for weak matches, false positives, confusable neighbors, missing workflow guidance, or deciding whether to refine an existing playbook instead of adding a new one. Trigger it for requests about fixture-driven playbook updates, overlap reduction, validation after playbook edits, or improving workflow fields such as likely_files, local_repro, and verify.

Use this skill when working on Faultline fixture intake from public sources, including staging review, duplicate rejection, promotion into fixtures/real, and post-promotion baseline validation. Trigger it for requests about running the ingestion pipeline, ingesting fixtures, reviewing staging candidates, promoting accepted cases, or validating new real-world corpus additions.

Use this skill 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.

Use this skill when make fixture-check or faultline fixtures stats --check-baseline fails after a repository change. Trigger it for investigating which fixture regressed, why, and how to restore a passing baseline without weakening the trust boundary. Covers per-fixture isolation, regression classification (pattern narrowed, outcompeted, false positive, shared rule change), and the three explicit outcomes (fix forward, fix expectations, revert). Do not trigger it for general playbook authoring, new fixture promotion, or proactive corpus improvement — those use other skills.