Krammeprresolve Review

Resolve Review Findings

Workflow

Step 0: Check for input

Before searching for reviews, check if the user provided input directly with the command:

1. Check for arguments after the command — If the user wrote /kramme:pr:resolve-review <something>:

   • Set REVIEW_SOURCE=auto by default.
   • Preferred source flags:
     • --source local or --local → set REVIEW_SOURCE=local
     • --source online or --online → set REVIEW_SOURCE=online
   • Legacy source flag (still supported):
     • --review-source local|online
   • If <something> includes both local and online source selections (across any source flags):
     • Ask the user to choose exactly one source value (local or online), then stop
   • If <something> includes --source or --review-source with any other value:
     • Ask the user to choose local or online, then stop
   • Remove any source flags (--source ..., --local, --online, --review-source ...) from remaining input before classification
   • If <something> includes --auto (preferred), --reply (legacy), or --answer-and-resolve (legacy):
     • Set ANSWER_AND_RESOLVE=true
     • Remove --auto / --reply / --answer-and-resolve from remaining input before classification
     • Treat this as permission to post replies and resolve addressed review threads/discussions directly on the PR/MR
   • If <something> includes --granular:
     • Set GRANULAR_COMMITS=true
     • Remove --granular from remaining input before classification
   • If <something> includes --severity <levels>:
     • Parse comma-separated severity levels. Valid values: critical, important, suggestion (maps to High, Medium, Low respectively)
     • Store as SEVERITY_FILTER
     • Remove --severity <levels> from remaining input before classification
     • When set, only findings matching the specified severities are addressed; others are skipped with Action taken: Skipped — outside severity filter.
   • If REVIEW_SOURCE=local and <something> includes a URL:
     • Ask the user to either remove the URL or switch to --source online / --online, then stop
   • If REVIEW_SOURCE=auto and <something> includes a URL:
     • Set REVIEW_SOURCE=online and treat the URL as the external review source
   • If <something> looks like review content (e.g., contains code comments, file references, or review-like text) → treat it as the review to resolve
   • If <something> looks like instructions (e.g., "focus on security issues", "only address high priority items") → store as additional instructions to apply during evaluation and implementation
   • If <something> is a URL → treat as external review source (fetch from that URL)

2. Apply additional instructions throughout — If the user provided instructions (not review content), keep them in mind when:

   • Prioritizing which findings to address
   • Evaluating whether to implement a fix
   • Deciding how to implement fixes

Step 1: Find the review

If no review content was provided in Step 0:

1. If REVIEW_SOURCE=local:
   • Read REVIEW_OVERVIEW.md only (do not use UX_REVIEW_OVERVIEW.md, chat, or PR/MR APIs)
   • If the file is missing, ask the user to provide review content, switch to --source online / --online, or run /kramme:pr:code-review first
   • Treat this as an internal review
2. If REVIEW_SOURCE=online:
   • If a PR/MR URL is provided in arguments or chat, fetch review comments/discussions from that URL
   • Otherwise, fetch unresolved review comments from the current branch's PR/MR:
     • Detect hosting platform: check for .gitlab-ci.yml (GitLab) or .github/ directory (GitHub)
     • For GitHub: Use gh pr view --json reviews,comments and gh api repos/{owner}/{repo}/pulls/{number}/comments
     • For GitLab: Use GitLab MCP tools or API to fetch unresolved discussions
   • Treat this as an external review
3. If REVIEW_SOURCE=auto:
   • Check for review files first:
     • REVIEW_OVERVIEW.md (generated by /kramme:pr:code-review)
     • UX_REVIEW_OVERVIEW.md (generated by /kramme:pr:ux-review)
     • PRODUCT_REVIEW_OVERVIEW.md (generated by /kramme:pr:product-review)
     • If any file exists, parse it as the review to resolve
     • If multiple exist, ask the user which to resolve (or resolve them sequentially)
     • This is an internal review
   • If no file found, scan chat context for:
     • Code review content from the agent → internal review
     • A PR/MR URL provided by the user → external review (fetch from that URL)
   • If still nothing found, fetch from current branch's PR/MR using platform-specific commands/APIs
4. If no review found for the selected source mode — Ask the user to provide review content, provide a PR/MR URL, or choose a different source mode
5. List all findings — Present each comment with its file location, line number, and content

Step 2: Evaluate findings

For each finding, before implementing any fix:

2a. Check for scope creep

First, determine the PR's intended scope by examining:

• The PR title and description
• The types of files changed (feature code, tests, configs, etc.)
• The commit messages on the branch
• Any linked issues or tickets

Then, for each finding, ask: "Is this within the PR's scope?"

In scope — Implement if valid:

• Bug/issue in code that this PR modified
• Missing error handling for new functionality
• Test coverage gaps for the PR's changes
• Documentation for new/changed behavior
• Security or correctness issues in the PR's code

Out of scope — Do NOT implement, document for later:

• Refactoring requests for code the PR didn't touch
• Suggestions to add features beyond the PR's goal
• "While you're here, also fix X" in unrelated files
• Style/naming changes in untouched code
• Performance optimizations unrelated to the PR's changes
• Requests to expand the PR's scope significantly

Gray area — Use judgment:

• Small fixes in adjacent code that make the PR's changes cleaner
• Consistency improvements that affect a few lines near the PR's changes
• If unclear, ask the user whether to include or defer

2b. Assess validity (for in-scope findings only)

For external reviews:

• Assess validity — Determine if you agree with the reviewer's comment
• If you disagree — Note your reasoning; you may still implement if it's a matter of preference, or skip if the suggestion would harm code quality
• If you agree — Proceed with the fix

For internal reviews (self-generated): Skip this substep and proceed directly to implementation.

2c. Prioritize by severity

