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

check-plan

Audit implementation progress against a plan, verify completed work, identify remaining tasks, and validate quality. Use when user asks to check plan status, verify implementation, see what's left to do, or validate plan completion.

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

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

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o check-plan.zip https://jpskill.com/download/18223.zip && unzip -o check-plan.zip && rm check-plan.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/18223.zip -OutFile "$d\check-plan.zip"; Expand-Archive "$d\check-plan.zip" -DestinationPath $d -Force; ri "$d\check-plan.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して check-plan.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → check-plan フォルダができる
  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 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

計画の実装の確認

手順

計画に対する実装の進捗状況を包括的に監査し、完了した作業の品質を検証し、残りの項目について実行可能なタスクリストを生成します。

フェーズ 1: セットアップと発見

ステップ 1: 計画の特定

  • ユーザーに確認する計画を尋ねる(またはコンテキストから特定する)
  • .plans/ から計画ファイルを読み込む
  • すべての計画項目と要件を理解する

ステップ 2: Git コンテキストの取得 (該当する場合)

# 変更されたファイルを確認
git status

# 詳細な変更を確認
git diff

# このブランチのコミット履歴を確認
git log --oneline -20

これは、行われた変更の範囲を理解するのに役立ちます。

ステップ 3: 影響を受けるすべてのファイルの特定

包括的なリストを作成します。

  1. 計画に記載されているファイル
  2. git status に表示されるファイル
  3. 影響を受ける可能性のあるファイル (Glob/Grep を使用)

確認するファイルごとに 1 つの項目を含む ToDo リストを作成します。

フェーズ 2: ファイルごとの体系的な監査

ToDo リストの各ファイルについて:

ステップ 1: ファイルの読み込み

  • Read ツールを使用して現在の状態を調べる
  • このファイルに関する以前のメモがないか、メモリ/コンテキストを確認する

ステップ 2: 計画項目へのマッピング

どの計画ステップがこのファイルに関連するかを特定します。

  • どの実装ステップがこのファイルに言及していますか?
  • どのような変更が行われるはずでしたか?
  • 計画のどの要件がここに適用されますか?

ステップ 3: 実装の検証

計画された変更が存在するかどうかを確認します。

  • DONE: 実装が計画の要件と一致する
  • ⚠️ PARTIAL: いくつかの作業は完了したが、不完全
  • NOT DONE: まだ実装されていない
  • 🔍 NEEDS REVIEW: 実装は存在するが、計画と一致しない可能性がある

ファイルごとに、以下を評価します。

  • 計画された機能は実装されていますか?
  • コードの品質は良好ですか?
  • 型は正しく使用されていますか (any はないか)?
  • CLAUDE.md のガイドラインに従っていますか?
  • 完了していますか、それとも部分的ですか?

ステップ 4: 品質検証

実装の品質を確認します。

  • Correctness: 計画どおりに動作しますか?
  • Types: 適切な型付け、any はないか、既存の型を使用していますか?
  • Naming: 計画の規則に従っていますか?
  • Architecture: 計画された設計と一致していますか?
  • Completeness: 計画ステップのすべての詳細が実装されていますか?

ステップ 5: 評価の記録

メモリに保存します。

File: path/to/file.ts
Plan Item: Step X - [description]
Status: [DONE|PARTIAL|NOT DONE|NEEDS REVIEW]
Notes: [何が良いか、何が欠けているか、何を修正する必要があるか]
Quality Issues: [見つかった問題]

ステップ 6: ToDo の更新

ToDo リストで、ファイルを確認済みにマークします。

フェーズ 3: REMOVAL SPEC の検証

重要: 古いコードが実際に削除されたことを確認します。

ステップ 1: 計画から REMOVAL SPEC を読み取る

削除対象としてリストされているすべての項目を抽出します。

  • 削除するコード (ファイル/行番号付き)
  • 削除するファイル
  • 廃止された削除する関数

ステップ 2: 各削除の検証

