Resolve

Resolve

Contract

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.