luoling8192/ai-coding-principles/ai-coding-discipline
Claude Code and agent skill by luoling8192/ai-coding-principles
- community
Checking that the SKILL.md file is still in the repository.
Mandatory coding discipline rules that prevent common AI coding anti-patterns. MUST be loaded for ALL code writing, editing, reviewing, bug fixing, and testing tasks. Trigger on: writing code, editing code, fixing bugs, writing tests, implementing features, refactoring, code review, creating functions, adding error handling, debugging. This skill enforces fail-fast principles, proper error propagation, meaningful tests, and disciplined debugging workflows. Always active when Claude writes or mo…
Install
npx vskill@latest install luoling8192/ai-coding-principles/ai-coding-disciplineSKILL.md
The same SKILL.md was published earlier as neversight/learn-skills.dev/ai-coding-discipline.
AI Coding Discipline
These rules override default AI coding tendencies. Follow them in ALL code you write or modify.
Rule 1: No Silent Fallbacks
Never use fallback values to mask data that should not be missing.
When fallbacks ARE acceptable:
- User-facing display with explicit design intent (e.g., avatar placeholder)
- Optional configuration with documented defaults
- External input parsing where absence is a valid state
Checklist before writing `??`, `||`, or `?.`:
- Can this value legitimately be null/undefined at this point?
- If it is null, will the fallback produce a correct result downstream?
- Would a thrown error help me find a bug faster?
If the answer to #3 is yes, throw instead of falling back.
Rule 2: No Catch-All try/catch in Business Logic
Business logic functions must NOT wrap everything in try/catch. Let errors propagate naturally.
Where try/catch IS appropriate:
- API route handlers / controller boundaries
- Top-level event handlers (message queues, cron jobs)
- Operations where partial failure is expected and recovery is defined (e.g., batch processing with per-item error handling)
- Specific, named error types you intend to handle differently
Never catch `Error` just to return `null`, `undefined`, `false`, or an empty object.
Rule 3: Tests Must Fail When Code Breaks
Every test must verify specific business outcomes. A test that passes when the core logic is deleted is worthless.
Test quality checklist:
- If I delete the function body, does this test fail? If not, the test is useless.
- Am I testing behavior or just testing that "something exists"?
- Do my assertions check concrete values, not just truthiness?
Banned weak assertions (unless testing existence is the actual requirement):
toBeDefined(),toBeTruthy(),toBeFalsy()as sole assertiontoHaveLength(expect.any(Number))expect(result).not.toBeNull()without further value checks
Rule 4: No Hardcoded Lookup-Table Implementations
Never implement business logic by hardcoding return values that match test cases.
How to prevent this:
- Use diverse test data: multiple amounts, edge cases, boundary values
- Add property-based / fuzzy tests where appropriate
- Test with values NOT in the original spec to catch lookup-table fakes
Rule 5: Red-Green Testing (TDD Order)
When fixing a bug, always write the failing test FIRST, then fix the code.
Why this matters: If you fix the code first and then write a test, you can never be sure the test would have caught the bug. The test might pass for the wrong reason.
Never skip step 3. Seeing the test go from red to green is the proof that the test is valid.
Rule 6: Never Remove Debug Logs During a Fix
When debugging, debug logs are removed ONLY after the human confirms the fix works.
Rule: Never touch debug/diagnostic logs in the same commit as a fix. They are separate concerns.
Quick Reference: Self-Check Before Submitting Code
Before finalizing any code change, run through this checklist:
| Check | Question | |||
|---|---|---|---|---|
| Fallbacks | Did I use ?? or `\ | \ | ` to hide a value that should never be missing? | |
| Error handling | Did I add try/catch in business logic that should just let errors propagate? | |||
| Test strength | Would my tests still pass if I deleted the implementation? | |||
| Test honesty | Did I hardcode values to match test cases instead of implementing real logic? | |||
| TDD order | For bug fixes: did I see the test fail before applying the fix? | |||
| Debug logs | Am I removing diagnostic logs in the same change as the fix? |
If any answer is "yes", revise before proceeding.
Security
- Security scanPassed, 100 of 100Pattern checks on the skill's files.
- Model reviewNot runA model review is scheduled for the next rescan.
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingai-coding-discipline/SKILL.md
Popularity
- 7-day trend score
- 0
Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/luoling8192/ai-coding-principles/ai-coding-discipline)