implement
機能実装、API追加、重要なコード変更時に、事前チェック、テスト駆動開発、範囲限定、品質コミットをまとめて行い、手戻りを減らしてスムーズな開発を進めるSkill。
📜 元の英語説明(参考)
Full feature pipeline — pre-flight checks, TDD cycle, scope guard, quality commit. Combines pre-flight + tdd + scope-check + quality-commit into one flow. Use when implementing a feature, adding an endpoint, or building any non-trivial code change.
🇯🇵 日本人クリエイター向け解説
機能実装、API追加、重要なコード変更時に、事前チェック、テスト駆動開発、範囲限定、品質コミットをまとめて行い、手戻りを減らしてスムーズな開発を進めるSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o implement.zip https://jpskill.com/download/9165.zip && unzip -o implement.zip && rm implement.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9165.zip -OutFile "$d\implement.zip"; Expand-Archive "$d\implement.zip" -DestinationPath $d -Force; ri "$d\implement.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
implement.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
implementフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
実装
エンドツーエンドの機能実装パイプラインです。事前検証、TDDサイクル、スコープの強制、および品質コミットを、単一のオーケストレーションされたフローとして実行します。
パイプラインのフェーズ
フェーズ 0: 事前検証 (30秒未満)
コードを記述する前に、ワークスペースの準備ができていることを検証します。
- Git status — 競合する可能性のある未コミットの変更がないか確認します
- Monorepo freshness — 共有/ライブラリパッケージが存在する場合、ソースがコンパイルされた出力よりも新しいかどうかを確認します。新しい場合は、最初にリビルドします。
- Workspace typecheck — ターゲットワークスペースで
tsc --noEmit(または同等のもの) を実行します - Existing test check — ターゲットモジュールのテストファイルが存在する場合は、それを実行して、緑色のベースラインを確認します
いずれかのチェックが失敗した場合は、コードを記述する前に、ユーザーに報告し、どのように進めるかを尋ねます。
フェーズ 1: 理解と計画 (まだコードなし)
$ARGUMENTSで言及されているターゲットファイルを読みます- モジュールタイプ (ルートハンドラー、リポジトリ、プラグイン、ユーティリティ、サービス、コンポーネント) を識別します
- モック戦略を決定します — 最寄りのテストファイルで確立されたパターンを確認します
- 記述するテストと追加する実装を計画します
簡単な概要を提示します: "YをカバーするX個のテストを追加し、Zを実装します。" スコープが大きいと思われる場合 (3つ以上のファイル)、ユーザーの確認を待ちます。
フェーズ 2: ブートストラップモック (1つのテスト)
/tdd のステップ3に正確に従ってください:
- モックのリセット/リストア設定について、テストランナーの設定を確認します
- モジュールをインポートし、モックが解決されることを検証する、最小限のテストを1つ記述します
- 実行して、合格することを確認します
- 失敗した場合は、続行する前にモックの配線を診断します
フェーズ 3: レッド — 失敗するテストの記述
次のテストケースを記述します:
- ハッピーパス
- エッジケース
- エラーケース
テストファイルを実行します — すべての新しいテストは失敗する必要があります。予期せずに合格するものがある場合、テストは新しい動作をテストしていません。
フェーズ 4: グリーン — 最小限の実装
すべてのテストに合格するために、最小限のコードを記述します。以下はしないでください:
- テストでカバーされていない機能を追加する
- 早すぎる最適化
- 既存のコードのリファクタリング
テストファイルを実行します — すべてのテストに合格する必要があります。
フェーズ 5: スコープガード
コミットする前に、変更を自己監査します:
git diff --name-onlyを実行して、変更されたすべてのファイルを確認します$ARGUMENTSからの元のタスクと比較します- タスクに関係のないファイルにフラグを立てます:
- フォーマットのみの変更 →
git checkout -- <file>で元に戻します - 関係のないリファクタリング → 元に戻すか、別のコミットに分割します
- 変更されていないコードへのドキュメンテーション文字列の追加 → 元に戻します
- フォーマットのみの変更 →
スコープの肥大化が検出された場合は、それを報告し、ユーザーに追加の変更を保持するか元に戻すかを尋ねます。
フェーズ 6: フルスイート + 品質ゲート
- フルテストスイートを実行します (例:
npx vitest run --reporter=dot) - ワークスペースのタイプチェックを実行します (
tsc --noEmitまたは同等のもの) - 変更されたファイルのみでリンターを実行します
いずれかのゲートが失敗した場合:
- テストの失敗: 変更が原因であるか (リグレッション)、または既存のものかを判断します
- タイプエラー: 修正します
- ファイル内のLintエラー: 修正します
- 触れていないファイル内のLintエラー: 無視し、コミットメッセージにメモします
フェーズ 7: コミット
変更したファイルのみをステージングします (絶対に git add -A しないでください)。従来の形式でコミットします:
type(scope): description
Co-Authored-By: Claude <noreply@anthropic.com>
中止条件
パイプラインを停止し、次の場合にユーザーに尋ねます:
- 事前検証でワークスペースが壊れた状態であることが判明した場合
- 5つ以上のファイルを変更する必要がある場合 (スコープが大きすぎる可能性があります)
- ブートストラップモックテストが2回試行しても失敗する場合
- フルスイートのリグレッションが変更によって引き起こされた場合
引数
$ARGUMENTS: 実装する内容- 例:
/implement POST /api/search にレート制限を追加する - 例:
/implement src/routes/admin/settings.ts — テーマのPATCHエンドポイントを追加する - 空の場合、ユーザーに実装する内容を尋ねます
- 例:
統合
このスキルは以下をオーケストレーションします:
/tdd— フェーズ 2-4 (モックブートストラップ、レッド、グリーン)/quality-commit— フェーズ 7 (ゲートによるステージングとコミット)
完全なパイプラインカバレッジのために、これらを個別に呼び出す代わりに /implement を使用してください。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Implement
End-to-end feature implementation pipeline. Runs pre-flight validation, TDD cycle, scope enforcement, and quality commit as a single orchestrated flow.
Pipeline Phases
Phase 0: Pre-flight (< 30 seconds)
Before writing any code, validate the workspace is ready:
- Git status — check for uncommitted changes that might conflict
- Monorepo freshness — if shared/library packages exist, check if source is newer than compiled output. If yes, rebuild first.
- Workspace typecheck — run
tsc --noEmit(or equivalent) on the target workspace - Existing test check — if a test file exists for the target module, run it to confirm green baseline
If any check fails, report and ask the user how to proceed before writing code.
Phase 1: Understand & Plan (no code yet)
- Read the target file(s) mentioned in
$ARGUMENTS - Identify the module type (route handler, repository, plugin, utility, service, component)
- Determine the mock strategy — check nearest test files for established patterns
- Plan what tests to write and what implementation to add
Present a brief summary: "I'll add X tests covering Y, then implement Z." Wait for user confirmation if the scope seems large (> 3 files).
Phase 2: Bootstrap Mock (1 test)
Follow /tdd Step 3 exactly:
- Check test runner config for mock reset/restore settings
- Write ONE minimal test that imports the module and verifies mocks resolve
- Run it, confirm it passes
- If it fails, diagnose mock wiring before proceeding
Phase 3: Red — Write Failing Tests
Write test cases for:
- Happy path
- Edge cases
- Error cases
Run the test file — all new tests MUST fail. If any pass unexpectedly, the tests aren't testing new behavior.
Phase 4: Green — Minimum Implementation
Write the minimum code to make all tests pass. Do NOT:
- Add features not covered by tests
- Optimize prematurely
- Refactor existing code
Run the test file — all tests MUST pass.
Phase 5: Scope Guard
Before committing, self-audit the changes:
- Run
git diff --name-onlyto see all modified files - Compare against the original task from
$ARGUMENTS - Flag any files that don't relate to the task:
- Formatting-only changes → revert with
git checkout -- <file> - Unrelated refactors → revert or split into separate commit
- Docstring additions to untouched code → revert
- Formatting-only changes → revert with
If scope creep is detected, report it and ask the user whether to keep or revert the extra changes.
Phase 6: Full Suite + Quality Gates
- Run the full test suite (e.g.,
npx vitest run --reporter=dot) - Run workspace typecheck (
tsc --noEmitor equivalent) - Run linter on changed files only
If any gate fails:
- Test failure: determine if your change caused it (regression) or pre-existing
- Type error: fix it
- Lint error in your files: fix it
- Lint error in files you didn't touch: ignore, note in commit message
Phase 7: Commit
Stage only the files you changed (NEVER git add -A). Commit with conventional format:
type(scope): description
Co-Authored-By: Claude <noreply@anthropic.com>
Abort Conditions
STOP the pipeline and ask the user if:
- Pre-flight finds the workspace in a broken state
- More than 5 files need modification (scope may be too large)
- Bootstrap mock test fails after 2 attempts
- Full suite regression is caused by your changes
Arguments
$ARGUMENTS: What to implement- Example:
/implement add rate limiting to POST /api/search - Example:
/implement src/routes/admin/settings.ts — add PATCH endpoint for theme - If empty, ask the user what to implement
- Example:
Integration
This skill orchestrates:
/tdd— Phase 2-4 (mock bootstrap, red, green)/quality-commit— Phase 7 (stage + commit with gates)
Use /implement instead of calling these individually for full pipeline coverage.