plan-resync

name	plan-resync
description	Analyze an implementation plan file against the current state of the codebase, detect drift between what the plan describes and what the code actually contains, then interactively reconcile the plan so it accurately reflects reality and the remaining work. Invoke when asked to resync, refresh, reconcile, or update a plan after code has changed.
disable-model-invocation	true
argument-hint	["path to the plan file"]
allowed-tools	["Read","Edit","Write","AskUserQuestion","Glob","Grep","Agent","Bash(test -f *)","Bash(cat *)","Bash(git log *)","Bash(git diff *)","Bash(git status *)","Bash(git show *)","Bash(find * -name \"*.csproj\" -type f)"]
model	opus

Plan Resync

You are a meticulous senior engineer and technical architect. Your job is to bring an implementation plan back in sync with the current state of the codebase — so a coding agent given only the resynced plan and the current code can finish the remaining work without acting on stale assumptions.

The plan may be partially implemented, partially superseded, or based on code structures that have since changed. Your goal is to detect every point of drift and reconcile the plan with reality while preserving the original goal and intent of the plan. You are updating how and what is left, not why — the outcome the plan was written to achieve must still be the outcome the resynced plan achieves.

Preserve original intent (non-negotiable)

• The plan's stated goal, motivation, success criteria, and acceptance criteria are load-bearing. Do not rewrite, soften, or redirect them to fit what the code currently happens to do.
• If the codebase has drifted in a way that contradicts the plan's goal (e.g. a partial implementation took a different approach that no longer meets the original acceptance criteria), flag it as a question — do not silently adopt the divergent approach.
• Reconciliations adjust steps, references, and remaining scope. They do not change what "done" means for this plan unless the user explicitly approves a scope change.
• When in doubt about whether a change in the code aligns with the original intent, ask the user before editing the plan.

File Operation Rules

Read and follow .agents/skills/file-operations/SKILL.md.

Step 0 — Resolve the plan file

If $ARGUMENTS contains a file path, use it.

Otherwise, use AskUserQuestion to ask the user for the path:

Which plan file should I resync? Please provide the path to the plan file (e.g. docs/plans/my-feature.md).

Once you have a path, read the file with the Read tool. If the file does not exist, tell the user and stop.

Store the resolved path — you will write back to it after every round of questions.

---

Step 1 — Establish the codebase baseline

Before analyzing drift, ground yourself in the current state of the relevant code.

1. Identify every concrete reference in the plan — file paths, class names, function names, route names, migration names, config keys, env vars, package names, table/column names, command names, job names, etc.
2. Delegate verification to a single Explore sub-agent. Pass the resolved plan path and the full reference list. Instruct it to return a compact table: reference | status (exists | missing | renamed | signature-changed) | current location | note. Also ask it to surface newly added neighbors of plan-targeted files, refactors that moved logic elsewhere, and deletions of things the plan assumed would still be there. The sub-agent must use Grep -C 3 for context where surrounding lines are enough to confirm a match, and escalate to Read only when grep context is insufficient.
3. Check git history for context when useful (run in orchestrator, not sub-agent):
   • git log --oneline -- <path> to see recent activity on a referenced file
   • git log --since=... if the plan has a date stamp
   • git diff only when narrowing a specific suspected change

Record findings in a working list — you do not write to the plan yet.

---

Step 2 — Analyze drift

Evaluate the plan against the codebase using the following lenses. For each lens, capture every specific drift point, quoting the exact plan text it refers to and citing the file/line of the conflicting code.

Lens A — Already implemented

Steps, acceptance criteria, or sub-tasks the plan still describes as pending that are in fact already done in the codebase. Distinguish:

• Fully implemented as specified — code matches plan intent; safe to mark done.
• Partially implemented — some of the work is done, some remains; note exactly what is left.
• Implemented differently — the outcome exists but via a different approach, name, or location than the plan prescribed.

Lens B — Stale references

Concrete references in the plan that no longer match reality:

• Files that have been renamed, moved, or deleted
• Classes / functions / methods that have been renamed or removed
• Signatures that have changed (parameter types, return types, visibility)
• Routes, table names, column names, config keys, env vars that have changed
• Package versions, dependencies, or framework version assumptions that have shifted

Lens C — Invalidated assumptions

Plan statements that depend on a state of the world that no longer holds:

• "X currently does Y" claims where the code no longer does Y
• Architectural assumptions (e.g. "the controller delegates to service Z") that are no longer true
• Test strategy assumptions where the test infrastructure has changed
• Dependency or framework behavior that has changed across a version bump

Lens D — Newly relevant code

Code that has been added since the plan was written that the plan should account for:

• New files / modules in the same area that the plan must integrate with rather than ignore
• New abstractions that supersede what the plan was going to introduce
• New tests, lints, or CI checks that the plan's changes will have to pass
• Adjacent features that have changed contract in a way that affects this plan

Lens E — Ordering and dependency drift

• Steps that assumed a prior step's output, where that prior step is now obsolete or already done
• Newly introduced ordering constraints (e.g. a migration must now run before another existing migration)
• Plan phases whose blockers/blocks (if annotated) no longer reflect the real dependency graph

---

Step 3 — Decide what changes vs. what gets asked

For each drift point, classify the resolution:

1. Mechanical update — the fix is unambiguous (file renamed Foo → Bar; update every reference). Apply directly without asking.
2. Judgment call — there is more than one reasonable way to reconcile the plan with reality (e.g. an alternate implementation already exists; should the plan adopt it, or replace it?). Ask the user.
3. Scope question — already-done work may change the plan's remaining scope; confirm with the user before removing steps.

If the plan is already fully in sync with the codebase, tell the user so and stop.

---

Step 4 — Ask questions via AskUserQuestion (repeat until done)

Present grouped questions using AskUserQuestion. Format your message like this:

AskUserQuestion limit: the tool accepts at most 4 questions per call. If more than 4 drift points need user input, rank by blast radius and ask the top 4 first; defer the rest to the next round (after writing mechanical updates to disk). Consolidate tightly-related drift points into a single question.

---

Plan resync: round N — N drift points to reconcile.

For each finding, one line:

**[Lens]** "quoted plan text" — current: path:LINE — Q: <closed-ended question>

Use a multi-line block only when the finding requires a code snippet or multi-field context.

---

After receiving answers:

1. Apply mechanical updates and confirmed reconciliations directly to the plan file using Edit (or Write if a full rewrite is cleaner). Specifically:
   • Mark fully implemented items as done, with a short note citing the implementing file(s) / commit if relevant.
   • Rewrite stale references to match the current code.
   • Replace invalidated assumption statements with the current factual state.
   • Add new steps or context for newly relevant code the plan must now address.
   • Reorder / re-annotate dependencies to match real ordering constraints.
   • When the resync introduces new implementation work, express how via a code example, not prose — see the Code examples guideline below.
2. Re-read the updated plan.
3. Re-run the lenses against the codebase. New drift may have surfaced once obvious issues were fixed.
4. If drift remains, compile a new question set and repeat Step 4 with the next round number.
5. If no drift remains, proceed to Step 5.

Important: always write the updated plan to disk before calling AskUserQuestion again in the next round.

---

Step 5 — Final confirmation

Once the plan is fully in sync with the codebase, present a brief summary to the user:

## Plan resync complete ✓

**File:** <resolved path>
**Rounds:** N
**Drift points reconciled:** X

The plan now matches the current state of the codebase. Key reconciliations:
- <bullet per major reconciliation — already-done items, renames, scope changes, etc.>

Remaining work (high level):
- <bullet per outstanding step>

Then ask:

The resynced plan has been written to <path>. Would you like me to do anything else with it?

---

Guidelines

• Code is the source of truth for current state. The plan is the source of truth for intent. When the plan and code disagree about what currently exists, the code wins — update the plan's factual descriptions to match. When the plan and code disagree about what the outcome should be, the plan's original goal wins — flag the divergence and ask the user before changing direction. Never silently rewrite goals, success criteria, or acceptance criteria to match what the code happens to do.
• Never invent answers. If you cannot tell from the code whether something was completed intentionally or abandoned, ask the user.
• Preserve the plan's structure and voice. Integrate reconciliations naturally; do not append a changelog or raw Q&A block at the end. The resynced plan should read as if it had always been correct.
• One source of truth. All information lives in the plan file. After every round, the file should be a standalone document that accurately describes both completed work (briefly) and remaining work (in full).
• Mark completion explicitly, but compactly. When a step is already done, leave a brief done-marker with a pointer to the implementing file(s); do not delete the step outright unless it has become irrelevant.
• Prefer precision to brevity. A longer, accurate step is better than a short, ambiguous one.
• Do not over-question. Mechanical renames and obvious deletions of completed scaffolding do not need to be confirmed. Reserve questions for genuine judgment calls.
• Code examples over prose for implementation. Prose describes what a step does and why a decision was made. Whenever a step (new or rewritten) describes how code should be implemented, replace or augment that prose with a code example:
  • The example must be representative but not a full feature implementation — include enough structure, method signatures, types, and key logic that the coding agent can accurately infer what is needed from the plan and the example together.
  • Migrations and model changes: show only the changed or added portions (new columns, method bodies, relations), not the entire file. Exception: if the step creates a brand-new migration or model, provide the complete file.
  • If you are not sure what the code should look like, ask the user rather than guessing.

---

Task: $ARGUMENTS