test-discipline

Enforces updating tests in the same commit as API and file changes.

2|Updated Jul 24, 2026
One-click install
npx skills add https://github.com/elbruno/ElBruno.MagenticUI --skill test-discipline-elbruno
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-discipline
Source: https://github.com/elbruno/ElBruno.MagenticUI/tree/main/.squad/templates/skills/test-discipline
Command: npx skills add https://github.com/elbruno/ElBruno.MagenticUI --skill test-discipline-elbruno

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Stale tests and out-of-sync assertions break CI for other contributors when APIs change or counted files are added without updating test expectations. ## Core Features & Use Cases - Same-commit test updates: Ensures any change to a function signature, public interface, or exported API is accompanied by corresponding test updates before committing. - Assertion-to-disk synchronization: Keeps expected count arrays (e.g., EXPECTED_FEATURES, EXPECTED_SCENARIOS) aligned with the actual files on disk. - CI triage guidance: Directs developers to verify test assertion arrays against filesystem state before debugging complex CI failures. - Use Case: After adding a new docs page like distributed-mesh.md to a features directory, update the EXPECTED_FEATURES array in the same commit so the next contributor's CI run passes. ## Quick Start Review my pending commit and confirm every API change and added file has its corresponding test and assertion array updated.

Frequently Asked Questions about test-discipline

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

FAQPage Schema
How do I keep tests in sync when changing an API?▼

Update the corresponding tests in the same commit as the API change. If you modify a function signature, public interface, or exported API, adjust the affected test files before committing so CI stays green for other contributors.

How do I update test assertions when adding new files?▼

Add the new file's entry to the expected-count assertion array in the same commit. For example, adding distributed-mesh.md to a features directory requires appending 'distributed-mesh' to the EXPECTED_FEATURES array.

Why does CI fail after someone else merges a change?▼

Stale test assertions are a common cause: the test expects a fixed file count that no longer matches disk reality. Before deep debugging, verify assertion arrays like EXPECTED_SCENARIOS match the actual files present.

Can passing CI still hide stale test assertions?▼

Yes. Stale assertions can pass while being wrong, so green CI does not guarantee coverage is correct. Treat assertion arrays as evolving with content rather than static constants.

When should test updates not be deferred to a later commit?▼

Never defer them when changing APIs or adding counted resources. Committing API changes without test updates breaks CI for the next person and leaves gaps other contributors must discover and fix.