test-discipline

Enforces updating test assertions in the same commit as API or file changes.

1|Updated Jul 7, 2026
One-click install
npx skills add https://github.com/seiggy/maf-copilot-studio-demo --skill test-discipline-seiggy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-discipline
Source: https://github.com/seiggy/maf-copilot-studio-demo/tree/main/.copilot/skills/test-discipline
Command: npx skills add https://github.com/seiggy/maf-copilot-studio-demo --skill test-discipline-seiggy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Stale tests and out-of-sync assertion arrays break CI for other contributors when APIs change or counted files are added without updating the corresponding tests. ## Core Features & Use Cases - Same-commit test updates: Ensures any change to a function signature, public interface, or exported API is accompanied by updated tests in the same commit. - Assertion-to-disk synchronization: Keeps expected-count arrays like EXPECTED_FEATURES and 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 such as 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 assertions updated before I push.

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 does not break for other contributors.

What should I update when adding new files to a counted directory?

Update the test assertion array in the same commit. For example, adding a docs page like distributed-mesh.md to a features directory requires adding its entry to the EXPECTED_FEATURES array so the expected count matches disk reality.

Why does CI fail after someone else merges API changes?

CI often fails because tests were not updated alongside the API change. Before debugging complex failures, verify that test assertion arrays match the current filesystem state and that test expectations reflect the new interfaces.

Can passing CI still hide stale test assertions?

Yes. Stale assertions can pass while being wrong, such as a test expecting 7 files when the disk has 25. Treat assertion arrays as evolving with content rather than static values, and audit them when adding or deleting counted resources.

When should test assertion arrays be treated as static?

Never. Assertion arrays like EXPECTED_FEATURES and EXPECTED_SCENARIOS must evolve with the content they count. Leaving them unchanged when adding or removing files blocks pull requests and creates gaps for other contributors to discover.