Back to Details

impl

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Implementation Skills

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.

禁止パターン（Purpose-Driven Implementation）

Prohibited Patterns (Purpose-Driven Implementation)

実装時に以下のパターンは絶対に禁止です：
禁止例なぜダメか
ハードコードテスト期待値をそのまま返す他の入力で動作しない
スタブ実装
return null
, 
return []
機能していない
決め打ちテストケースの値だけ対応汎用性がない
コピペ辞書テストの期待値マップ意味あるロジックがない
python
undefined
The following patterns are strictly prohibited during implementation:
ProhibitedExampleReason for Prohibition
HardcodingReturning test expected values as-isDoes not work with other inputs
Stub Implementation
return null
, 
return []
Does not function properly
Hardcoded Test Case HandlingOnly handles values from test casesLacks generality
Copy-Paste DictionaryTest expected value mapNo meaningful logic
python
undefined

❌ 絶対禁止

❌ Strictly prohibited

def slugify(text: str) -> str: answers = {"HelloWorld": "hello-world"} return answers.get(text, "")
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())
undefined
def slugify(text: str) -> str: return re.sub(r'[\s_]+', '-', text.strip().lower())
undefined

実装前セルフチェック

Pre-Implementation Self-Check

  • テストケース以外の入力でも動作するか？
  • エッジケース（空、null、境界値）を処理しているか？
  • 意味のあるロジックを実装しているか？
  • Does it work with inputs other than test cases?
  • Are edge cases (empty, null, boundary values) handled?
  • Is meaningful logic implemented?

困難な場合

When Facing Difficulties

実装が難しい場合は、形骸化実装を書かずに正直に報告してください：
markdown
undefined
If implementation is difficult, do not write a dummy implementation; report honestly using the following format:
markdown
undefined

🤔 実装の相談

🤔 Implementation Consultation

状況: [何を実装しようとしているか]

Situation: [What you are trying to implement]

困難な点: [具体的に何が難しいか]

Difficulties: [Specific challenges]

選択肢: [考えられる案]

Options: [Possible solutions]

undefined
undefined

機能詳細

Feature Details

機能詳細
機能実装See references/implementing-features.md
テスト作成See references/writing-tests.md
FeatureDetails
Feature ImplementationSee references/implementing-features.md
Test CreationSee references/writing-tests.md

実行手順

Execution Steps

  1. Plans.md 登録確認（Step -1）← 必須
  2. 品質判定ゲート（Step 0）
  3. ユーザーのリクエストを分類
  4. （Claude-mem 有効時）過去の実装パターンを検索
  5. 上記の「機能詳細」から適切な参照ファイルを読む
  6. その内容に従って実装
  1. Plans.md Registration Check (Step -1) ← Required
  2. Quality Check Gate (Step 0)
  3. Classify the user's request
  4. (When Claude-mem is enabled) Search past implementation patterns
  5. Read the appropriate reference file from the "Feature Details" section above
  6. Implement according to the content

Step -1: Plans.md 登録確認（最優先・必須）

Step -1: Plans.md Registration Check (Top Priority, Required)

⚠️ 実装前に必ず Plans.md にタスクを登録する
ユーザーの依頼を受信
    ↓
Plans.md を読み込み
    ↓
┌─────────────────────────────────────────────────────────────┐
│ 依頼内容が Plans.md に存在するか？                          │
├─────────────────────────────────────────────────────────────┤
│  YES → そのまま実装へ進む                                   │
│  NO  → Plans.md に追加してから実装へ進む                    │
└─────────────────────────────────────────────────────────────┘
追加時のフォーマット:
markdown
undefined
⚠️ 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
undefined

🟡 未着手のタスク

🟡 Unstarted Tasks

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

**表示メッセージ**:

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

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

