Review followup

Review Follow-Up

Process follow-up .md files left by autonomous commands (/ops:batch-execute, /ops:get-to-work).

1. Find the follow-up file

If $ARGUMENTS contains a file path, use that. Otherwise, search for follow-up files:

1. Check .plans/ and plans/ for files matching *follow*up* or *followup*.
2. If multiple found, list them and ask the user which to review.
3. If none found, tell the user and stop.

Read the file. Also read the branch's git log (git log main..HEAD --oneline) to understand what was done.

2. Present the summary

Give a brief overview:

• How many items total across all sections
• Which sections have items (skip empty ones)
• The branch name and number of commits

3. Walk through each section

Context before questions. For every item you present, show the relevant context first — the actual code snippet, diff, file path, commit message, or whatever the user needs to understand the situation — before presenting options or asking anything. The follow-up file often contains only a brief summary; that's not enough. Read the relevant files, run git show on the relevant commit, or do whatever it takes so the user sees the concrete reality, not just an abstract description. Never ask "what do you want to do about X?" without first showing X.

Process sections in this order (skip empty ones):

Implementation Issues

These block quality. Present each issue with options:

• Fix now — address the issue immediately
• Create backlog item — add to .plans/ or backlog/ for later
• Dismiss — not worth fixing

Controversial Decisions

The agent made a judgment call. For each, show the decision and reasoning, then offer:

• Keep as-is — the agent's choice is fine
• Revert — undo this specific change (identify the commit)
• Modify — adjust the approach (ask what they want)

User Input Needed

Questions the agent couldn't resolve. For each, read the relevant code/files so you understand the full situation, then present the question with that context and concrete options where possible. The follow-up file's summary alone is rarely enough — the user needs to see what's actually going on before they can answer. After getting the answer, take action if the answer implies a code change.

Files to Delete

List each file with a one-line explanation of why. Offer:

• Delete all — remove everything listed
• Pick individually — go through one by one
• Skip — leave them for now

DB Migrations

List the schema changes. These always need manual review. Just present them clearly — don't offer to run them.

Skipped Items

Opportunities the agent chose not to act on. For each:

• Plan it — create a plan file for future work
• Add to backlog — lighter-weight tracking
• Dismiss — not worth pursuing

Borderline Insights

Findings the agent wasn't sure were worth persisting. For each:

• Add to CLAUDE.md — if it's a project-wide rule most sessions need
• Add to a reference file — if it's topic-specific, or a close call (ask which file)
• Add to MEMORY.md — if it's cross-project knowledge
• Dismiss — not worth keeping

Suggested Follow-Up Work

Potential new work items. For each:

• Create plan — write a plan file
• Add to backlog — add as a backlog item
• Dismiss — not worth pursuing

4. Clean up

After all items are resolved:

1. Delete the follow-up file.
2. Summarize what was done: items kept, reverted, planned, dismissed.
3. If any items generated new plan or backlog files, list them.

Rules

• Context first, always. Before every question or set of options, show the concrete context: the relevant code snippet, diff (git show <commit>), file path, or error. The follow-up file's one-liner is a pointer, not enough context for a decision. Read the actual source before presenting anything to the user.
• Use AskUserQuestion with concrete options — don't ask open-ended questions when you can present choices.
• Batch related items when possible (e.g., "these 3 skipped items are all test coverage — plan all, dismiss all, or pick individually?").
• When reverting, use git revert on the specific commit rather than manual edits, unless the commit contains mixed changes.
• When creating plan files, follow the project's existing plan format (check .plans/ or plans/ for examples).
• Keep momentum — the goal is to process the entire file in one session.