REMOVAL SPEC の各項目について:

  1. 削除するコードの場合:

    # 古いコードがまだ存在するかどうかを確認
    grep -n "old_function_name" path/to/file.ts
    • ✅ 見つからない場合: コードは正常に削除されました
    • ❌ 見つかった場合: コードはまだ存在します (NOT DONE)
  2. 削除するファイルの場合:

    # ファイルがまだ存在するかどうかを確認
    ls path/to/old-file.ts
    • ✅ 見つからない場合: ファイルは正常に削除されました
    • ❌ 見つかった場合: ファイルはまだ存在します (NOT DONE)
  3. 廃止されたインポート/参照の場合:

    # コードベース全体を検索
    grep -r "old_symbol" src/
    • ✅ 見つからない場合: すべての参照が削除されました
    • ❌ 見つかった場合: 参照はまだ存在します (NOT DONE)

ステップ 3: 削除ステータスの記録

  • 削除されるはずだったものをリストする
  • 実際に削除されたものをリストする
  • 削除されなかった項目を HIGH PRIORITY タスクとしてフラグを立てる

フェーズ 3.5: 元の問題/タスクのカバレッジ検証 (必須)

重要: 実装が計画ステップだけでなく、元の問題/タスクの要件の 100% をカバーしていることを確認します。

ステップ 1: 元の問題/タスクの特定

ソース要件を見つけます。

  • この計画をトリガーした GitHub issue: gh issue view <number>
  • 元のタスクの説明またはチケット
  • 作業を開始したユーザーリクエスト

ステップ 2: 元のすべての要件の抽出

元の issue/タスクから、以下を抽出します。

  • すべての機能要件
  • すべての受け入れ基準
  • 言及されているすべてのエッジケース
  • すべてのエラー処理要件
  • 暗黙的な要件

ステップ 3: 要件から実装へのマッピング

# Original Requirement Plan Step Implementation Status
1 [from issue] Step X ✅/❌/⚠️
2 [from issue] Step Y ✅/❌/⚠️
3 [from issue] N/A (missing from plan!)

ステップ 4: カバレッジギャップの特定

2 種類のギャップ:

  1. 計画のギャップ: issue からの要件で、計画に取り込まれていないもの
  2. 実装のギャップ: 計画ステップで、完全に実装されていないもの

どちらも不完全なカバレッジとしてカウントされます。

ステップ 5: カバレッジの評価

Issue Coverage = (Implemented Original Requirements / Total Original Requirements) × 100%

100% 未満の場合 = PLAN NOT COMPLETE

フェーズ 4: ギャップ分析

ステップ 1: スコープクリープの特定

計画にない変更されたファイル:

  • なぜ変更されたのですか?
  • 変更は必要でしたか?
  • それらを反映するように計画を更新する必要がありますか?

ステップ 2: 未完了の作業の特定

対応する実装がない計画項目:

  • どのステップが開始されていませんか?
  • どのステップが部分的に完了していますか?
  • 完了を妨げているものは何ですか?

ステップ 3: Issue カバレッジギャップの特定 (HIGH PRIORITY)

実装にない元の issue からの要件:

  • どの issue 要件が欠落していますか?
  • 計画または実装で見逃されましたか?
  • これらは計画ステップの完了よりも HIGHER PRIORITY です

フェーズ 5: 進捗レポートの作成

ステップ 1: 完了率の計算

Total Plan Steps: X
Completed Steps: Y
Partial Steps: Z
Not Started: W

Completion: (Y / X) * 100%
Weighted Completion: ((Y + 0.5*Z) / X) * 100%

ステップ 2: 構造化されたレポートの生成

.plans/[plan-name].progress.md にレポートを作成します。


# Plan Progress Report: [Plan Name]
**Date**: [timestamp]
**Plan File**: [path]
**

(原文はここで切り詰められています)
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Check Plan Implementation

Instructions

Perform comprehensive audit of implementation progress against a plan, verify quality of completed work, and generate actionable task list for remaining items.

Phase 1: Setup & Discovery

Step 1: Identify the Plan

  • Ask user which plan to check (or identify from context)
  • Read the plan file from .plans/
  • Understand all plan items and requirements

Step 2: Get Git Context (if applicable)

