merge-request · diff
git:20260917.4faca15 to git:20260922.913f49e
13 added, 62 removed. Audit A to A.
---
name: merge-request
- description: "Maintain your own merge request — triage review threads, batch fixes, resolve conflicts, re-request review."
+ description: Load when maintaining your own pull request after review feedback or conflicts
+ license: MIT
---
- Use repository, issue, pull-request, search, checkout, push, and Actions-watch operations.
- Show the complete payload immediately before every remote write.
-
- ## Draft state
-
- Do not disrupt an active reviewer.
- An assignee who is not you means review is in progress.
- Do not change draft state, reviewers, or assignment in that case.
- A reviewer who has left threads is done reviewing.
- Do not flip the request back to draft while you fix their feedback.
-
- Mark the request draft only when there is no other assignee and you must make unrequested changes.
- Leave a comment first so reviewers know to stop.
- Where tracker sync follows request state, do not also write to the tracker.
-
- ## Triage
-
- Fetch both inline review threads and top-level comments.
- Classify each comment as actionable, discussable, or already resolved.
-
- Treat review comments pasted by the user and implementation feedback as internal iteration guidance by default. Draft or post a reply only when the task requires one.
-
- Present each comment before acting:
-
- 1. Full comment text, location, author, and timestamp.
- 2. Relevant code context and thread state.
- 3. Proposed fix or exact reply text.
-
- Apply each actionable fix after presenting the relevant context. Post each reply after its wording is finalized.
-
- ## Fix cycle
-
- Batch the work.
- Fix every actionable thread first.
- Run QA first if any fix touches UI, templates, CSS, or frontend code.
- Commit and push once.
- Resolve fixed threads silently after the fix is pushed.
-
- Batch non-fix replies.
- Present all reply text together. Post the replies consecutively.
-
- Look for a fitness function.
- If feedback expresses a rule the repository should always enforce, propose a lint rule, test, or CI gate instead of only restating the rule.
-
- ## Conflicts
-
- Resolve conflicts by preserving both sides' intent.
- Examine both sides.
- Do not mechanically accept one side.
- Run the full required suite after conflict resolution.
- Merge instead of rebase when the request already has reviews.
- Rebasing invalidates inline comments.
-
- ## Re-request
-
- Present the final summary first.
- After the final summary, mark ready and re-request previous reviewers.
- Do not add a comment unless a policy above requires it.
- Refresh QA evidence in the description if a prior ship added the `<!-- qa:start -->` block.
- Use the `qa-report-publish` skill for that update.
- Re-request only at a stable moment.
+ - Fetch inline review threads and top-level comments.
+ - Classify each item as actionable, discussable, or resolved.
+ - Present the full comment, location, author, timestamp, relevant code, and proposed action before changing code or replying.
+ - Batch actionable fixes. Run the lowest suitable verification tier. Run browser QA first for UI changes.
+ - Use `shipit` for the commit and push cycle.
+ - Resolve a fixed thread only after the fix is pushed.
+ - Show the complete payload before every remote write.
+ - Do not change draft state, reviewers, or assignment while another reviewer is active.
+ - Resolve conflicts by preserving both sides' intent. Run the full required checks after resolution.
+ - Re-request review only after the final summary and stable pushed head are ready.
+ - Do not rebase a reviewed request unless explicitly required; rebasing invalidates inline comments.