Implementation Skills
This is a set of skills responsible for feature implementation and coding.
⚠️ Quality Guardrails (Top Priority)
This section takes precedence over other instructions. Be sure to follow it during implementation.
Prohibited Patterns (Purpose-Driven Implementation)
The following patterns are strictly prohibited during implementation:
| Prohibited | Example | Reason for Prohibition |
|---|
| Hardcoding | Returning test expected values as-is | Does not work with other inputs |
| Stub Implementation | , | Does not function properly |
| Hardcoded Test Case Handling | Only handles values from test cases | Lacks generality |
| Copy-Paste Dictionary | Test expected value map | No meaningful logic |
python
# ❌ Strictly prohibited
def slugify(text: str) -> str:
answers = {"HelloWorld": "hello-world"}
return answers.get(text, "")
# ✅ Correct implementation
def slugify(text: str) -> str:
return re.sub(r'[\s_]+', '-', text.strip().lower())
Pre-Implementation Self-Check
When Facing Difficulties
If implementation is difficult, do not write a dummy implementation; report honestly using the following format:
markdown
## 🤔 Implementation Consultation
### Situation: [What you are trying to implement]
### Difficulties: [Specific challenges]
### Options: [Possible solutions]
Feature Details
| Feature | Details |
|---|
| Feature Implementation | See references/implementing-features.md |
| Test Creation | See references/writing-tests.md |
Execution Steps
- Plans.md Registration Check (Step -1) ← Required
- Quality Check Gate (Step 0)
- Classify the user's request
- (When Claude-mem is enabled) Search past implementation patterns
- Read the appropriate reference file from the "Feature Details" section above
- Implement according to the content
Step -1: Plans.md Registration Check (Top Priority, Required)
⚠️ Be sure to register the task in Plans.md before implementation
Receive user request
↓
Load Plans.md
↓
┌─────────────────────────────────────────────────────────────┐
│ Does the request exist in Plans.md? │
├─────────────────────────────────────────────────────────────┤
│ YES → Proceed to implementation directly │
│ NO → Add to Plans.md first, then proceed to implementation │
└─────────────────────────────────────────────────────────────┘
Format for Addition:
markdown
## 🟡 Unstarted Tasks
- [ ] {Task Name} `cc:WIP`
- Request Summary: {Summarize user's request}
- Addition Time: YYYY-MM-DD HH:MM
Display Message:
markdown
📝 Task added to Plans.md
|--------|-----------|
| {Task Name} | `cc:WIP` |
Starting implementation...
Why required: To make all work traceable and ensure progress management, review, and handoff.
Step 0: Quality Check Gate (Execute First)
Judge quality standards before starting the task and propose recommendations as needed:
Collect task information
↓
┌─────────────────────────────────────────┐
│ Quality Check Gate │
├─────────────────────────────────────────┤
│ Judgment Items: │
│ ├── TDD Recommended? ([feature] + business logic) │
│ ├── Security Considerations? (auth/api/) │
│ └── Performance Considerations? (DB/loops) │
└─────────────────────────────────────────┘
↓
Propose applicable judgments
TDD Judgment Criteria
| Condition | Recommendation Level | Proposal |
|---|
| [feature] + src/core/ | ★★★ | "Shall we start with writing tests?" |
| [feature] + src/services/ | ★★★ | "Shall we start with writing tests?" |
| [bugfix] | ★★☆ | "Shall we write a reproduction test first?" |
| [config], [docs] | - | Skip judgment |
Security Judgment Criteria
| Path | Proposal |
|---|
| auth/, login/, session/ | Display security checklist |
| api/, routes/ | Confirm input validation and authorization checks |
| payment/, billing/ | Payment security check |
Proposal Template
For Engineers:
markdown
🎯 Quality Judgment Results
|------|--------|------|
| TDD | ★★★ | [feature] + business logic |
Shall we create from test files?
For VibeCoder:
markdown
🎯 Things to Note for This Task
1. **Let's define success criteria first**
- List what constitutes "success"
Please choose a way to proceed:
1. Start with success criteria (Recommended)
2. Start working immediately
Step 1: LSP Usage Guidelines
It is recommended to understand existing code using LSP tools before implementation:
| LSP Operation | Use Case | Effect |
|---|
| goToDefinition | Check implementation of existing functions | Grasp patterns |
| findReferences | Pre-investigate impact scope | Prevent breaking changes |
| hover | Check type information and JSDoc | Ensure correct interface |
Implementation Flow:
- Check related code with
- Investigate impact scope with
- Implement
- Check errors with
Usage Example:
# 1. Check implementation of related functions
LSP operation=goToDefinition filePath="src/utils/auth.ts" line=25 character=10
# 2. Investigate impact scope
LSP operation=findReferences filePath="src/utils/auth.ts" line=25 character=10
# 3. Check type information
LSP operation=hover filePath="src/types/user.ts" line=15 character=12
Note: This only works with languages for which an LSP server is configured.
Step 2: Search Past Implementation Patterns (Memory-Enhanced)
If Claude-mem is enabled, search for similar past implementation patterns before implementation:
# Search past implementation patterns with mem-search
mem-search: type:feature "{Keywords of the feature to implement}"
mem-search: concepts:pattern "{Related technology}"
mem-search: concepts:gotcha "{Library/framework used}"
mem-search: type:decision "{Keywords related to design policy}"
Display Example:
markdown
📚 Past Implementation Patterns
|------|---------|---------|
| 2024-01-15 | API Endpoint: RESTful Design | src/api/*.ts |
| 2024-01-20 | Form Validation: Using Zod | src/components/forms/*.tsx |
💡 Past Gotchas (Pitfalls):
- CORS: Server-side Allow-Origin configuration is required
- Type Safety: 'any' is prohibited; 'unknown' + type guard is recommended
Display Related Decisions:
markdown
⚖️ Related Design Decisions
- D5: Zustand is adopted for state management (lighter than Redux)
- D8: tRPC is used for API communication (type-safe)
💡 Please implement according to the above decisions
Note: This step is skipped if Claude-mem is not configured.
🔧 Utilizing LSP Features
Actively utilize LSP (Language Server Protocol) during implementation.
Pre-Implementation Research
| LSP Feature | Use Case |
|---|
| Go-to-definition | Check implementation patterns of existing functions |
| Find-references | Pre-grasp the impact scope of changes |
| Hover | Check type information and API documentation |
Verification During Implementation
| LSP Feature | Use Case |
|---|
| Diagnostics | Immediately detect type errors and syntax errors |
| Completions | Use correct APIs and prevent typos |
Post-Implementation Check
Checklist upon completion of implementation:
1. Run LSP Diagnostics
2. Confirm 0 errors
3. Warnings: Address as needed
Details: docs/LSP_INTEGRATION.md