copilot-address-reviews

Copilot Address Reviews

Given a GitHub PR link, process Copilot review items one at a time. NEVER assume review is correct. NEVER change code only to satisfy review text.

Inputs

• PR URL
• Local checkout for PR branch, or clear path to fetch/switch to it
• User confirmation for subjective, design, or constraint-driven items

Workflow

1. Resolve bundled scripts relative to the directory containing this SKILL.md, not the current working directory. Resolve the shared typed runtime owner at ../campaign/references/runtime-adapter.md from that same skill directory. NEVER cd to the skill directory — the fetcher's relative scratch default would land output there.

2. At workflow entry, call the runtime owner's resolve_repository_context(checkout) exactly once with the supplied local checkout. Then call run_argv with these distinct fields (the script creates the scratch directory if missing):

   run_argv(
     argv: ["bash", fetch_review_items_script, "--tmp-dir", repository.scratch_root, pr_url],
     cwd: repository.project_root, stdin_file: null, stdout_file: null
   )
   

   fetch_review_items_script is the absolute path resolved in step 1. Invoke bundled scripts through their interpreter — bash for .sh, python3 for .py — NEVER bare: a bare invocation depends on the executable bit and the shebang surviving every checkout, archive, and install path.

3. Read path_join(repository.scratch_root, "copilot-review-items.json") through read_bytes as the primary worklist of unresolved items only.

4. Inspect the sibling paths under repository.scratch_root named copilot-review-items.raw.json, gh-pr-view.json, and gh-pr-review-threads.json through read_bytes when dedup or extraction needs verification. Never resolve these from cwd.

5. Select next unhandled unresolved item from worklist. NEVER work resolved items.

6. For current item, choose exactly one outcome before moving on:

   • valid → fix
   • invalid → no code change
   • subjective/constraint-driven/ambiguous → ask user
   • deferred/won't fix → ask user, then no code change
   • already fixed on branch → no code change

7. After each valid item:

   • make smallest code change that addresses verified issue
   • run focused tests first
   • add/update tests when they materially prove claim or prevent regression
   • run broader relevant tests when change touches shared behavior
   • commit only files for that item
   • after commit, resolve corresponding GitHub review thread/comment if it is still unresolved

8. After each invalid, deferred, won't-fix, or already-fixed item:

   • record why no code change is needed
   • if current source/tests do not already make decision obvious, add concise code comment near relevant logic so future reviewers can see reasoning or constraint
   • if outcome is deferred or won't fix and user confirmed that outcome, resolve corresponding GitHub review thread/comment if it is still unresolved
   • do not make speculative edits

9. Mark current item handled, then look up whether more unhandled items remain.

10. If more items remain, return to step 5. Continue until worklist is empty.

11. After all items, report every item, decision, evidence, and commit hash when applicable.