# Resolve > Use when addressing review feedback: analyze mode classifies comment validity, reception mode applies accepted items with tests and drafts pushback. Not for GitHub PR threads: use resolve-pr-feedback. - Skill: `majiayu000/resolve-5` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds add majiayu000/resolve-5` - Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/resolve-5/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: majiayu000 (https://skillmd.com/u/majiayu000) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/majiayu000/resolve-5 --- # Resolve ## Contract | Field | Bound contract | |---|---| | Trigger | addressing review feedback or analyzing whether a comment is valid; for GitHub PR threads use resolve-pr-feedback | | Authority | Reversible local. Mode analyze is read-only. Mode reception writes only local source files, test files, and pushback drafts; rollback is version control or undo. No remote mutation. | | Side effect | analyze: classification and proposed solutions in chat, no code edits. reception: local edits, tests, and a draft file; no GitHub reply, CI trigger, or issue | | Done | every comment is classified; analyze: VALID ISSUE / NOT AN ISSUE / NEEDS CLARIFICATION with evidence and a recommended solution for each VALID ISSUE. reception: each item is clarified, implemented locally with its own test, or answered by a drafted pushback | ## Inputs - Mode: `analyze` or `reception`. Required. Default `analyze` when the user asks only whether comments are valid. - Feedback: the raw review comment(s), PR thread, or inline suggestion. Required. - Code under review: the relevant source files or their location. Required. - PR or issue thread: the full review context. Optional; use when available. ## Procedure 1. Parse every review comment into an isolated unit. Do not combine, rephrase, or infer unstated items. Done when: each comment stands as a separate item, or the run stops with "No comments supplied" on an empty or unparseable list. 2. Read the referenced code. Mode analyze: use only read-only tools (`grep`, `read`, `glob`, or shell equivalents such as `eza`, `rg`, `fd`, `head`, `tail`); never invoke `bash` write operations (`mkdir`, `touch`, `rm`, `cp`, `mv`, `git add`, `git commit`, `npm install`, redirects `>`, `>>`, or file-creating heredocs) or any tool with write, rename, delete, or staging arguments. Mode reception: read freely; writes are confined to steps 5 and 6. Done when: the code context for each item is read, or the item is marked unreadable. 3. Clarify each item to a concrete statement. Mode reception: resolve the precise intent from context or by asking the user; stop on any item that cannot be resolved to an implementable statement. Done when: every item is a concrete, assessable statement. 4. Classify each item. Done when: every item carries exactly one classification with evidence. - Mode analyze: - VALID ISSUE: the concern is confirmed by the code. Propose three distinct solutions with trade-offs and name the recommended one with justification. - NOT AN ISSUE: the concern is not supported by the code or contradicts project patterns. Supply evidence from the code. - NEEDS CLARIFICATION: the comment cannot be assessed without additional context. State exactly what is missing. - Stop before proposing solutions for any comment classified NOT AN ISSUE or NEEDS CLARIFICATION. - Mode reception: - Accepted: the suggestion aligns with the codebase and the user's intent. - Questionable: the suggestion is technically incorrect, out of scope, or conflicts with design intent. 5. Mode reception: apply accepted items one at a time. Apply the change to the relevant source file, write or update a test that covers the change, and verify the test passes before moving to the next item. Done when: each accepted item is implemented with a passing test. 6. Mode reception: draft factual pushback for questionable items in a local draft file. State the specific reason the suggestion is not accepted, such as a design conflict, incorrect assumption, or scope mismatch. Do not post it. Done when: each questionable item has a drafted reply. 7. Stop. Do not post any GitHub reply, open any issue, trigger any CI pipeline, or otherwise mutate any remote system. Done when: no remote state has changed. ## Failure and recovery - Empty input: return "No comments supplied" and stop. - Inaccessible code: if the referenced location cannot be read, classify the comment NEEDS CLARIFICATION in analyze mode, or report it unclarified in reception mode, with the specific access failure as the missing context. - Unresolvable ambiguity: analyze: classify NEEDS CLARIFICATION; do not guess intent or invent a fix. reception: stop and report which item cannot be clarified to a concrete statement; do not implement it. - Partial-result rule: if one comment cannot be processed, continue with the remaining comments and report the failure for the unprocessed one. Do not claim the whole batch succeeded. - User rejects an accepted item (reception): skip that item; continue with the remaining items. - Implementation blocked (reception): report the specific technical obstacle; do not widen scope. - Test fails (reception): fix the implementation, not the test. If the test is wrong, report it and stop. - Remote mutation attempted: refuse; log the blocked action. - Non-converged result: any unresolved failure produces a report listing unresolved items and blocked actions. The done predicate does not hold. ## Output - Mode analyze: per comment, in order: Comment, Status (VALID ISSUE | NOT AN ISSUE | NEEDS CLARIFICATION), then the status-specific block: for VALID ISSUE three numbered Solutions with trade-offs and the Recommended pick; for NOT AN ISSUE the Reason and Evidence; for NEEDS CLARIFICATION the exact Missing information. Stop after the last comment; emit no summary or overall-PR content. - Mode reception: a local report listing every feedback item, its classification (accepted or questionable), the actions taken for each accepted item, and the location of any drafted pushback. No remote state is changed.