How do I install the Coding Discipline skill?

Run npx skillmds@latest add snowbridge/coding-discipline in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Coding Discipline safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Coding Discipline?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Coding Discipline free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Coding Discipline?

Snowbridge (@snowbridge) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Coding Discipline by snowbridge — Agent Skill

Name: Coding Discipline
Author: Snowbridge

Coding Discipline

Enforces coding discipline: constants over magic values, enums over boolean params, breathing room and purposeful comments, private-by-default visibility, layered abstractions, minimal diffs, strict layer boundaries, always-braces if, and test-first bug fixes. Use when writing or editing code, reviewing changes, or when the user asks about code style or clean code practices.

Snowbridge Updated Sep 22, 2026

File contents

Coding discipline

When to apply

Writing or editing code in any language
Code review or refactoring
User asks about code style, clean code, or coding discipline

Principles

Avoid magic numbers and strings by extracting recurring or meaningful values into descriptive constants (const) or enums. Keep self-explanatory, one-off values inline to avoid clutter. If a value comes from a spec (e.g. HTTP 200 OK), use a constant regardless.
Use enums instead of booleans for function parameters.
Let the reader of the code breathe. Add empty lines between logical blocks of code.
Add a small, to the point, comment to explain what the block does and why. Use examples when possible. Propose ASCII drawings to explain complete systems.
Treat member visibility changes as a breaking design shift. Keep all fields and functions private unless external access is strictly required by the design. Prompt the user for explicit approval before changing any access modifier from private to internal or public.
Program to levels of abstraction. Lower-level mechanics (e.g., raw hardware I/O, sector parsing, direct socket streams) must be encapsulated in a dedicated driver/abstraction layer. Expose clean, high-level APIs to the rest of the application so calling code works with domain concepts, not raw implementation details.
Don't touch blocks of code unrelated to the feature you implement. e.g. Don't add comments to a block of code if you did not create it or modify it. As much as possible try to minimize the number of changed lines when implementing a feature.
Strictly adhere to the layered boundary hierarchy: each layer may only communicate with its immediate neighbor directly below it. Never "punch holes" through layers (e.g., controllers or UI components must never directly call database queries, raw hardware drivers, or low-level network clients; always route through the intermediate service/abstraction layer).
Always use {}, even on a one-line "if" statement.
If the prompt indicates that a bug is being fixed, don't write the fix right away. First write the test. Observe it failing. Then write the fix. And observe the test passing.

Workflows

Visibility gate

Before widening any access modifier, stop and ask the user:

⚠️ Visibility change requested
Current: private <member>
Proposed: internal|public <member>
Reason: <why external access is required>
Confirm before applying.

Do not apply the change until the user explicitly approves.

Bug-fix TDD

When the task is a bug fix:

- [ ] Write a test that reproduces the bug
- [ ] Run the test — confirm failure
- [ ] Implement the minimal fix
- [ ] Run the test — confirm pass

Layer boundary

Each layer talks only to its immediate neighbor below:

UI / CLI ──► Service / Use-case ──► Domain ──► Driver / IO
     ✗ never skip intermediate layer

Additional resources

For good/bad code examples, see examples.md

---name: coding-disciplinedescription: Enforces coding discipline: constants over magic values, enums over boolean params, breathing room and purposeful comments, private-by-default visibility, layered abstractions, minimal diffs, strict layer boundaries, always-braces if, and test-first bug fixes. Use when writing or editing code, reviewing changes, or when the user asks about code style or clean code practices.---# Coding discipline## When to apply- Writing or editing code in any language- Code review or refactoring- User asks about code style, clean code, or coding discipline## Principles- Avoid magic numbers and strings by extracting recurring or meaningful values into descriptive constants (const) or enums. Keep self-explanatory, one-off values inline to avoid clutter. If a value comes from a spec (e.g. HTTP 200 OK), use a constant regardless.- Use enums instead of booleans for function parameters.- Let the reader of the code breathe. Add empty lines between logical blocks of code.- Add a small, to the point, comment to explain *what* the block does and *why*. Use examples when possible. Propose ASCII drawings to explain complete systems.- Treat member visibility changes as a breaking design shift. Keep all fields and functions private unless external access is strictly required by the design. Prompt the user for explicit approval before changing any access modifier from private to internal or public.- Program to levels of abstraction. Lower-level mechanics (e.g., raw hardware I/O, sector parsing, direct socket streams) must be encapsulated in a dedicated driver/abstraction layer. Expose clean, high-level APIs to the rest of the application so calling code works with domain concepts, not raw implementation details.- Don't touch blocks of code unrelated to the feature you implement. e.g. Don't add comments to a block of code if you did not create it or modify it. As much as possible try to minimize the number of changed lines when implementing a feature.- Strictly adhere to the layered boundary hierarchy: each layer may only communicate with its immediate neighbor directly below it. Never "punch holes" through layers (e.g., controllers or UI components must never directly call database queries, raw hardware drivers, or low-level network clients; always route through the intermediate service/abstraction layer).- Always use {}, even on a one-line "if" statement.- If the prompt indicates that a bug is being fixed, don't write the fix right away. First write the test. Observe it failing. Then write the fix. And observe the test passing.## Workflows### Visibility gateBefore widening any access modifier, stop and ask the user:```text⚠️ Visibility change requestedCurrent: private <member>Proposed: internal|public <member>Reason: <why external access is required>Confirm before applying.```Do not apply the change until the user explicitly approves.### Bug-fix TDDWhen the task is a bug fix:```text- [ ] Write a test that reproduces the bug- [ ] Run the test — confirm failure- [ ] Implement the minimal fix- [ ] Run the test — confirm pass```### Layer boundaryEach layer talks only to its immediate neighbor below:```textUI / CLI ──► Service / Use-case ──► Domain ──► Driver / IO ✗ never skip intermediate layer```## Additional resources- For good/bad code examples, see [examples.md](examples.md)

Frequently asked questions