@jeffober/thatch 0.1.25 → 0.1.26

package/README.md

@@ -70,7 +70,7 @@ Include thatch's instructions in your agent's system prompt manually; see
 - **Prediction engine**: a statistical model of user decision-making
   preferences. When a prompt matches learned contexts, predictions fire
   alongside the recall nudge.
-- **Skills**: 20 skills for memory workflows, structured multi-specialist
+- **Skills**: 21 skills for memory workflows, structured multi-specialist
   code review, change walkthroughs, and writing tasks (PR descriptions,
   tickets, PR splitting).
 

package/artifacts/skills/thatch-review-followup.md

@@ -0,0 +1,253 @@
+---
+name: thatch-review-followup
+description: Alternate entrypoint for follow-up review rounds. Verifies whether the author's responses and code changes since your last review round adequately addressed your prior findings, offers to reply on resolved items, then optionally re-runs the full structured review. Use after you have posted review comments and the author has responded or pushed changes.
+---
+
+You are a re-review verifier. Your job is to check whether the PR author's responses and code changes since your last review round adequately addressed your prior findings, before deciding whether another full review round is needed.
+
+This skill is an alternate entrypoint to the review pipeline. Use it instead of `thatch-code-review` when you have already reviewed a PR and the author has responded or pushed changes. It does not dispatch specialists or run a full review from scratch. It verifies resolution of your existing findings, offers to reply on the resolved ones, then optionally hands off to `thatch-code-review` for a fresh round.
+
+## When to use
+
+- You have already posted review comments on a PR (your prior review round).
+- The author has responded to your comments, pushed code changes, or both.
+- You want to verify your concerns were addressed before deciding whether another full review round is needed.
+
+## When NOT to use
+
+- First review of a PR. Use `thatch-code-review` instead.
+- You have no prior review comments on the PR. There is nothing to re-check.
+- You want a full from-scratch review regardless of prior comments. Use `thatch-code-review` — its existing follow-up detection will cross-reference your prior comments automatically.
+
+## Step 1: Identify your prior review round
+
+### Detect the connected PR/MR
+
+Run `git fetch origin` (NOT `git pull`). Inspect `git remote -v` to recognize the VCS host:
+- `github.com` → GitHub (`gh`)
+- `gitlab.*` → GitLab (`glab`)
+- `bitbucket.org` → Bitbucket Cloud
+- `dev.azure.com` → Azure DevOps
+
+Probe for an open PR/MR on the current branch:
+- **GitHub**: `gh pr view --head <branch> --json number,title,headRefOid,baseRefOid`
+- **GitLab**: `glab mr list --source-branch <branch>`
+
+If no PR/MR is found or no VCS CLI is available, you cannot re-check. Report this and stop.
+
+### Identify your VCS identity
+
+Get your own username so you can separate your comments from other reviewers':
+- **GitHub**: `gh api user --jq .login`
+- **GitLab**: `glab api user`
+
+### Fetch your prior review comments
+
+Fetch ALL review comments on the PR/MR, then filter to comments by your user:
+- **GitHub**: `gh api repos/{owner}/{repo}/pulls/{N}/reviews` (review summaries with `user.login`, `commit_id`, `state`, `submitted_at`) AND `gh api repos/{owner}/{repo}/pulls/{N}/comments` (inline comments with `path`, `line`, `original_line`, `commit_id`, `body`, `user.login`, `in_reply_to_id`). Filter both to `user.login` matching your identity.
+- **GitLab**: `glab api projects/:id/merge_requests/:iid/discussions`. Filter threads to those initiated by your user.
+
+Also fetch other reviewers' comments as context. They may have raised related issues, or the author may have addressed their comments in ways that affect yours. But you are only verifying resolution of YOUR findings.
+
+### Determine the last-round head SHA
+
+Find the HEAD commit at the time of your most recent review. This is the baseline for detecting what the author changed:
+- If you submitted formal reviews (state COMMENTED, CHANGES_REQUESTED, APPROVED), the most recent review's `commit_id` is the last-round SHA.
+- If you posted individual comments without a formal review, the most recent comment's `commit_id` is the last-round SHA.
+- If you used a pending review (e.g., via oink draft-review), its `commit_id` is the last-round SHA.
+
+Record this as `LAST_ROUND_SHA`. Record the current HEAD as `CURRENT_SHA` (from `gh pr view --json headRefOid` or equivalent).
+
+### Build the findings register
+
+For each of your prior review comments, record:
+- The comment body (quoted)
+- The original file:line and commit SHA
+- The semantic claim (one-sentence paraphrase of what you raised)
+- The severity you assigned (if discernible from the comment)
+- The original finding's category (if discernible)
+
+This is the list of findings you will verify.
+
+## Step 2: Determine what changed since the last round
+
+### Check for code changes
+
+Compare `LAST_ROUND_SHA` to `CURRENT_SHA`:
+- If they are the same, the author has not pushed code. Skip to "Read author responses" below.
+- If they differ, diff the two SHAs to isolate the author's changes: `git diff <LAST_ROUND_SHA> <CURRENT_SHA>`.
+
+**Force-push check**: run `git merge-base --is-ancestor <LAST_ROUND_SHA> <CURRENT_SHA>`. If it fails, the author rewrote history (force-pushed). Line numbers may have drifted. You will need to locate each finding's equivalent location in the new HEAD by matching surrounding context, not by line number.
+
+**Merge-from-main check**: if the author merged main into the branch between rounds, plain `git log <LAST_ROUND_SHA>..<CURRENT_SHA>` and `git diff <LAST_ROUND_SHA> <CURRENT_SHA>` both pull in every main commit, burying the author's actual response commits. To see only the author's commits, run `git log <LAST_ROUND_SHA>..<CURRENT_SHA> --not origin/main` after `git fetch origin`. Then read each remaining commit's diff with `git show <sha>`. Do not assume a large diff stat means the author rewrote the PR. Check for a merge commit first.
+
+### Read author responses
+
+Fetch reply threads on your comments:
+- **GitHub**: the comments API returns all comments including replies. Replies have `in_reply_to_id` pointing to the original comment's `id`. Match these to build reply threads.
+- **GitLab**: the discussions API already returns threads.
+
+For each of your findings, record:
+- Whether the author responded (yes/no)
+- The response body (quoted)
+- Whether the author resolved the thread in the UI (GitLab `resolved` flag, GitHub `isResolved` via GraphQL if accessible). The UI resolve flag is supplementary signal only. A thread can be marked resolved while the bug persists.
+
+### If nothing has happened
+
+If the head SHA is unchanged AND the author left no responses to your comments, report:
+
+> No changes since the last review round. The head SHA is still `<SHA>`. No responses to your review comments. There is nothing to re-check.
+
+Stop. Do not offer to re-run the review.
+
+## Step 3: Verify adequate resolution of each finding
+
+For each finding in your register, determine whether it was adequately addressed. The bar is deliberately high: the author must demonstrate resolution, not just respond.
+
+### What counts as adequately addressed
+
+A finding is `ADEQUATELY ADDRESSED` when one of these is true:
+
+1. **Code change fixed the issue.** The author changed the code in a way that resolves the root cause. Verify by reading the new code at the equivalent location in `CURRENT_SHA`. The fix must address the actual problem, not just paper over the symptom. Read the diff for the affected file(s) between `LAST_ROUND_SHA` and `CURRENT_SHA` to see what changed. Quote the new code that resolves the finding.
+
+2. **Author proved the finding is not a concern.** The author responded with a verifiable argument showing the finding is out of scope, the result of a misunderstanding, or structurally impossible. The argument must be checkable. You can verify the constraint, scope, or code path they cite. If the argument references a schema constraint, type, or guard, read it and quote it. If the argument says the code path is unreachable, trace the callers and verify. If the argument says the behavior is intentional, check git history and memories for design rationale.
+
+3. **Author filed a follow-up ticket AND explained the risk.** The author created a ticket to address the finding later AND provided a logical and plausible explanation of why there is little or no risk until that ticket is implemented. The ticket must be real and verifiable in the issue tracker. The risk explanation must be sound. Verify the ticket exists (e.g., `gh issue view <N>` or `gh issue list --search "<title>"`). Read the risk explanation and judge whether it holds.
+
+### What does NOT count as adequately addressed
+
+1. **Author responded but did not prove anything.** A response that says "I think this is fine" or "this is not a concern" without evidence is not adequate. The response must demonstrate why the finding is not a concern, not merely assert it.
+
+2. **Author added a comment noting the issue.** Adding a TODO or comment that describes the problem is not adequate unless paired with a follow-up ticket and a risk explanation. A comment that says "this is a known issue" without a ticket and risk assessment is an acknowledgment, not a resolution.
+
+3. **Author dismissed without engaging.** "Won't fix" without justification is not adequate. The author must explain why the finding does not need to be fixed.
+
+4. **Thread was resolved in the UI.** A thread marked "resolved" in the VCS UI is not adequate by itself. Anyone can click resolve. The code state or the author's response must demonstrate resolution. When the UI resolve flag disagrees with the code state, trust the code state.
+
+### Classification
+
+For each finding, classify as:
+
+- **`ADEQUATELY ADDRESSED`** — meets one of the three criteria above. State which criterion and provide evidence: the code change (quote the new code), the proof (quote the author's argument and the constraint, scope, or code path you verified), or the ticket + risk explanation (ticket reference and your assessment of the risk argument).
+- **`NOT ADDRESSED`** — the issue persists and the author's response (if any) does not meet the bar. State what the author did or did not do, and what is still needed.
+- **`PARTIALLY ADDRESSED`** — the author made progress but the resolution is incomplete. State what was done and what remains. This covers cases where the author fixed part of the issue but left related cases unhandled.
+- **`DISPUTED`** — the author disagreed with the finding and provided an argument, but the argument does not hold up under verification. Explain why the argument fails. Cite the code, constraint, or scope that refutes the author's claim.
+- **`NO RESPONSE`** — the author neither responded nor changed the relevant code. The finding stands as originally reported.
+
+### Verification method
+
+For each finding:
+1. Locate the finding's code at `LAST_ROUND_SHA` using the original comment's file:line and commit_id.
+2. Find the equivalent location in `CURRENT_SHA` by matching surrounding context. Line numbers may have drifted after a force-push or merge. Search for unique tokens from the original region.
+3. Read the code at the current location. Does the issue still exist?
+4. If the author changed the code, read the diff for the affected file(s) to understand what changed and whether it addresses the root cause.
+5. If the author responded, read the response. Verify any claims they make against the code, constraints, or documentation. Do not accept claims at face value. Check them.
+6. Classify per the criteria above.
+
+## Step 4: Present the verification report
+
+Produce a structured report for the user:
+
+### Re-check summary
+- PR/MR number, title
+- Last-reviewed SHA, current SHA
+- Whether the author pushed changes, responded to comments, or both
+- Force-push or merge-from-main detected (if applicable)
+
+### Finding verification
+
+Group findings by status. For each finding:
+
+#### ADEQUATELY ADDRESSED
+1. **Finding** — one-line paraphrase of the original concern
+2. **How addressed** — code change / proof / follow-up ticket + risk explanation
+3. **Evidence** — what you read to verify (code quote, constraint quote, ticket reference + risk assessment)
+4. **Original location** — file:line @ last-round SHA and file:line @ current SHA
+
+#### NOT ADDRESSED
+1. **Finding** — one-line paraphrase
+2. **Current state** — what the author did or did not do
+3. **What's still needed** — what would resolve this finding
+
+#### PARTIALLY ADDRESSED
+1. **Finding** — one-line paraphrase
+2. **What was done** — the progress made
+3. **What remains** — what is still needed
+
+#### DISPUTED
+1. **Finding** — one-line paraphrase
+2. **Author's argument** — what the author claimed
+3. **Why it fails** — your verified refutation
+
+#### NO RESPONSE
+1. **Finding** — one-line paraphrase
+2. **Status** — no response, no code change. Finding stands.
+
+### Round assessment
+- Count of findings in each status
+- Whether the unaddressed, partially addressed, disputed, or no-response findings warrant further action
+- Whether the author's changes introduced new code that should be reviewed
+
+## Step 5: Offer to reply on adequately addressed findings
+
+For each finding classified as `ADEQUATELY ADDRESSED`, use your judgement to decide whether a reply is appropriate and what form it should take.
+
+### Reply decision guide
+
+- **Code change that solved it well**: "Oh, nice. I didn't think of solving it that way." or a thumbs-up reaction. Do not over-explain. If the fix was obvious, a reaction alone is enough.
+- **Follow-up ticket agreed**: "Agreed, that can be dealt with in a follow up." Reference the ticket if the author did not.
+- **Proof that it's not a concern**: "Good point, that makes sense." or a brief acknowledgment. Do not restate their argument back at them.
+- **Trivial fix** (typo, naming, one-line change): an emoji reaction is enough. No need to write a comment.
+- **Clever or unexpected solution**: acknowledge it specifically. "Nice, using the existing validator there is cleaner than what I suggested."
+
+### When NOT to reply
+
+- If the author's response was thorough and there is nothing to add, a reaction is enough. Silence is also fine.
+- If the fix was trivial and obvious, do not write a comment. A reaction or silence.
+- If most findings are trivial, consider one summary comment instead of per-finding replies.
+
+### When to reply
+
+- When the author filed a ticket you want to acknowledge.
+- When the author's solution was clever or unexpected and worth calling out.
+- When the author proved a finding was not a concern and you want to accept their reasoning on the record.
+- When a brief comment helps close the thread cleanly for future readers.
+
+### Posting replies
+
+Propose the replies (or reactions) to the user before posting. After the user approves:
+- Post comments via the VCS CLI (`gh pr comment` or equivalent) or the oink draft-review tool when available.
+- Post reactions via the VCS API (GitHub: `gh api repos/{owner}/{repo}/issues/comments/{id}/reactions` with `content` field).
+- When responding on behalf of the user, prefix the response with `Landru is thinking on behalf of Jeff: ` (in bold, using the correct markup for the platform).
+- Build the draft review once at the end after all replies have been decided, not incrementally after each finding.
+
+## Step 6: Handle unaddressed findings
+
+For findings classified as `NOT ADDRESSED`, `PARTIALLY ADDRESSED`, `DISPUTED`, or `NO RESPONSE`, present them to the user one at a time. The user decides how to handle each:
+
+- **Push back**: the user wants to reiterate the finding and ask the author to address it. Offer to draft a follow-up comment.
+- **Accept the author's response**: the user disagrees with your verification and accepts the author's response. Reclassify as `ADEQUATELY ADDRESSED` and return to Step 5 to handle the reply.
+- **Drop the finding**: the user decides the finding is no longer worth pursuing. Note this and move on.
+- **Escalate**: the user wants to discuss the finding with the author in a different forum (Slack, ticket, etc.). Note this and move on.
+
+After the user responds to each unaddressed finding, check whether a thatch prediction should be updated based on the user's decision (review threshold, severity, evidence standards, what is worth posting).
+
+## Step 7: Offer to re-run the structured review
+
+After all findings have been dealt with (adequately addressed and replied to, or unaddressed and the user decided how to handle them), offer to re-run the full structured review.
+
+### When to offer
+
+- **All findings adequately addressed AND author pushed code changes**: offer to run `thatch-code-review` on the current HEAD. The author's fixes may have introduced new issues. The full review will catch them. The coordinator's existing follow-up detection will cross-reference your prior comments automatically.
+- **Some findings unaddressed but user wants to proceed**: offer to run the full review alongside the unaddressed findings. The new review may find additional context.
+- **Author only responded (no code changes) and all findings adequately addressed**: do NOT offer a full re-run. The code has not changed, so a new review would produce the same findings as the last round. Confirm that the user is satisfied with the responses.
+- **No findings were adequately addressed**: do NOT offer a full re-run. The author has not engaged with the review. Suggest the user respond to the unaddressed findings instead.
+- **Author pushed changes but only addressed some findings**: offer the full re-run only after the user has decided how to handle the unaddressed ones. The user may want to push back before another review round makes sense.
+
+### How to offer
+
+Present the offer as a choice:
+1. **Re-run the full structured review**: load `thatch-code-review` on the current HEAD. It will dispatch all seven specialists on the merge-base..HEAD range. The existing follow-up detection will cross-reference your prior comments. On Claude Code or Cursor (no sub-agent support), run each specialist skill in sequence, then run `thatch-review-synthesizer` to aggregate.
+2. **End the re-review here**: the user confirmed their concerns were addressed (or decided how to handle the unaddressed ones) and does not want another full round.
+
+The offer is just an offer. The user may decline. They may have only wanted to confirm their concerns were addressed.

package/docs/dev/README.md

@@ -64,7 +64,7 @@ bin/thatch             → CLI: stores|list|show|forget|search|mcp|reminder|hygi
 | `extract-queue.ts` | File-backed per-session JSONL queue (caps 20, oldest dropped). Shared by the Claude Code and Cursor hook paths, which fire one-shot per event with no cross-call state. This is the MCP-side equivalent of `extraction.ts`. |
 | `sideband.ts` | Unix domain socket server + client. The MCP server (long-lived, warm model) runs `SidebandServer` so one-shot hook processes can ask it to embed a prompt and search for matches without loading the model themselves. Handles two methods: `match` (recall nudge) and `predictions` (prediction auto-fire). Socket path is a hash of the DB path — both processes compute it independently. |
 | `prompts.ts` | Text constants: opencode system prompt, compaction context, session-start reminder, prompt-aware recall nudge (`recallNudge` / `claudeRecallNudge`), Claude Code CLAUDE.md instructions, Cursor AGENTS.md instructions, Claude Code hook text. |
-| `skills.ts` | `SKILL.md` content for all thatch skills, plus the installer. Skills are split into `SHARED_SKILLS` (19 skills: fact-extractor, dedup-classifier, project-primer, 7 review specialists, review synthesizer, review context, workflow research, change walkthrough, code walkthrough, session reflection, pr-description, ticket-description, split-overlarge-pr — work on both opencode and Claude Code) and `OPENCODE_ONLY_SKILLS` (1 skill: code-review coordinator — requires sub-agent support, not installed for Claude Code). `installSkills(dir, skills)` defaults to `SHARED_SKILLS`; the opencode plugin passes `[...SHARED_SKILLS, ...OPENCODE_ONLY_SKILLS]`. |
+| `skills.ts` | `SKILL.md` content for all thatch skills, plus the installer. Skills are split into `SHARED_SKILLS` (20 skills: fact-extractor, dedup-classifier, project-primer, 7 review specialists, review synthesizer, review context, workflow research, review followup, change walkthrough, code walkthrough, session reflection, pr-description, ticket-description, split-overlarge-pr — work on both opencode and Claude Code) and `OPENCODE_ONLY_SKILLS` (1 skill: code-review coordinator — requires sub-agent support, not installed for Claude Code). `installSkills(dir, skills)` defaults to `SHARED_SKILLS`; the opencode plugin passes `[...SHARED_SKILLS, ...OPENCODE_ONLY_SKILLS]`. |
 
 ## Plugin hooks
 

package/docs/dev/skills.md

@@ -21,9 +21,9 @@ description: Extract durable project facts ... Use when ...
 - `description` drives when the agent loads the skill (both opencode and
   Cursor auto-discover skills and use the description for relevance).
 
-## The 20 skills
+## The 21 skills
 
-**Shared (19)** — installed everywhere; no sub-agents required:
+**Shared (20)** — installed everywhere; no sub-agents required:
 
 | Skill | Role |
 |-------|------|
@@ -40,6 +40,7 @@ description: Extract durable project facts ... Use when ...
 | `thatch-review-synthesizer` | Verify specialist findings against code, dedupe, classify, calibrate severity. Starts the final report with a workflow-change preface, then cross-references findings against prior review comments when a follow-up round register is provided. |
 | `thatch-review-context` | Gather project/feature context (PR descriptions, git archaeology, ticket references, memory) before fan-out. Prevents false positives about intentionally deferred work. Also fetches prior review comments on a connected PR/MR for follow-up-round detection and builds a register with preliminary addressed-check status per comment. |
 | `thatch-workflow-research` | Research code workflows/features affected by a change or planned change. Reads code flows, comments, git history, memories, docs. Produces a guide to the code for reviewers or planners. |
+| `thatch-review-followup` | Alternate entrypoint for follow-up review rounds. Verifies whether the author's responses and code changes since your last review round adequately addressed your prior findings, offers to reply on resolved items, then optionally re-runs the full structured review. |
 | `thatch-change-walkthrough` | Explain a change to the user as a teaching walkthrough: resolve the delta, research each affected workflow at the merge-base, teach current behavior, then overlay the modifications with file:line citations and analogies. |
 | `thatch-code-walkthrough` | Explain a feature, module, or workflow to the user as a teaching walkthrough: identify the code area (optionally from a branch or PR), research how it works, teach it with file:line citations and analogies, list the key files. |
 | `thatch-session-reflection` | End-of-session memory recording (project, user, tools, self). |
@@ -85,7 +86,7 @@ The synthesizer reuses the same verification rigor but has its own structure
 ## The two arrays
 
 ```ts
-const SHARED_SKILLS: SkillDef[] = [ /* 19 skills above */ ];
+const SHARED_SKILLS: SkillDef[] = [ /* 20 skills above */ ];
 const OPENCODE_ONLY_SKILLS: SkillDef[] = [ /* code-review coordinator */ ];
 ```
 
@@ -119,6 +120,10 @@ and `--cursor` pass only the shared set.
 - **Full review on opencode**: load `thatch-code-review` — it gathers project context, researches affected workflows, dispatches all 7 specialists in parallel (with both the context brief and workflow guide injected into each briefing), then synthesizes a report that starts with the workflow changes before findings.
 - **Full review on Claude Code/Cursor**: run each specialist in sequence, then
   run `thatch-review-synthesizer` to verify and aggregate.
+- **Follow-up round (re-review)**: load `thatch-review-followup` when the author
+  has responded or pushed changes after your initial review. It verifies whether
+  your prior findings were adequately addressed, offers to reply on resolved
+  items, then optionally hands off to `thatch-code-review` for a fresh round.
 
 The coordinator is the only skill that can't be used without sub-agents; that's
 why it lives in `OPENCODE_ONLY_SKILLS`.

package/docs/qa/use-cases/README.md

@@ -22,7 +22,7 @@ file/IPC/CLI contracts ready to graduate into `bun:test` integration tests.
 | [UC-011](UC-011-write-time-similarity-warning.md) | Write-time warning never blocks; merge or mark-distinct reconciliation |
 | [UC-012](UC-012-model-migration.md) | `THATCH_MODEL` change: old memories skipped (not corrupted) until re-saved |
 | [UC-013](UC-013-compaction-context.md) | Compaction context re-familiarization (opencode-only) |
-| [UC-014](UC-014-skill-install-drift.md) | Skill install: 19 shared vs 20 opencode; drift overwritten on re-setup |
+| [UC-014](UC-014-skill-install-drift.md) | Skill install: 20 shared vs 21 opencode; drift overwritten on re-setup |
 | [UC-015](UC-015-env-override-matrix.md) | `THATCH_DB_PATH`, `XDG_CONFIG_HOME`, `CLAUDE_CONFIG_DIR`, `THATCH_QUEUE_DIR`, `THATCH_RECALL_THRESHOLD`, `THATCH_MODEL` |
 | [UC-016](UC-016-concurrent-session-isolation.md) | Per-session extraction isolation (in-memory + file queue); shared stateless sideband |
 | [UC-017](UC-017-buffer-tool-vs-buffer-batch.md) | `buffer-batch` (Claude, `tool_calls[]`+`session_id`) vs `buffer-tool` (Cursor, single+`conversation_id`) |

package/docs/qa/use-cases/UC-005-setup-install.md

@@ -17,12 +17,12 @@
   appends a thatch block to `CLAUDE.md` bracketed by start/end markers (replaced, not
   duplicated, on re-run), writes `.claude/settings.json` hooks (`SessionStart` -> `thatch reminder`,
   `PostToolBatch` -> `thatch buffer-batch`, `UserPromptSubmit` -> `thatch flush-tools`), and installs
-  **19 shared skills** (no code-review coordinator) to `$CLAUDE_CONFIG_DIR/skills/` — user-scoped
+  **20 shared skills** (no code-review coordinator) to `$CLAUDE_CONFIG_DIR/skills/` — user-scoped
   even in project-local mode.
 - `--cursor` project-local writes `.cursor/mcp.json`, appends to `AGENTS.md`, writes
   `.cursor/hooks.json` in the **flat format** (`{version:1, hooks:{...}}`): `sessionStart` ->
   `thatch reminder --json`, `postToolUse` -> `thatch buffer-tool`, `beforeSubmitPrompt` ->
-  `thatch flush-tools --json`; and installs 19 shared skills to `~/.cursor/skills/`.
+  `thatch flush-tools --json`; and installs 20 shared skills to `~/.cursor/skills/`.
 - Re-run is idempotent: instructions are not duplicated, thatch hooks are replaced (not appended),
   and non-thatch hooks are preserved. A legacy `thatch echo` hook is replaced with `flush-tools`.
 - `--global` (Claude) writes `~/.claude/CLAUDE.md` + `~/.claude/settings.json` but **no project

package/docs/qa/use-cases/UC-014-skill-install-drift.md

@@ -13,16 +13,16 @@
 5. Check whether the `thatch-code-review` coordinator skill is present.
 
 **Expected**
-- Claude Code and Cursor install exactly **19 shared skills** to the skills
+- Claude Code and Cursor install exactly **20 shared skills** to the skills
   dir — the coordinator (`thatch-code-review`) is **absent** (it needs
   sub-agents, which those hosts lack).
-- opencode installs **20** — the 19 shared plus the coordinator.
+- opencode installs **21** — the 20 shared plus the coordinator.
 - The locally edited `SKILL.md` is **overwritten** with the canonical content
   on the next `setup`/init (drift detection: a file is only rewritten when its
   content differs from the definition). Unrelated skill files are untouched.
 - Skills never land in the worktree — always under the user-scoped config dir
   (`~/.claude/skills`, `~/.cursor/skills`, `$XDG_CONFIG_HOME/opencode/skills`).
 
-_Automatable: yes — file presence, count (19 vs 20), content-diff-overwrite, and
+_Automatable: yes — file presence, count (20 vs 21), content-diff-overwrite, and
 coordinator host-gating are all file assertions (`setup.test.ts` already covers
 the unit contract)._

package/docs/user/README.md

@@ -200,6 +200,7 @@ Seven specialist review lenses, each a self-contained static-analysis pass:
 | `thatch-review-synthesizer` | Verifies and synthesizes findings from multiple specialists into a report that starts with workflow changes, then highlights, then deduplicated severity-grouped findings. |
 | `thatch-review-context` | Gathers project context (PR descriptions, git archaeology, ticket references, memory) before a review. Prevents false positives about intentionally deferred work. |
 | `thatch-workflow-research` | Researches code workflows and features affected by a change or planned change. Reads code flows, comments, git history, and produces a guide for reviewers or planners. |
+| `thatch-review-followup` | Alternate entrypoint for follow-up review rounds. Verifies whether the author's responses and code changes since your last review adequately addressed your prior findings, offers to reply on resolved items, then optionally re-runs the full structured review. |
 | `thatch-change-walkthrough` | Explains a change to the user as a teaching walkthrough: researches each affected workflow at the merge-base, teaches current behavior, then overlays the modifications with file:line citations. |
 | `thatch-code-walkthrough` | Explains a feature, module, or workflow to the user as a teaching walkthrough with file:line citations. Also used to draft high-level docs for new or undocumented features. |
 
@@ -225,6 +226,7 @@ Seven specialist review lenses, each a self-contained static-analysis pass:
 | Review specialists (7) | Yes | Yes | Yes |
 | Review synthesizer | Yes | Yes | Yes |
 | Review context + workflow research | Yes | Yes | Yes |
+| Review followup | Yes | Yes | Yes |
 | Walkthrough skills (2) | Yes | Yes | Yes |
 | Writing skills (3) | Yes | Yes | Yes |
 | Code review coordinator | Yes | No (requires sub-agents) | No (requires sub-agents) |
@@ -258,6 +260,18 @@ specialist in sequence, then synthesize:
 4. Load thatch-review-synthesizer, verify and aggregate all findings.
 ```
 
+For a **follow-up round** (the author responded or pushed changes after your
+review), load the re-check skill:
+
+```text
+Load thatch-review-followup and check whether my prior review comments
+on this PR were adequately addressed.
+```
+
+It verifies whether each finding was resolved (by code change, proof, or
+follow-up ticket with a risk explanation), offers to reply on the resolved
+ones, then optionally hands off to the coordinator for a fresh full review.
+
 These files are plugin-owned: local edits are overwritten the next time the
 plugin initializes (this is how skill improvements ship with new versions).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jeffober/thatch",
-  "version": "0.1.25",
+  "version": "0.1.26",
   "description": "Persistent memory for AI coding agents — local embeddings, SQLite stores, zero config. Works with OpenCode (as a plugin), Claude Code (as an MCP server), and Cursor (as an MCP server).",
   "type": "module",
   "main": "src/index.ts",

package/src/prompts.ts

@@ -38,6 +38,7 @@ Thatch ships skills for code review, project investigation, and memory
 workflows. The host auto-discovers them, but reach for them proactively:
 
 - \`thatch-code-review\` — full multi-agent code review (dispatches 7 specialists + synthesizer). Requires sub-agent support.
+- \`thatch-review-followup\` — alternate entrypoint for follow-up review rounds. Verifies whether the author's responses and code changes since your last review adequately addressed prior findings, offers to reply on resolved items, then optionally re-runs the full structured review.
 - \`thatch-workflow-research\` — research code workflows affected by a change or planned change, before reviewing or planning.
 - \`thatch-change-walkthrough\` — produces a teaching walkthrough of a diff with a specific format (SYNOPSIS + per-workflow orient/mechanism/numbered-stages + change overlay mirroring the same numbers) and calibrated prose rules. Load the skill for the format and prose rules, not just for the research method.
 - \`thatch-code-walkthrough\` — produces a teaching walkthrough for a feature/workflow as it stands today with a specific format (SYNOPSIS + per-workflow orient/mechanism/numbered-stages + Key files) and calibrated prose rules. Also use proactively to draft high-level docs for new or undocumented features (suitable for pkg/README.md or docs/features/<name>.md). Load the skill for the format and prose rules, not just for the research method.
@@ -243,6 +244,7 @@ workflows. The host auto-discovers them, but reach for them proactively:
 - \`thatch-change-walkthrough\` — produces a teaching walkthrough of a diff with a specific format (SYNOPSIS + per-workflow orient/mechanism/numbered-stages + change overlay mirroring the same numbers) and calibrated prose rules. Load the skill for the format and prose rules, not just for the research method.
 - \`thatch-code-walkthrough\` — produces a teaching walkthrough for a feature/workflow as it stands today with a specific format (SYNOPSIS + per-workflow orient/mechanism/numbered-stages + Key files) and calibrated prose rules. Also use proactively to draft high-level docs for new or undocumented features (suitable for pkg/README.md or docs/features/<name>.md). Load the skill for the format and prose rules, not just for the research method.
 - \`thatch-review-context\` — gather project context (PRs, tickets, TODOs, deferred work) before a review.
+- \`thatch-review-followup\` — alternate entrypoint for follow-up review rounds. Verifies whether the author's responses and code changes since your last review adequately addressed prior findings, offers to reply on resolved items, then optionally re-runs the full structured review.
 - \`thatch-review-pedantic\` / \`-acceptance\` / \`-state-flow\` / \`-no-slop\` / \`-breadcrumbs\` / \`-mark-and-sweep\` / \`-highlights\` — seven specialist review lenses. Run individually, then \`thatch-review-synthesizer\` to verify and aggregate.
 - \`thatch-project-primer\` — investigate a new project and write foundational memories.
 - \`thatch-session-reflection\` — record what you learned at end of session.
@@ -511,6 +513,7 @@ workflows. The host auto-discovers them, but reach for them proactively:
 - \`thatch-change-walkthrough\` — produces a teaching walkthrough of a diff with a specific format (SYNOPSIS + per-workflow orient/mechanism/numbered-stages + change overlay mirroring the same numbers) and calibrated prose rules. Load the skill for the format and prose rules, not just for the research method.
 - \`thatch-code-walkthrough\` — produces a teaching walkthrough for a feature/workflow as it stands today with a specific format (SYNOPSIS + per-workflow orient/mechanism/numbered-stages + Key files) and calibrated prose rules. Also use proactively to draft high-level docs for new or undocumented features (suitable for pkg/README.md or docs/features/<name>.md). Load the skill for the format and prose rules, not just for the research method.
 - \`thatch-review-context\` — gather project context (PRs, tickets, TODOs, deferred work) before a review.
+- \`thatch-review-followup\` — alternate entrypoint for follow-up review rounds. Verifies whether the author's responses and code changes since your last review adequately addressed prior findings, offers to reply on resolved items, then optionally re-runs the full structured review.
 - \`thatch-review-pedantic\` / \`-acceptance\` / \`-state-flow\` / \`-no-slop\` / \`-breadcrumbs\` / \`-mark-and-sweep\` / \`-highlights\` — seven specialist review lenses. Run individually, then \`thatch-review-synthesizer\` to verify and aggregate.
 - \`thatch-project-primer\` — investigate a new project and write foundational memories.
 - \`thatch-session-reflection\` — record what you learned at end of session.

package/src/skills.ts

@@ -43,6 +43,7 @@ function loadSharedSkills(): SkillDef[] {
     "thatch-review-synthesizer",
     "thatch-review-context",
     "thatch-workflow-research",
+    "thatch-review-followup",
     "thatch-change-walkthrough",
     "thatch-code-walkthrough",
     "thatch-session-reflection",