turn

0:skill:turn

---
name: turn
description: "signals that the user is done with their turn in the PR review processs, instructs the assistant that their turn is up and that they may review the user's comments. use proactively when user is done with their turn"
---
# PR Review Turn

You are working on your turn in a round of a pull request review. Follow the below steps

## Step 1: Explore
launch /opsx:explore with the below argument
> Read every unresolved PR review thread and every comment in each thread as one corpus before reasoning about them or responding to any of them. Comments often relate to each other — sometimes across file boundaries — and a reading that treats them as independent misses the connective tissue. Think about how the comments fit together first. Then think about how to address them together. Be mindful to read ALL comments in the thread exhaustively and meticulously. You must not miss a single comment.. sometimes the user replies in several comments to the same thread - reading one comment or two is EXPLICITLY FORBIDDEN- so is reading the last N or first N comments.


## Step 2: Propose

You **MUST** read the project engineering rules and select the ones that apply to design / proposal / architecture stages.

Write a reply into every applicable thread, each carrying enough context such that the reviewer can pick it up without scrolling up and down. That aside: name the related comments, the shared cause, and your proposed direction.

When you reference another comment, do not just point at it by file and line. Link to the comment AND block-quote the relevant fragment inline, so the thread is self-contained and the reviewer never has to navigate away to follow your reasoning. That being said, copy as little as possible from the original comment to be respectful of human signal to noise ration limitations.

Inside each thread: theorize, explain your reading, propose a fix, push back if the suggestion is wrong. Stay in writing mode.

If you agree and have nothing to add, reply 👍. Don't ack with prose — long pleasantries waste the user's energy and bury important comments.

If the user has signed off on a thread (an explicit comment such as "LGTM" or "sounds good" or any term of agreement which implies the discussion has run its course, or a 👍 or 🚀 reaction from the user on the thread), run /opsx:propose and extend the existing proposal to support the latest comments. commit and push any changes.

### Next Step Guard
Only proceed to the next step once all of the below have been observed on your turn
- The user has not opened a new thread
- The user has not made a new comment on ANY thread
- All of the existing threads have been signed off by the user

## Step 3: Apply

run /opsx:apply
commit and push.

## Step 4: Verification
Run /opsx:verify
After done applying, return to the thread and post a follow-up comment that proves what you did. Include the changed code as a fenced block, and block-quote the parts of the comment your change addresses so the reader can verify the move without leaving the thread. Link to the commit by its full GitHub URL (the `https://github.com/<owner>/<repo>/commit/<sha>` form) — not the bare sha — so the reader can click straight through to the diff in their browser. Do not resolve or close the thread yourself — only the user decides whether more work is needed.

## Quality Gates

Always do the below

- Commit according to @.claude/rules/engineering/git-commit-message.md

## Guardrails

Never ever do the below

- Resolve threads. 
  - That is reserved only to the user. assistants dont decide when a thread is resolved.

- During steps 1 and 2, you MUST NOT actually act on any comment:
  - No file edits / writes.
  - No bash commands.

1:rule:git-commit-message

# Authoring Commit & Stash Messages

- First line: `<ISSUE-ID>`
- Second line: `<branch-suffix>` (text after ticket ID, with hyphens/underscores replaced by spaces)
- Third line: *blank line*
- Subsequent lines: <message body>

## Composing a Message

- Use imperative mood
- Be concise yet descriptive
- Summarize the changes made
- Avoid vague phrasing like "update" or "fix"
- In your message, group changes according to the categories listed below, in the specified order.

## Categories

1) Bug Fixes
2) New Features
3) Performance Improvements
4) Infrastructure / CI / CD Changes
5) Testing Improvements
6) Code Refactoring
7) Agentic Coding Assistant Changes
8) Documentation Updates
9) General - Catch all for changes that don't fit above categories.


## Changes Affecting Multiple Files

- When a bunch of files change, recall each group of files whose change served a purpose, then think about each change set's purpose.
- Group each discrete changeset under a single entry, describing
  - The overall purpose
  - Each file and what has been changed, framed in purpose terms
- Each such group's message entry must be self contained, relying on no external knowledge that is not listed in the message.

## Success Criteria

- No duplicate categories in the commit message.
- No two entries are related to one another but listed as separate items.
- no "co-authored by" or "generated by" comments are present in the message.