adamlinscott Reground
The current session has drifted: the recent work rests on assumptions the codebase has not been shown to support, invents systems that may not exist, or builds past what the task needs. This skill is a hard reset to ground truth. It does not summarize or compact — it discards the speculative thread and rebuilds a small, evidence-backed footing for the next step. Run the protocol in order. Do not skip ahead to step 5.
1. Halt
Stop immediately. Make no further Edit, Write, or other tool calls that advance the
work until the report in step 5 is produced and the user approves a next step.
Before reporting, make sure the working tree is in a coherent state — never leave a file half-written or a multi-file change partly applied. If a change is mid-flight, the only edits permitted here are the minimal ones that restore a self-consistent, non-broken state, or a clean revert of it; make no new feature progress either way. The aim is solid footing to assess from, not a frozen half-edit.
2. Name the drift
State plainly, in one or two sentences, the specific unverified assumption(s) the recent work depended on — the equivalent of "the last answer assumed X, but the repo shows no evidence for X." Be concrete: name the assumed file, function, endpoint, schema, or behavior. If you cannot name what was assumed, that itself is the finding — say so.
3. Set the anchor
Decide the focus file set — the minimum slice of the repo the next step actually depends on:
- If the user passed paths or class/function/object names (as arguments or in their message), use exactly those.
- Otherwise, self-derive them from the stated task: list the files/paths you intend to read and why each one matters, then read them. Keep the set small and task-scoped; do not sweep the whole repo. If the right anchor is genuinely unclear, ask the user for the paths rather than guessing.
4. Read the anchor, nothing else
Read those files now. Treat only what is on disk as true. Do not fill gaps with memory, convention, or inference about code you have not opened. If something the task seems to need is absent, that is an "unknown," not a thing to assume into existence.
5. Report — use this exact structure
- Proven — what the existing code establishes, each claim with a
file:linecitation. - Unknown — what the task needs but the read code does not settle; open questions.
- Smallest next change — the single smallest change that follows from the evidence above. Not a plan for the whole feature — the next concrete step only.
- Basis — the exact files, functions, and endpoints this is grounded in.
From this point, the report is the working ground truth. Disregard any earlier assumption not restated in it.
Assess honestly — do not defend the work already done. Treat what was just written as
suspect by default, held to the same evidentiary standard as everything else. "The
implementation is actually fine / in line with the task" is a claim that needs file:line
proof like any other — it is never the default conclusion, and it must not be reached
by reframing the user's concern as a mere misunderstanding of some underlying feature. If
the recent change cannot be grounded in the read code, it is part of the drift, not vindicated.
Hard constraints
- Do not invent missing systems. If a service, table, or module is not in the read code, it does not exist for the purposes of this step.
- Do not add fallbacks or defensive branches for conditions the evidence does not show.
- No placeholders, stubs, or mock data unless the user explicitly approves them.
- Wait for approval before resuming implementation. The output of this skill is the report, not a resumed edit.