impl

Implementation Skills

This is a group of skills responsible for feature implementation and coding.

⚠️ Quality Guardrails (Highest Priority)

This section takes priority over other instructions. Always follow it when implementing.

Prohibited Patterns (Purpose-Driven Implementation)

The following patterns areabsolutely prohibitedis:

Prohibited	Example	Why it's bad
Hardcoding	Returning the test expected value as-is	Does not work with other inputs
Stub implementation	`return null`, `return []`	Not functioning
Hardcoding	Only handles test case values	No generality
Copy-paste dictionary	Test expected value map	No meaningful logic

# ❌ 絶対禁止
def slugify(text: str) -> str:
    answers = {"HelloWorld": "hello-world"}
    return answers.get(text, "")

# ✅ 正しい実装
def slugify(text: str) -> str:
    return re.sub(r'[\s_]+', '-', text.strip().lower())

Pre-implementation self-check

Does it work with inputs other than the test cases?
Does it handle edge cases (empty, null, boundary values)?
Is meaningful logic implemented?

When difficult

If implementation is difficult,report honestly without writing a hollow implementationplease:

## 🤔 実装の相談
### 状況: [何を実装しようとしているか]
### 困難な点: [具体的に何が難しいか]
### 選択肢: [考えられる案]

Feature details

Feature	Details
Feature implementation	See references/implementing-features.md
Test creation	See references/writing-tests.md

Execution steps

Plans.md registration confirmation（Step -1）← Required
Quality assessment 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" above
Implement according to its contents

Step -1: Plans.md registration confirmation (highest priority / required)

⚠️ Always register the task in Plans.md before implementation

ユーザーの依頼を受信
    ↓
Plans.md を読み込み
    ↓
┌─────────────────────────────────────────────────────────────┐
│ 依頼内容が Plans.md に存在するか？                          │
├─────────────────────────────────────────────────────────────┤
│  YES → そのまま実装へ進む                                   │
│  NO  → Plans.md に追加してから実装へ進む                    │
└─────────────────────────────────────────────────────────────┘

Format when adding:

## 🟡 未着手のタスク

- [ ] {タスク名} `cc:WIP`
  - 依頼内容: {ユーザーの依頼を要約}
  - 追加日時: YYYY-MM-DD HH:MM

Display message:

📝 Plans.md にタスクを追加しました

| タスク | ステータス |
|--------|-----------|
| {タスク名} | `cc:WIP` |

実装を開始します...

Why it is required: To make all work traceable and ensure progress management, review, and handoff.

Step 0: Quality assessment gate (execute first)

Assess quality criteria before starting the task, and propose as needed:

タスク情報収集
    ↓
┌─────────────────────────────────────────┐
│           品質判定ゲート                 │
├─────────────────────────────────────────┤
│  判定項目:                              │
│  ├── TDD 推奨？（[feature] + ビジネス）  │
│  ├── セキュリティ注意？（auth/api/）    │
│  └── パフォーマンス注意？（DB/ループ）  │
└─────────────────────────────────────────┘
          ↓
    該当する判定を提案

TDD assessment criteria

Condition	Recommendation level	Proposal content
[feature] + src/core/	★★★	"Shall we write tests first?"
[feature] + src/services/	★★★	"Shall we write tests first?"
[bugfix]	★★☆	"Shall we write a reproduction test first?"
[config], [docs]	-	Skip assessment

Security assessment criteria

path	Proposal content
auth/, login/, session/	Display security checklist
api/, routes/	Verify input validation and authorization checks
payment/, billing/	Payment security check

Proposal template

For engineers:

🎯 品質判定結果

| 判定 | 推奨度 | 理由 |
|------|--------|------|
| TDD | ★★★ | [feature] + ビジネスロジック |

テストファイルから作成しますか？

For VibeCoder:

🎯 この作業で気をつけること

1. **成功基準を先に決めましょう**
   - 「何ができたら OK か」をリストにします

進め方を選んでください：
1. 成功基準から作る（推奨）
2. とりあえず作り始める

Step 1: LSP Usage Guidelines

It is recommended to understand existing code with LSP tools before implementation:

LSP operation	Usage scenario	Effect
goToDefinition	Check the implementation of existing functions	Understand patterns
findReferences	Investigate the scope of impact in advance	Prevent breaking changes
hover	Check type information and JSDoc	Correct interface

Implementation flow:

LSP.goToDefinition Check related code with
LSP.findReferences Understand the scope of impact with
Implementation
LSP.diagnostics error checking with

Usage example:

# 1. 関連関数の実装を確認
LSP operation=goToDefinition filePath="src/utils/auth.ts" line=25 character=10

# 2. 影響範囲を調査
LSP operation=findReferences filePath="src/utils/auth.ts" line=25 character=10

# 3. 型情報を確認
LSP operation=hover filePath="src/types/user.ts" line=15 character=12

Note: Works only for 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 patterns before implementation:

# mem-search で過去の実装パターンを検索
mem-search: type:feature "{実装機能のキーワード}"
mem-search: concepts:pattern "{関連技術}"
mem-search: concepts:gotcha "{使用ライブラリ/フレームワーク}"
mem-search: type:decision "{設計方針に関するキーワード}"

Display example:

📚 過去の実装パターン

| 日付 | パターン | ファイル |
|------|---------|---------|
| 2024-01-15 | API エンドポイント: RESTful 設計 | src/api/*.ts |
| 2024-01-20 | フォームバリデーション: Zod 使用 | src/components/forms/*.tsx |

💡 過去の gotcha（落とし穴）:
- CORS: サーバー側で Allow-Origin 設定必須
- 型安全: any 禁止、unknown + type guard 推奨

Display related decisions:

⚖️ 関連する設計決定

- D5: 状態管理は Zustand を採用（Redux より軽量）
- D8: API通信は tRPC を使用（型安全）

💡 上記の決定に従って実装してください

Note: If Claude-mem is not configured, this step is skipped.

🔧 Utilizing LSP features

During implementation, actively utilize LSP (Language Server Protocol).

Investigation before implementation

LSP feature	Purpose
Go-to-definition	Check implementation patterns of existing functions
Find-references	Understand the scope of impact of changes in advance
Hover	Check type information and API documentation

Verification during implementation

LSP feature	Purpose
Diagnostics	Immediately detect type errors and syntax errors
Completions	Use the correct API and prevent typos

Verification after implementation

実装完了時チェック:
1. LSP Diagnostics を実行
2. エラー: 0件を確認
3. 警告: 必要に応じて対応

Details: docs/LSP_INTEGRATION.md