• High (= critical): Security issues, data loss risks, broken functionality, blocking bugs
• Medium (= important): Performance problems, maintainability concerns, missing error handling
• Low (= suggestion): Style preferences, naming suggestions, minor refactors

If SEVERITY_FILTER is set, skip any finding whose severity is not in the filter. Document skipped findings with Action taken: Skipped — outside severity filter.

2d. Dismiss nitpicks with judgment

Not every finding deserves a code change. Dismiss findings that meet ALL of these criteria:

• Severity is Low
• The suggestion is subjective (style, naming preference, alternative approach that isn't clearly better)
• Implementing it would churn code without measurable improvement

For dismissed findings, document them in the output with Action taken: Acknowledged — no change. and a one-line rationale. For external reviews with ANSWER_AND_RESOLVE=true, post a polite reply explaining why no change was made, but do NOT mark the thread as resolved (let the reviewer decide).

Step 2.5: Create rollback checkpoint

Before making any code changes, create a checkpoint commit so fixes can be cleanly reverted if they introduce problems:

# Stage any uncommitted work first
git add -A
# Only create checkpoint if there are staged changes
git diff --cached --quiet || git commit -m "wip: pre-resolve-review checkpoint"

Record the checkpoint commit SHA as CHECKPOINT_SHA:

CHECKPOINT_SHA=$(git rev-parse HEAD)

If fixes later fail verification (Step 4), offer to roll back:

git reset --hard "$CHECKPOINT_SHA"

Step 3: Implement fixes

Work through each finding in priority order, applying the guidelines below.

If GRANULAR_COMMITS=true: After implementing each finding, create a dedicated commit for it before moving to the next finding:

git add -A
git commit -m "review: <brief description of the fix>"

Each commit should be self-contained and pass linting/formatting on its own. If a finding requires changes across multiple files, include all of them in the same commit. If two findings touch the same lines and cannot be separated cleanly, combine them into a single commit and note both finding numbers in the message.

Step 4: Validate and summarize

• Validate — Check for and fix any new linting, formatting, and testing issues. If validation fails after multiple fix attempts and CHECKPOINT_SHA exists, offer to rollback: git reset --hard "$CHECKPOINT_SHA"
• Review response behavior:
  • Default (no flag): Do NOT resolve or reply to comments on the platform
  • If ANSWER_AND_RESOLVE=true and the review source is external: post replies for each external review comment, then resolve addressed threads/discussions on the PR/MR
  • If REVIEW_SOURCE=local: do not post replies or resolve threads on the platform, even when --auto or a legacy reply alias was provided
  • If ANSWER_AND_RESOLVE=true and the review source is external: for disagreements or out-of-scope findings, post a rationale reply, but do not mark as resolved unless explicitly requested by the reviewer/user
• Generate summary — Write resolutions back to the source review file (see Output format below). If the source was UX_REVIEW_OVERVIEW.md, update that file. If the source was REVIEW_OVERVIEW.md or an external/chat review, write to REVIEW_OVERVIEW.md.

Guidelines

General principles

• Write clear, maintainable code — prioritize readability and simplicity; prefer straightforward solutions over clever ones, but do not be lazy.
• Add comments where needed — if a fix involves non-obvious logic or trade-offs, include concise comments explaining the reasoning.
• Ask questions if unsure — if any aspect of the fix or the related business logic is unclear, seek clarification before proceeding.
• Follow project conventions — ensure fixes align with the best practices outlined in AGENTS.md.
• Stay focused — limit changes to what's necessary for the fix; avoid unrelated refactors or improvements.

For each fix

• Understand the root cause — before making changes, ensure you fully grasp why the issue exists.
• Be comprehensive within scope — don't just patch the specific lines mentioned; briefly investigate and apply the same fix pattern wherever the same issue exists in the code touched by this branch.
• Update tests — add or adjust appropriate tests to cover any new logic or edge cases.

When handling errors or external data

• Consider graceful degradation — where it makes sense, prefer non-fatal error paths that preserve partial success. However, if failing hard is the safer or more appropriate choice, do that instead and explain why in succinct code comments.
• Be defensive at boundaries — when parsing responses from third-party services, external APIs, or user input, normalize/fallback rather than assuming a single format. However, don't over-engineer defensiveness against internal code — trust our own contracts unless there's evidence they're being violated.

Output format

Write resolutions to the appropriate file in the project root:

• If the source review was UX_REVIEW_OVERVIEW.md → update UX_REVIEW_OVERVIEW.md
• Otherwise → create/update REVIEW_OVERVIEW.md

For external reviews

Use this format for each comment:

Comment #N: [Brief description]

File: path/to/file.ts:123

Reviewer's comment:

[Quote the original review comment]

Assessment: Agree / Agree With Modifications / Disagree

Rationale: [Why you agree or disagree with this feedback]

Action taken: [Description of the fix implemented, or "No action" with explanation]

Draft reply:

[Suggested response to post to the reviewer]

For internal reviews

Use this simplified format for each finding:

Finding #N: [Brief description]

File: path/to/file.ts:123

Issue: [Description of the issue]

Action taken: [Description of the fix implemented]

Out-of-scope section

If any findings were identified as scope creep, document them:

Deferred: [Brief description]

File: path/to/file.ts:123

Finding:

[Quote the original finding/comment]

Reason deferred: [Why this is out of scope for this PR]

Recommendation: [Suggested follow-up: create a separate PR, open an issue, discuss with team, etc.]

Summary section

At the end, include:

• Summary of changes made
• Count of findings: N addressed, M deferred as out-of-scope
• Note any breaking changes to API contracts or config behavior
• Flag areas that need manual verification due to potential edge cases or risk

Converted and distributed by TomeVault — claim your Tome and manage your conversions.