# See what files changed
git status

# See detailed changes
git diff

# See commit history on this branch
git log --oneline -20

This helps understand scope of changes made.

Step 3: Identify All Affected Files

Create comprehensive list:

  1. Files mentioned in the plan
  2. Files shown in git status
  3. Files that might be affected (use Glob/Grep)

Create todo list with one item per file to check.

Phase 2: Systematic File-by-File Audit

For EACH file in the todo list:

Step 1: Read the File

  • Use Read tool to examine current state
  • Check memory/context for any previous notes about this file

Step 2: Map to Plan Items

Identify which plan step(s) relate to this file:

  • Which implementation steps mention this file?
  • What changes were supposed to be made?
  • What requirements from the plan apply here?

Step 3: Verify Implementation

Check if planned changes are present:

  • DONE: Implementation matches plan requirements
  • ⚠️ PARTIAL: Some work done, but incomplete
  • NOT DONE: No implementation yet
  • 🔍 NEEDS REVIEW: Implementation exists but may not match plan

For each file, assess:

  • Are planned features implemented?
  • Is code quality good?
  • Are types used correctly (no any)?
  • Does it follow CLAUDE.md guidelines?
  • Is it complete or partial?

Step 4: Quality Verification

Check implementation quality:

  • Correctness: Does it work as planned?
  • Types: Proper typing, no any, using existing types?
  • Naming: Follows conventions from plan?
  • Architecture: Matches planned design?
  • Completeness: All details from plan step implemented?

Step 5: Record Assessment

Store in memory:

File: path/to/file.ts
Plan Item: Step X - [description]
Status: [DONE|PARTIAL|NOT DONE|NEEDS REVIEW]
Notes: [What's good, what's missing, what needs fixing]
Quality Issues: [Any problems found]

Step 6: Update Todo

Mark file as checked in the todo list.

Phase 3: REMOVAL SPEC Verification

CRITICAL: Verify old code was actually removed.

Step 1: Read REMOVAL SPEC from Plan

Extract all items listed for removal:

  • Code to be removed (with file/line numbers)
  • Files to be deleted
  • Deprecated functions to eliminate

Step 2: Verify Each Removal

For each item in REMOVAL SPEC:

  1. For code to remove:

    # Check if old code still exists
    grep -n "old_function_name" path/to/file.ts
    • ✅ If not found: Code successfully removed
    • ❌ If found: Code still exists (NOT DONE)
  2. For files to delete:

    # Check if file still exists
    ls path/to/old-file.ts
    • ✅ If not found: File successfully deleted
    • ❌ If found: File still exists (NOT DONE)
  3. For deprecated imports/references:

    # Search entire codebase
    grep -r "old_symbol" src/
    • ✅ If not found: All references removed
    • ❌ If found: References still exist (NOT DONE)

Step 3: Record Removal Status

  • List what was supposed to be removed
  • List what actually was removed
  • Flag any items not removed as HIGH PRIORITY tasks

Phase 3.5: Original Issue/Task Coverage Verification (MANDATORY)

CRITICAL: Verify that the implementation covers 100% of the ORIGINAL issue/task requirements, not just the plan steps.

Step 1: Locate Original Issue/Task

Find the source requirement:

  • GitHub issue that triggered this plan: gh issue view <number>
  • Original task description or ticket
  • User request that initiated the work

Step 2: Extract ALL Original Requirements

From the original issue/task, extract:

  • Every functional requirement
  • Every acceptance criterion
  • Every edge case mentioned
  • Every error handling requirement
  • Any implicit requirements

Step 3: Map Requirements to Implementation

# Original Requirement Plan Step Implementation Status
1 [from issue] Step X ✅/❌/⚠️
2 [from issue] Step Y ✅/❌/⚠️
3 [from issue] N/A (missing from plan!)

Step 4: Identify Coverage Gaps

Two types of gaps:

  1. Plan gaps: Requirements from issue that weren't captured in plan
  2. Implementation gaps: Plan steps that weren't fully implemented

Both count toward incomplete coverage.

Step 5: Coverage Assessment

