Todolo Development Standards
Development rules for the Todolo project, an Electron-based todo application that feels like a text editor.
Overview
This skill enforces strict development standards for the Todolo project, emphasizing test-first development, code reuse, incremental changes, and comprehensive error handling. Follow these rules when contributing to or modifying the Todolo codebase.
Instructions
CRITICAL: Before Suggesting Any Code
Before making any code suggestions or modifications:
1. **Search for existing utilities/functions** - Always check if functionality already exists that can be reused
2. **Include tests** - Every code suggestion must include corresponding tests
3. **Add error handling** - Include proper error handling and input validation
4. **Keep changes small** - Make incremental, focused changes
5. **Prefer simplicity** - Choose simpler solutions over clever ones when equivalent
Core Development Principles
Apply these principles to all development work:
**Low complexity** - Favor simplicity while maintaining quality, performance, and clarity**Think in slices** - Deliver safe, testable increments first**Composition** - Prefer composition and small functions; keep boundaries clean**Reuse first** - Search for existing helpers before writing new ones**Obvious behavior** - Make behavior clear via tests and names, not comments**Measure before optimizing** - Instrument key paths and measure before making performance changes**Explicit failure modes** - Validate inputs, add guards, and return useful errors**Clean as you go** - Remove duplication and tighten interfacesImplementation Requirements
Every code change must meet these requirements:
1. **Write tests first** - Add or extend tests with each change, not only at the end
2. **Reuse existing code** - Search `src/renderer/utils/` and other directories for existing utilities before writing new ones
3. **Validate inputs** - Handle null/undefined cases and avoid silent failures
4. **Add observability** - Include logging for key decision points and errors
5. **Handle timeouts/retries** - Guard external calls with proper error handling
6. **Incremental changes** - Keep each change small and focused on a single concern
7. **Document breaking changes** - Always note API changes and their impact
Testing Standards
All code must include comprehensive tests:
Write **unit tests** for individual functions/componentsAdd **integration tests** for cross-boundary behaviorTest edge cases, boundary conditions, and error statesTarget **>80% code coverage** for new code, **100% for critical paths**Keep tests deterministic and readable; avoid over-mockingFollow testing patterns in `src/__tests__/` directoryUse Jest as the testing frameworkCode Quality Requirements
Before suggesting or committing code:
Run formatting, lint, and type checksRemove dead code and debug logsExtract shared utilities immediately to avoid duplicationUse clear, descriptive variable and function namesAdd proper error handling with helpful error messagesOrganize files/code according to project structure: - Utilities in `src/renderer/utils/`
- Tests in `src/__tests__/`
- Components in `src/renderer/features/`
- Database operations following `src/main/db.ts` patterns
Project Context
Key technical details about Todolo:
**Framework**: Electron-based desktop application**Language**: TypeScript**UI Library**: React**Testing**: Jest**Database**: Follow patterns in `src/main/db.ts` for database operations**Architecture**: Follows existing patterns in the codebaseCode Review Checklist
Apply this checklist to all suggestions:
[ ] Changes are incremental and focused on a single concern[ ] Tests cover new functionality and edge cases[ ] No duplication with existing code (existing utilities are reused)[ ] Error handling is appropriate and provides helpful messages[ ] Performance impact has been considered[ ] Code follows existing project patterns and structure[ ] Input validation is present[ ] Logging is added for key decision pointsResponse Format (MANDATORY)
When suggesting code changes, always follow this format:
1. **First**: Search and mention existing utilities that could be reused
2. **Then**: Provide the implementation with accompanying tests
3. **Include**: Comprehensive error handling and input validation
4. **Explain**: Why this approach follows the development rules
Examples of Good Practices
Use existing utilities like `validateEmail()` from `src/renderer/utils/` instead of reimplementing regex validationAdd comprehensive error handling with user-friendly messages for all failure scenariosWrite tests that cover both happy path and edge cases (null inputs, invalid data, boundary conditions)Extract duplicated logic into reusable utility functions immediatelyKeep functions small and focused on a single responsibilityProject Files to Reference
Always check these locations before writing new code:
`src/renderer/utils/` - Existing utility functions`src/__tests__/` - Testing patterns and examples`src/renderer/features/todos/` - Component structure and patterns`src/main/db.ts` - Database operation patternsConstraints
All code suggestions must include testsNo code duplication - always search for and reuse existing utilitiesChanges must be incremental and focusedError handling is mandatory for all operationsTypeScript types must be properly definedFollow existing project structure and patternsExpected Outcome
Code that is:
Well-tested (>80% coverage for new code)Maintainable and readableFree of duplicationProperly error-handledFollowing consistent patterns throughout the projectIncrementally delivered in safe, testable slices