Unnamed Skill
Implement code changes by learning from and precisely matching existing codebase patterns, ensuring seamless integration with surrounding code. Use when writing new features, modifying logic, adding functionality. Triggers: 'implement', 'write code', 'add feature', 'create', 'build', 'fix bug', '구현', '코드 작성', '기능 추가', '생성', '빌드', '버그 수정', '만들어', working with *.ts, *.go, *.java, *.py, *.nix, *.rs files.
$ 설치
git clone https://github.com/vanillacake369/tonys-nix /tmp/tonys-nix && cp -r /tmp/tonys-nix/dotfiles/claude/skills/code-implementation ~/.claude/skills/tonys-nix// tip: Run this command in your terminal to install the skill
name: code-implementation description: Implement code changes by learning from and precisely matching existing codebase patterns, ensuring seamless integration with surrounding code. Use when writing new features, modifying logic, adding functionality. Triggers: 'implement', 'write code', 'add feature', 'create', 'build', 'fix bug', '구현', '코드 작성', '기능 추가', '생성', '빌드', '버그 수정', '만들어', working with *.ts, *.go, *.java, *.py, *.nix, *.rs files. allowed-tools:
- Read
- Edit
- Write
- Glob
- Grep
- Bash(git:*)
- Bash(just:*)
- Bash(go:*)
- Bash(gradle:*)
- Bash(./gradlew:*)
Code Implementation Methodology
This skill provides systematic approach to implementing code that blends naturally with existing codebase as if written by the original developers.
Leverages: [codebase-analysis] skill for discovering project conventions and patterns.
Core Implementation Principle
Mimic, Don't Import: Every line of new code should feel like it was written by the same developer who wrote the surrounding code.
Implementation Workflow
Phase 1: Context Learning
Before writing any code:
- Study neighbors: Read 3-5 files in same directory/module
- Analyze similar features: Find comparable functionality
- Learn patterns: Identify repeated structures and approaches
- Understand dependencies: See how libraries are used
- Examine tests: Learn validation approaches
Phase 2: Pattern Matching
Match existing code exactly:
- Naming: Use same case, prefixes, suffixes as neighbors
- Structure: Follow same file organization and class/function layout
- Style: Match indentation, spacing, bracing, comments
- Libraries: Use same dependencies and utilities as existing code
- Error handling: Follow same error patterns and logging
Phase 3: Implementation
Write code that blends in:
- Copy structural patterns from similar existing code
- Reuse existing utilities and helper functions
- Follow same abstraction levels as surrounding code
- Match comment style and documentation format
- Use same testing patterns and assertions
Phase 4: Integration Validation
Ensure seamless integration:
- Run existing tests - all must pass
- Execute build commands - must compile/run
- Verify style consistency with surrounding code
- Check that integration points work correctly
- Ensure no new dependencies without justification
Style Matching Categories
Naming Conventions
- Match case style (camelCase, snake_case, PascalCase)
- Follow prefix/suffix patterns (get*, is*, has*, *Service, *Repository)
- Use domain terminology from existing code
- Maintain consistency within same module
Structural Patterns
- Copy class/function organization from similar files
- Follow same constructor/initialization patterns
- Match method ordering (public → private, create → read → update → delete)
- Replicate abstraction levels
Import Organization
- Group imports same way as existing files
- Use same libraries and frameworks
- Follow import ordering conventions
- Avoid introducing new dependencies
Error Handling
- Match exception types and error messages
- Follow logging patterns and levels
- Use same error propagation approach
- Replicate validation patterns
Comment and Documentation
- Match comment style (// vs /* */ vs #)
- Follow documentation format (JSDoc, Python docstrings, etc.)
- Use same level of detail as surrounding code
- Maintain consistent spacing and formatting
Common Implementation Patterns
Adding CRUD Operations
When adding CRUD, find existing CRUD examples:
- Copy the structure exactly
- Adjust entity/model names
- Keep same validation patterns
- Use same repository patterns
- Follow same endpoint/API structure
Adding API Endpoints
When adding endpoints, find similar endpoints:
- Copy routing pattern
- Match request/response DTOs structure
- Use same validation approach
- Follow same error response format
- Apply same authentication/authorization
Adding Business Logic
When adding logic, study similar use cases:
- Follow same service/use case structure
- Use existing domain models
- Apply same transaction patterns
- Reuse existing validation
- Match logging and error handling
Integration Best Practices
Use Existing Utilities
✅ Always: Reuse project utilities and helpers
❌ Never: Reimplement existing functionality
Follow Architectural Boundaries
✅ Always: Respect layer dependencies (API → Service → Repository)
❌ Never: Skip layers or create circular dependencies
Match Technology Choices
✅ Always: Use same libraries as existing code
❌ Never: Introduce new frameworks without strong justification
Quality Checklist
Before considering implementation complete:
- Does code match naming conventions of surrounding files?
- Are imports organized like existing files?
- Does error handling follow project patterns?
- Are same libraries/utilities used?
- Do comments match existing style?
- Does code structure align with similar features?
- All existing tests still pass?
- New code follows discovered patterns?
- No architectural boundaries violated?
- No unnecessary dependencies added?
Detailed Examples
For comprehensive code examples demonstrating each pattern, see:
- examples.md - Detailed code samples for all matching strategies
Remember: The best implementation is invisible - it looks like it was always part of the codebase. Use [codebase-analysis] to understand the codebase's voice, then write in that voice.
Repository
