# Krammeprresolve Review > Resolve findings from code reviews by implementing fixes and documenting changes Use when this capability is needed. - Skill: `tomevault-io/krammeprresolve-review` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/krammeprresolve-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/krammeprresolve-review/raw - Safety review: pending (external: skill-scanner PASS, skillspector CAUTION) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/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 `: - 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 `` 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 `` 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 `` 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 `` includes `--granular`: - Set `GRANULAR_COMMITS=true` - Remove `--granular` from remaining input before classification - If `` includes `--severity `: - Parse comma-separated severity levels. Valid values: `critical`, `important`, `suggestion` (maps to High, Medium, Low respectively) - Store as `SEVERITY_FILTER` - Remove `--severity ` 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 `` includes a URL: - Ask the user to either remove the URL or switch to `--source online` / `--online`, then stop - If `REVIEW_SOURCE=auto` and `` includes a URL: - Set `REVIEW_SOURCE=online` and treat the URL as the external review source - If `` looks like review content (e.g., contains code comments, file references, or review-like text) → treat it as the **review to resolve** - If `` 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 `` 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: ```bash # 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`: ```bash CHECKPOINT_SHA=$(git rev-parse HEAD) ``` If fixes later fail verification (Step 4), offer to roll back: ```bash 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: ```bash git add -A git commit -m "review: " ``` 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](https://tomevault.io/claim/abildtoft) — claim your Tome and manage your conversions.