Issue Coverage = (Implemented Original Requirements / Total Original Requirements) × 100%

Anything less than 100% = PLAN NOT COMPLETE

Phase 4: Gap Analysis

Step 1: Identify Scope Creep

Files changed that are NOT in the plan:

  • Why were they changed?
  • Were changes necessary?
  • Should plan be updated to reflect them?

Step 2: Identify Missing Work

Plan items without corresponding implementation:

  • Which steps haven't been started?
  • Which steps are partially complete?
  • What's blocking completion?

Step 3: Identify Issue Coverage Gaps (HIGH PRIORITY)

Requirements from original issue not in implementation:

  • Which issue requirements are missing?
  • Were they missed in planning or implementation?
  • These are HIGHER PRIORITY than plan step completion

Phase 5: Build Progress Report

Step 1: Calculate Completion Percentage

Total Plan Steps: X
Completed Steps: Y
Partial Steps: Z
Not Started: W

Completion: (Y / X) * 100%
Weighted Completion: ((Y + 0.5*Z) / X) * 100%

Step 2: Generate Structured Report

Create report at .plans/[plan-name].progress.md:

# Plan Progress Report: [Plan Name]
**Date**: [timestamp]
**Plan File**: [path]
**Status**: [In Progress | Ready for Review | Completed]

---

## Summary
- **Overall Completion**: X%
- **Steps Complete**: Y / Total
- **Steps Partial**: Z
- **Steps Not Started**: W
- **Critical Issues**: N

---

## Progress by Plan Step

### ✅ Step 1: [Description]
**Status**: DONE
**Files**: [list]
**Notes**: [Any relevant notes]

