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:
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.
1---2name: code-implementation3description: 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 f4---5
6---
7name: code-implementation
8description: 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.
9allowed-tools:
10 - Read
11 - Edit
12 - Write
13 - Glob
14 - Grep
15 - Bash(git:*)
16 - Bash(just:*)
17 - Bash(go:*)
18 - Bash(gradle:*)
19 - Bash(./gradlew:*)
20---
21
22# Code Implementation Methodology
23
24This skill provides systematic approach to implementing code that blends naturally with existing codebase as if written by the original developers.
25
26**Leverages:** [codebase-analysis] skill for discovering project conventions and patterns.
27
28## Core Implementation Principle
29
30**Mimic, Don't Import**: Every line of new code should feel like it was written by the same developer who wrote the surrounding code.
31
32## Implementation Workflow
33
34### Phase 1: Context Learning
35Before writing any code:
361. **Study neighbors**: Read 3-5 files in same directory/module
372. **Analyze similar features**: Find comparable functionality
383. **Learn patterns**: Identify repeated structures and approaches
394. **Understand dependencies**: See how libraries are used
405. **Examine tests**: Learn validation approaches
41
42### Phase 2: Pattern Matching
43Match existing code exactly:
441. **Naming**: Use same case, prefixes, suffixes as neighbors
452. **Structure**: Follow same file organization and class/function layout
463. **Style**: Match indentation, spacing, bracing, comments
474. **Libraries**: Use same dependencies and utilities as existing code
485. **Error handling**: Follow same error patterns and logging
49
50### Phase 3: Implementation
51Write code that blends in:
521. Copy structural patterns from similar existing code
532. Reuse existing utilities and helper functions
543. Follow same abstraction levels as surrounding code
554. Match comment style and documentation format
565. Use same testing patterns and assertions
57
58### Phase 4: Integration Validation
59Ensure seamless integration:
601. Run existing tests - all must pass
612. Execute build commands - must compile/run
623. Verify style consistency with surrounding code
634. Check that integration points work correctly
645. Ensure no new dependencies without justification
65
66## Style Matching Categories
67
68### Naming Conventions
69- Match case style (camelCase, snake_case, PascalCase)
70- Follow prefix/suffix patterns (get*, is*, has*, *Service, *Repository)
71- Use domain terminology from existing code
72- Maintain consistency within same module
73
74### Structural Patterns
75- Copy class/function organization from similar files
76- Follow same constructor/initialization patterns
77- Match method ordering (public → private, create → read → update → delete)
78- Replicate abstraction levels
79
80### Import Organization
81- Group imports same way as existing files
82- Use same libraries and frameworks
83- Follow import ordering conventions
84- Avoid introducing new dependencies
85
86### Error Handling
87- Match exception types and error messages
88- Follow logging patterns and levels
89- Use same error propagation approach
90- Replicate validation patterns
91
92### Comment and Documentation
93- Match comment style (// vs /* */ vs #)
94- Follow documentation format (JSDoc, Python docstrings, etc.)
95- Use same level of detail as surrounding code
96- Maintain consistent spacing and formatting
97
98## Common Implementation Patterns
99
100### Adding CRUD Operations
101When adding CRUD, find existing CRUD examples:
1021. Copy the structure exactly
1032. Adjust entity/model names
1043. Keep same validation patterns
1054. Use same repository patterns
1065. Follow same endpoint/API structure
107
108### Adding API Endpoints
109When adding endpoints, find similar endpoints:
1101. Copy routing pattern
1112. Match request/response DTOs structure
1123. Use same validation approach
1134. Follow same error response format
1145. Apply same authentication/authorization
115
116### Adding Business Logic
117When adding logic, study similar use cases:
1181. Follow same service/use case structure
1192. Use existing domain models
1203. Apply same transaction patterns
1214. Reuse existing validation
1225. Match logging and error handling
123
124## Integration Best Practices
125
126### Use Existing Utilities
127```
128✅ Always: Reuse project utilities and helpers
129❌ Never: Reimplement existing functionality
130```
131
132### Follow Architectural Boundaries
133```
134✅ Always: Respect layer dependencies (API → Service → Repository)
135❌ Never: Skip layers or create circular dependencies
136```
137
138### Match Technology Choices
139```
140✅ Always: Use same libraries as existing code
141❌ Never: Introduce new frameworks without strong justification
142```
143
144## Quality Checklist
145
146Before considering implementation complete:
147- [ ] Does code match naming conventions of surrounding files?
148- [ ] Are imports organized like existing files?
149- [ ] Does error handling follow project patterns?
150- [ ] Are same libraries/utilities used?
151- [ ] Do comments match existing style?
152- [ ] Does code structure align with similar features?
153- [ ] All existing tests still pass?
154- [ ] New code follows discovered patterns?
155- [ ] No architectural boundaries violated?
156- [ ] No unnecessary dependencies added?
157
158## Detailed Examples
159
160For comprehensive code examples demonstrating each pattern, see:
161- **examples.md** - Detailed code samples for all matching strategies
162
163---
164
165**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.