
Engineering Discipline
- 26 installs
- 10 repo stars
- Updated July 24, 2026
- duyet/claude-plugins
Apply core engineering principles for sustainable, maintainable code - no shortcuts, minimal changes, and quality gates (tests, lint, verification) before marking work complete.
About
An engineering-discipline skill encoding core principles for sustainable, maintainable code: no shortcuts or hacks, minimal one-logical-change commits, edit over rewrite, and quality gates - tests pass, lint clean, manual verification - before any work is marked complete. It is framed for code meant to scale to thousands of users. A solo builder reaches for it to keep an AI agent honest and avoid accumulating technical debt.
- No shortcuts, sustainable-only solutions
- Minimal, one-logical-change commits
- Quality gates: tests pass, lint clean, verify before complete
Engineering Discipline by the numbers
- 26 all-time installs (skills.sh)
- Ranked #693 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/duyet/claude-plugins --skill engineering-disciplineAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 26 |
|---|---|
| repo stars | ★ 10 |
| Last updated | July 24, 2026 |
| Repository | duyet/claude-plugins ↗ |
What it does
Apply core engineering principles for sustainable, maintainable code - no shortcuts, minimal changes, and quality gates (tests, lint, verification) before marking work complete.
Who is it for?
Keeping agent output disciplined
Skip if: Throwaway prototypes
Files
Engineering Discipline
Duyetbot's engineering principles for code that scales to 10,000+ users.
Core Rules
1. No Shortcuts
- Every solution must be sustainable long-term
- Temporary fixes become permanent debt
- If it feels like a workaround, it is
2. Minimal Changes
- One logical change per commit
- Touch only what's necessary
- Edit over Write (preserve context)
3. Verify Before Complete
- Tests pass
- Lint clean
- Manual verification when needed
Quality Gates
Before marking any work complete:
Code
- [ ] No errors/warnings
- [ ] Follows existing patterns
- [ ] No hardcoded values
- [ ] Error handling present
- [ ] Input validation at boundaries
Testing
- [ ] Unit tests for logic
- [ ] Integration tests for flows
- [ ] Edge cases covered
- [ ] Tests are deterministic
Performance
- [ ] No N+1 patterns
- [ ] Appropriate caching
- [ ] Resource cleanup
Security
- [ ] Input sanitized
- [ ] Auth/authz checked
- [ ] No secrets in code
Decision Rules
When to Refactor
Refactor when:
- Adding features is painful
- Bugs cascade
- Code confuses
Don't when:
- Code works, rarely changes
- No immediate need
When to Abstract
Abstract when:
- Pattern appears 3+ times
- Abstraction reduces complexity
Don't when:
- Only 1-2 occurrences
- Abstraction more complex
Anti-Patterns
| Bad | Why | Good |
|---|---|---|
| Magic numbers | Unclear | Named constants |
| God objects | Unmaintainable | Single responsibility |
| Copy-paste | Bug multiplication | Extract shared |
| Commented code | Confusion | Git history |
| Premature optimization | Wrong focus | Measure first |