### ⚠️ Step 2: [Description]
**Status**: PARTIAL (60% complete)
**Files**: [list]
**Completed**:
- [What's done]
**Remaining**:
- [What's not done]
**Issues**: [Any problems]

### ❌ Step 3: [Description]
**Status**: NOT DONE
**Blocking**: [What's blocking this]

---

## REMOVAL SPEC Status

### ✅ Completed Removals
- `old_function` from `file.ts` - Successfully removed
- `old-file.ts` - Successfully deleted

### ❌ Pending Removals (HIGH PRIORITY)
- `legacy_code` from `file.ts:lines 50-100` - **STILL EXISTS**
- `deprecated-helper.ts` - **FILE STILL EXISTS**

**Critical**: Old code must be removed before plan can be marked complete.

---

## Quality Assessment

### Passed
- ✅ TypeScript types used correctly
- ✅ CLAUDE.md naming conventions followed
- ✅ Architecture matches plan

### Issues Found
- ⚠️ `any` type used in `file.ts:42` (should use existing type)
- ⚠️ Missing error handling in step 5 implementation

---

## Files Changed

### Planned Changes (from plan)
- ✅ `path/to/file1.ts` - DONE
- ⚠️ `path/to/file2.ts` - PARTIAL
- ❌ `path/to/file3.ts` - NOT DONE

### Unplanned Changes (scope creep)
- `path/to/unexpected.ts` - Why: [reason]

---

## Remaining Work

### High Priority
1. **Remove old code** (REMOVAL SPEC items)
   - [ ] Remove `legacy_code` from `file.ts`
   - [ ] Delete `deprecated-helper.ts`

2. **Complete Step 3**
   - [ ] Implement [specific requirement]
   - [ ] Add proper types

### Medium Priority
3. **Fix quality issues**
   - [ ] Replace `any` in `file.ts:42`
   - [ ] Add error handling in step 5

### Low Priority
4. **Polish**
   - [ ] [Minor improvements]

---

## Validation Status

### Pre-Validation
- [ ] All plan steps completed
- [ ] All REMOVAL SPEC items removed
- [ ] TypeScript compiles
- [ ] Linting passes
- [ ] No `any` types added

**Ready for Final Validation**: NO (pending items remain)

---

## Next Steps

1. Complete REMOVAL SPEC items (remove old code)
2. Finish Step 3 implementation
3. Fix quality issues
4. Run validation checks
5. Update plan status when 100% complete

Phase 6: Validation Checks

Step 1: Run TypeScript Check

# Run type checking
npm run typecheck
# or
tsc --noEmit

Record results:

  • ✅ Passes: Good to go
  • ❌ Errors: List errors, add to remaining work

Step 2: Run Linting

# Run linter
npm run lint
# or
eslint .

Record results:

  • ✅ Passes: Good to go
  • ⚠️ Warnings: List warnings
  • ❌ Errors: List errors, add to remaining work

Step 3: Run Build (if applicable)

npm run build

Ensure build succeeds.

Phase 7: Generate Task List

Create actionable todo list for remaining work:

# Remaining Tasks for [Plan Name]

## Critical (Must Do)
- [ ] Remove `legacy_code` from `file.ts:50-100` (REMOVAL SPEC)
- [ ] Delete `deprecated-helper.ts` (REMOVAL SPEC)
- [ ] Complete Step 3: [description]

## Important (Should Do)
- [ ] Fix TypeScript error in `file.ts:42`
- [ ] Add error handling in step 5

## Polish (Nice to Have)
- [ ] [Minor improvement]

## Validation
- [ ] TypeScript passes (`npm run typecheck`)
- [ ] Linting passes (`npm run lint`)
- [ ] Build succeeds (`npm run build`)
- [ ] All REMOVAL SPEC items removed

**When all tasks complete**: Update plan file from `.todo.md` to `.done.md`

Phase 8: Report to User

Provide concise summary:

# Plan Check Complete: [Plan Name]

## Overall Status
**X% Complete** (Y of Z steps done)

## Completed ✅
- Step 1: [description]
- Step 2: [description]

## In Progress ⚠️
- Step 3: [description] (60% done)

## Not Started ❌
- Step 4: [description]

## Critical Issues 🚨
- **REMOVAL SPEC not complete**: Old code still exists
  - `legacy_code` in `file.ts` must be removed
  - `deprecated-helper.ts` must be deleted

## Quality Issues
- `any` type used in `file.ts:42`
- Missing error handling in step 5

## Validation
- ❌ TypeScript: 3 errors
- ✅ Linting: Passed
- Build: Not tested

## Next Steps
1. Remove old code (REMOVAL SPEC)
2. Complete Step 3
3. Fix quality issues
4. Run final validation

**Detailed Report**: `.plans/[plan-name].progress.md`
**Task List**: See remaining work section above

Critical Principles

  • NEVER SKIP FILES - Check every file in the comprehensive list
  • DO NOT EDIT FILES - This is read-only audit, not implementation
  • VERIFY REMOVAL SPEC - Critical that old code is actually removed
  • BE THOROUGH - Think critically about each file's implementation
  • USE MEMORY - Store context as you review files
  • RUN VALIDATION - Always run typecheck and lint
  • BE HONEST - Mark things as incomplete if they are
  • PROVIDE ACTIONS - Don't just identify issues, provide todo list
  • CHECK QUALITY - Implementation exists doesn't mean it's good
  • 100% STANDARD - Plan isn't done until 100% complete and validated

Completion Criteria

A plan can be marked as .done.md ONLY when:

  1. 100% of ORIGINAL ISSUE/TASK requirements implemented (not just plan steps!)
  2. All plan steps implemented (100% completion)
  3. All REMOVAL SPEC items removed (old code gone)
  4. TypeScript passes (tsc --noEmit succeeds)
  5. Linting passes (no errors)
  6. Build succeeds (if applicable)
  7. No any types added (strict typing maintained)
  8. CLAUDE.md compliance (all guidelines followed)
  9. Quality verified (implementations match plan specs)

CRITICAL: Criterion #1 is the MOST IMPORTANT. A plan that completes all its steps but doesn't fulfill the original issue requirements is STILL INCOMPLETE.

Anything less = plan stays as .todo.md

Supporting Tools

  • Grep: Search for old code to verify removal
  • Glob: Find all relevant files
  • Bash: Run git, typecheck, lint, build
  • Read: Examine file contents
  • TodoWrite: Track file review progress
  • Memory/Pinboard: Store context across files