実装を開始します...
なぜ必須か: 全ての作業を追跡可能にし、進捗管理・レビュー・ハンドオフを確実にするため。
  • {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 | Status |
|--------|-----------|
| {Task Name} | `cc:WIP` |

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

Step 0: 品質判定ゲート（最初に実行）

Step 0: Quality Check Gate (Execute First)

タスク開始前に品質基準を判定し、必要に応じて提案:
タスク情報収集
    ↓
┌─────────────────────────────────────────┐
│           品質判定ゲート                 │
├─────────────────────────────────────────┤
│  判定項目:                              │
│  ├── TDD 推奨？（[feature] + ビジネス）  │
│  ├── セキュリティ注意？（auth/api/）    │
│  └── パフォーマンス注意？（DB/ループ）  │
└─────────────────────────────────────────┘
          ↓
    該当する判定を提案
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 判定基準

TDD Judgment Criteria

条件推奨度提案内容
[feature] + src/core/★★★「テストから書きますか？」
[feature] + src/services/★★★「テストから書きますか？」
[bugfix]★★☆「再現テストを先に書きますか？」
[config], [docs]-判定スキップ
ConditionRecommendation LevelProposal
[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

パス提案内容
auth/, login/, session/セキュリティチェックリスト表示
api/, routes/入力検証・認可チェック確認
payment/, billing/決済セキュリティチェック
PathProposal
auth/, login/, session/Display security checklist
api/, routes/Confirm input validation and authorization checks
payment/, billing/Payment security check

提案テンプレート

Proposal Template

エンジニア向け:
markdown
🎯 品質判定結果

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

テストファイルから作成しますか？
VibeCoder 向け:
markdown
🎯 この作業で気をつけること

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

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

| Judgment | Recommendation Level | Reason |
|------|--------|------|
| 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 活用ガイドライン

Step 1: LSP Usage Guidelines

実装前に LSP ツールで既存コードを理解することを推奨:
LSP 操作活用場面効果
goToDefinition既存関数の実装を確認パターン把握
findReferences影響範囲の事前調査破壊的変更防止
hover型情報・JSDoc 確認正しいインターフェース
実装フロー:
  1. LSP.goToDefinition
    で関連コードを確認
  2. LSP.findReferences
    で影響範囲を把握
  3. 実装
  4. LSP.diagnostics
    でエラーチェック
使用例:
undefined
It is recommended to understand existing code using LSP tools before implementation:
LSP OperationUse CaseEffect
goToDefinitionCheck implementation of existing functionsGrasp patterns
findReferencesPre-investigate impact scopePrevent breaking changes
hoverCheck type information and JSDocEnsure correct interface
Implementation Flow:
  1. Check related code with 
    LSP.goToDefinition
  2. Investigate impact scope with 
    LSP.findReferences
  3. Implement
  4. Check errors with 
    LSP.diagnostics
Usage Example:
undefined

1. 関連関数の実装を確認

1. Check implementation of related functions

LSP operation=goToDefinition filePath="src/utils/auth.ts" line=25 character=10
LSP operation=goToDefinition filePath="src/utils/auth.ts" line=25 character=10

2. 影響範囲を調査

2. Investigate impact scope

LSP operation=findReferences filePath="src/utils/auth.ts" line=25 character=10
LSP operation=findReferences filePath="src/utils/auth.ts" line=25 character=10

3. 型情報を確認

3. Check type information

LSP operation=hover filePath="src/types/user.ts" line=15 character=12

> **注**: LSP サーバーが設定されている言語でのみ動作します。
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: 過去の実装パターン検索（Memory-Enhanced）

Step 2: Search Past Implementation Patterns (Memory-Enhanced)

Claude-mem が有効な場合、実装前に過去の類似パターンを検索:
undefined
If Claude-mem is enabled, search for similar past implementation patterns before implementation:
undefined

mem-search で過去の実装パターンを検索

Search past implementation patterns with mem-search

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

**表示例**:

```markdown
📚 過去の実装パターン

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

💡 過去の gotcha（落とし穴）:
- CORS: サーバー側で Allow-Origin 設定必須
- 型安全: any 禁止、unknown + type guard 推奨
関連する決定事項の表示:
markdown
⚖️ 関連する設計決定

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

💡 上記の決定に従って実装してください
注: Claude-mem が未設定の場合、このステップはスキップされます。
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

| Date | Pattern | File |
|------|---------|---------|
| 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.

🔧 LSP 機能の活用

🔧 Utilizing LSP Features

実装時には LSP（Language Server Protocol）を積極的に活用します。
Actively utilize LSP (Language Server Protocol) during implementation.

実装前の調査

Pre-Implementation Research

LSP 機能用途
Go-to-definition既存関数の実装パターンを確認
Find-references変更の影響範囲を事前把握
Hover型情報・API ドキュメントを確認
LSP FeatureUse Case
Go-to-definitionCheck implementation patterns of existing functions
Find-referencesPre-grasp the impact scope of changes
HoverCheck type information and API documentation

実装中の検証

Verification During Implementation

LSP 機能用途
Diagnostics型エラー・構文エラーを即座に検出
Completions正しい API を使用、タイポ防止
LSP FeatureUse Case
DiagnosticsImmediately detect type errors and syntax errors
CompletionsUse correct APIs and prevent typos

実装後の確認

Post-Implementation Check

実装完了時チェック:
1. LSP Diagnostics を実行
2. エラー: 0件を確認
3. 警告: 必要に応じて対応
詳細: docs/LSP_INTEGRATION.md
Checklist upon completion of implementation:
1. Run LSP Diagnostics
2. Confirm 0 errors
3. Warnings: Address as needed
Details: docs/LSP_INTEGRATION.md