build-discipline

Enforce small test-first vertical slices during BUILD and verify-fix cycles.

Updated May 24, 2026

Search Tags:#debugging #maintainability #scope control #test-first #CI verification #vertical slices #software build

Ready to run

npx skills add https://github.com/RCSnyder/lights-out-swe-plugin --skill build-discipline-rcsnyder

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: build-discipline
Source: https://github.com/RCSnyder/lights-out-swe-plugin/tree/main/skills/build-discipline
Command: npx skills add https://github.com/RCSnyder/lights-out-swe-plugin --skill build-discipline-rcsnyder

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill solves the risk of drifting into large, hard-to-debug changes during BUILD by enforcing small, evidence-driven, test-first vertical slices.

Core Features & Use Cases

Slice-and-Prove Execution: Break work into small end-to-end increments anchored to the spec, with failing proof added before implementation.
Root-Cause Debug Loop: Reproduce failures, localize the failing layer, apply the smallest fix that removes the root cause, and preserve regression coverage.
Maintainability Guardrails: Prevent scope creep and speculative architecture changes by using explicit Changed / Not touched / Concerns summaries and red-flag triggers.

Quick Start

Use the build-discipline skill to implement a multi-file BUILD change by writing a failing test first, applying the smallest working fix, and re-running the verification ladder after each slice.

Frequently Asked Questions about build-discipline

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I prevent scope creep when implementing multi-file features?▼

Use test-first vertical slices to prevent scope creep during multi-file feature implementation. Anchor each slice to the design spec, implement the simplest working change, and use explicit Changed/Not touched/Concerns summaries to guard against speculative abstractions.

What is the best way to debug a root cause regression fix?▼

Debug a root cause regression fix by reproducing the failure, localizing the failing layer, adding a failing test proving the bug, and applying the smallest code change that removes the root cause while preserving regression coverage.

How do I structure a test-first workflow for software builds?▼

Structure a test-first software build workflow by writing or extending a failing test before any code changes, implementing the working fix, and running targeted then broader CI verification after each slice to ensure safer changes.

Why do my large code changes become hard to debug during iteration?▼

Large code changes become hard to debug during iteration because they drift away from the spec and introduce speculative abstractions. Enforcing small, evidence-driven, test-first vertical slices keeps increments manageable and isolated.

Does test-first development work for repairing existing features?▼

Yes, test-first development works for repairing existing features by requiring a failing test that reproduces the bug before applying the smallest fix. This maintains maintainability and prevents scope-creep during the verify-fix cycle.

When should I not use vertical slices for a software build?▼

Avoid vertical slices when the task lacks a clear spec or scaffolding scope to anchor increments. Without an anchor, the test-first approach cannot enforce maintainability or prevent speculative architecture changes effectively.