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.
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
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
$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. 下の青いボタンを押して
check-plan.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
check-planフォルダができる - 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 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
計画の実装の確認
手順
計画に対する実装の進捗状況を包括的に監査し、完了した作業の品質を検証し、残りの項目について実行可能なタスクリストを生成します。
フェーズ 1: セットアップと発見
ステップ 1: 計画の特定
- ユーザーに確認する計画を尋ねる(またはコンテキストから特定する)
.plans/から計画ファイルを読み込む- すべての計画項目と要件を理解する
ステップ 2: Git コンテキストの取得 (該当する場合)
# 変更されたファイルを確認
git status
# 詳細な変更を確認
git diff
# このブランチのコミット履歴を確認
git log --oneline -20
これは、行われた変更の範囲を理解するのに役立ちます。
ステップ 3: 影響を受けるすべてのファイルの特定
包括的なリストを作成します。
- 計画に記載されているファイル
git statusに表示されるファイル- 影響を受ける可能性のあるファイル (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 の各項目について:
-
削除するコードの場合:
# 古いコードがまだ存在するかどうかを確認 grep -n "old_function_name" path/to/file.ts- ✅ 見つからない場合: コードは正常に削除されました
- ❌ 見つかった場合: コードはまだ存在します (NOT DONE)
-
削除するファイルの場合:
# ファイルがまだ存在するかどうかを確認 ls path/to/old-file.ts- ✅ 見つからない場合: ファイルは正常に削除されました
- ❌ 見つかった場合: ファイルはまだ存在します (NOT DONE)
-
廃止されたインポート/参照の場合:
# コードベース全体を検索 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 種類のギャップ:
- 計画のギャップ: issue からの要件で、計画に取り込まれていないもの
- 実装のギャップ: 計画ステップで、完全に実装されていないもの
どちらも不完全なカバレッジとしてカウントされます。
ステップ 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:
- Files mentioned in the plan
- Files shown in
git status - 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:
-
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)
-
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)
-
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:
- Plan gaps: Requirements from issue that weren't captured in plan
- 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:
- ✅ 100% of ORIGINAL ISSUE/TASK requirements implemented (not just plan steps!)
- ✅ All plan steps implemented (100% completion)
- ✅ All REMOVAL SPEC items removed (old code gone)
- ✅ TypeScript passes (
tsc --noEmitsucceeds) - ✅ Linting passes (no errors)
- ✅ Build succeeds (if applicable)
- ✅ No
anytypes added (strict typing maintained) - ✅ CLAUDE.md compliance (all guidelines followed)
- ✅ 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