Agent skill
plan:findings:create
Retroactively create findings for a plan by reviewing completed phases. Use when findings weren't recorded during implementation and need to be extracted after the fact.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/data/plan-findings-create
SKILL.md
Plan Findings Create Skill
Retroactively extract findings from completed plan phases when findings weren't recorded during implementation.
Process
-
Identify the target plan:
- If the user provides a plan number (e.g.,
/plan:findings:create 0018), use that plan directly - If no number is provided, scan for in-progress plans:
- Look for
plans/*/task-list.mdfiles (excludeplans/archive/) - Check which plans have completed tasks but no
findings/directory (or sparse findings) - If one plan qualifies, use it
- If multiple plans qualify, list them and ask the user to choose
- If no plans qualify, check
plans/archive/and offer those
- Look for
- If the user provides a plan number (e.g.,
-
Gather implementation context:
Read the plan's state to understand what was done:
- Read
implementation-plan.mdfor the intended approach - Read
task-list.mdto identify completed phases and tasks - Read
.plan-state.jsonfor:commitsarray — commit SHAs from completed phaseslast_session_notes— notes about what happenedcurrent_task— where work stopped
- Read task files in
tasks/for what was planned vs. what may have changed
- Read
-
Review commits for each completed phase:
For each commit SHA in
.plan-state.json:- Run
git log --format='%H %s' <sha>to get the commit message - Run
git diff <sha>~1..<sha> --statto see what files changed - Run
git diff <sha>~1..<sha>to review the actual changes - Compare changes against what the task files specified
If no commits are recorded but tasks are checked off:
- Use
git log --onelineto find likely commits by message pattern (feat(plan-NNNN)) - Review those commits instead
- Run
-
Identify findings by comparing plan vs. reality:
For each completed task/phase, look for:
- Diversions: Code that differs from what the task file specified. Why did the approach change?
- Discoveries: Unexpected behavior encountered. New understanding of how the code works.
- Plan errors: Tasks that assumed something incorrect. Missing steps that had to be improvised.
- TODOs: Comments with
TODO,FIXME,HACK, orWORKAROUNDin the committed code. - Cleanup items: Code that works but could be improved. Temporary scaffolding left in place.
- Notes: Important context that future work should know about.
Also search the committed code:
- Grep for
TODO,FIXME,HACK,WORKAROUND,XXXin changed files - Look for commented-out code or temporary implementations
- Check test files for
#[ignore]or@skipmarkers
-
Present findings to the user:
**Plan:** `plans/NNNN-feature-name/` **Phases reviewed:** N completed phases (M commits) **Findings identified:** K total | # | Finding | Type | Phase/Task | Source | |---|---------|------|------------|--------| | 1 | [Short title] | diversion | Phase 2 / Task 2.1 | Commit abc1234 | | 2 | [Short title] | todo | Phase 3 / Task 3.2 | TODO in src/foo.rs:42 | | 3 | [Short title] | discovery | Phase 1 / Task 1.3 | Commit def5678 | Should I write these as finding files in `plans/NNNN-name/findings/`? You can adjust, add, or remove findings before I write them. -
Wait for user approval before writing findings.
-
Write finding files:
-
Create
plans/NNNN-name/findings/directory if it doesn't exist -
Write each finding as an individual markdown file
-
Use descriptive filenames:
findings/todo-cleanup-unused-helpers.md -
Follow the standard finding format:
markdown# Finding: Short Title **Type:** discovery | diversion | plan-error | note | todo | cleanup **Task:** 2.1 **Date:** YYYY-MM-DD **Source:** Commit abc1234 | TODO in src/foo.rs:42 | Observed during review ## Details [What was found/changed/wrong] ## Impact [How this affects the current plan or future work] ## Action Items - [ ] Concrete next step (if any)
-
-
Report results:
**Findings written:** N files in `plans/NNNN-name/findings/` - findings/diversion-changed-routing-approach.md - findings/todo-cleanup-unused-helpers.md - findings/discovery-diamond-attachment-behavior.md Run `/plan:findings:resume NNNN` to triage these into issues and research.
When to Use This Skill
- A plan has completed phases but no
findings/directory - You finished implementing and forgot to record findings along the way
- You want to do a retrospective review of what changed vs. what was planned
- Before archiving a plan, to capture learnings
Example Output
Plan: plans/0018-lr-rl-remaining-fixes/
Phases reviewed: 3 completed phases (3 commits)
Findings identified: 4 total
| # | Finding | Type | Phase/Task | Source |
|---|---|---|---|---|
| 1 | Router needed separate LR/RL backward path | diversion | Phase 2 / Task 2.1 | Commit 9b85567 |
| 2 | render_edge has TODO for multi-segment labels |
todo | Phase 3 / Task 3.2 | TODO in src/render/edge.rs:187 |
| 3 | Plan assumed waypoints always ordered top-to-bottom | plan-error | Phase 2 / Task 2.3 | Commit 7b7e7f0 |
| 4 | Diamond attachment points need rank-aware sorting | discovery | Phase 1 / Task 1.2 | Commit 0d66d6c |
Should I write these as finding files in plans/0018-lr-rl-remaining-fixes/findings/?
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?