jpskill.com
🛠️ 開発・MCP コミュニティ

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本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して implement.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → implement フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

実装

エンドツーエンドの機能実装パイプラインです。事前検証、TDDサイクル、スコープの強制、および品質コミットを、単一のオーケストレーションされたフローとして実行します。

パイプラインのフェーズ

フェーズ 0: 事前検証 (30秒未満)

コードを記述する前に、ワークスペースの準備ができていることを検証します。

  1. Git status — 競合する可能性のある未コミットの変更がないか確認します
  2. Monorepo freshness — 共有/ライブラリパッケージが存在する場合、ソースがコンパイルされた出力よりも新しいかどうかを確認します。新しい場合は、最初にリビルドします。
  3. Workspace typecheck — ターゲットワークスペースで tsc --noEmit (または同等のもの) を実行します
  4. Existing test check — ターゲットモジュールのテストファイルが存在する場合は、それを実行して、緑色のベースラインを確認します

いずれかのチェックが失敗した場合は、コードを記述する前に、ユーザーに報告し、どのように進めるかを尋ねます。

フェーズ 1: 理解と計画 (まだコードなし)

  1. $ARGUMENTS で言及されているターゲットファイルを読みます
  2. モジュールタイプ (ルートハンドラー、リポジトリ、プラグイン、ユーティリティ、サービス、コンポーネント) を識別します
  3. モック戦略を決定します — 最寄りのテストファイルで確立されたパターンを確認します
  4. 記述するテストと追加する実装を計画します

簡単な概要を提示します: "YをカバーするX個のテストを追加し、Zを実装します。" スコープが大きいと思われる場合 (3つ以上のファイル)、ユーザーの確認を待ちます。

フェーズ 2: ブートストラップモック (1つのテスト)

/tdd のステップ3に正確に従ってください:

  1. モックのリセット/リストア設定について、テストランナーの設定を確認します
  2. モジュールをインポートし、モックが解決されることを検証する、最小限のテストを1つ記述します
  3. 実行して、合格することを確認します
  4. 失敗した場合は、続行する前にモックの配線を診断します

フェーズ 3: レッド — 失敗するテストの記述

次のテストケースを記述します:

  • ハッピーパス
  • エッジケース
  • エラーケース

テストファイルを実行します — すべての新しいテストは失敗する必要があります。予期せずに合格するものがある場合、テストは新しい動作をテストしていません。

フェーズ 4: グリーン — 最小限の実装

すべてのテストに合格するために、最小限のコードを記述します。以下はしないでください:

  • テストでカバーされていない機能を追加する
  • 早すぎる最適化
  • 既存のコードのリファクタリング

テストファイルを実行します — すべてのテストに合格する必要があります。

フェーズ 5: スコープガード

コミットする前に、変更を自己監査します:

  1. git diff --name-only を実行して、変更されたすべてのファイルを確認します
  2. $ARGUMENTS からの元のタスクと比較します
  3. タスクに関係のないファイルにフラグを立てます:
    • フォーマットのみの変更 → git checkout -- <file> で元に戻します
    • 関係のないリファクタリング → 元に戻すか、別のコミットに分割します
    • 変更されていないコードへのドキュメンテーション文字列の追加 → 元に戻します

スコープの肥大化が検出された場合は、それを報告し、ユーザーに追加の変更を保持するか元に戻すかを尋ねます。

フェーズ 6: フルスイート + 品質ゲート

  1. フルテストスイートを実行します (例: npx vitest run --reporter=dot)
  2. ワークスペースのタイプチェックを実行します (tsc --noEmit または同等のもの)
  3. 変更されたファイルのみでリンターを実行します

いずれかのゲートが失敗した場合:

  • テストの失敗: 変更が原因であるか (リグレッション)、または既存のものかを判断します
  • タイプエラー: 修正します
  • ファイル内の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:

  1. Git status — check for uncommitted changes that might conflict
  2. Monorepo freshness — if shared/library packages exist, check if source is newer than compiled output. If yes, rebuild first.
  3. Workspace typecheck — run tsc --noEmit (or equivalent) on the target workspace
  4. 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)

  1. Read the target file(s) mentioned in $ARGUMENTS
  2. Identify the module type (route handler, repository, plugin, utility, service, component)
  3. Determine the mock strategy — check nearest test files for established patterns
  4. 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:

  1. Check test runner config for mock reset/restore settings
  2. Write ONE minimal test that imports the module and verifies mocks resolve
  3. Run it, confirm it passes
  4. 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:

  1. Run git diff --name-only to see all modified files
  2. Compare against the original task from $ARGUMENTS
  3. 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

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

  1. Run the full test suite (e.g., npx vitest run --reporter=dot)
  2. Run workspace typecheck (tsc --noEmit or equivalent)
  3. 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

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.