zero-debt
Zero Technical Debt skill for the ikigai project
When & Why to Use This Skill
The Zero Technical Debt skill for the ikigai project is a specialized Claude capability designed to enforce high-standard engineering principles and a 'fix-it-now' philosophy. It ensures a clean, maintainable codebase by prioritizing the immediate resolution of code smells, naming inconsistencies, and architectural debt. By integrating systematic fixes and rigorous work style principles, this skill helps development teams prevent technical debt accumulation, leading to more robust, scalable, and high-quality software solutions.
Use Cases
- Automated Standards Enforcement: Instantly identifying and correcting naming convention violations and formatting issues to maintain a unified code style across the entire project.
- Proactive Quality Assurance: Detecting and filling test coverage gaps or missing function preconditions during the development phase to enhance system stability and prevent regressions.
- Systematic Debt Reduction: Auditing the codebase for recurring patterns of technical debt and applying comprehensive, root-cause fixes rather than temporary patches to ensure long-term maintainability.
- Workflow Optimization: Streamlining the development process by automating routine checks like 'make fmt' and 'make lint' while ensuring critical architectural changes are flagged for human approval.
| name | zero-debt |
|---|---|
| description | Zero Technical Debt skill for the ikigai project |
Zero Technical Debt
Description
Zero technical debt philosophy and work style principles for ikigai.
Details
Zero Technical Debt Principle
When you discover any problem, inconsistency, or standards violation:
- Fix it immediately - don't defer or document
- Fix it completely - address root cause, not symptoms
- Fix it systematically - search for similar issues elsewhere
Examples requiring immediate fixes:
- Missing assertions on function preconditions
- Inconsistent naming conventions
- Code violating error handling philosophy
- Test coverage gaps
- Code not following established patterns
When to ask first:
- Architectural changes
- Unclear which solution is correct
- Breaking changes to public APIs
- Uncertainty about project conventions
If you discover deficiencies in existing code while working nearby, fix them as part of your current work.
Work Style
CRITICAL: Do not make architectural, structural, or refactoring changes unless explicitly requested.
Acceptable without asking:
- Formatting with
make fmt - Running
make checkandmake lint - Minor code style consistency
When discussing improvements:
- Present options and trade-offs
- Wait for explicit approval before implementing