Imported from ryumiel/devcanon (skills/play-review-response/SKILL.md). Install upstream with npx skills add ryumiel/devcanon --skill play-review-response. Copyright stays with the author.

Code Review Reception

Invocation Policy

This workflow is explicit-invocation-only. Do not select it from ordinary discussion, review-shaped text, possible behavior-change wording, or implementation-adjacent language. Run it only when the user explicitly invokes play-review-response or when an owning workflow explicitly hands off to play-review-response.

Overview

Code review requires technical evaluation, not emotional performance.

Core principle: Verify and classify before execution. Ask before assuming. Technical correctness over social comfort.

The Response Pattern

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. EXECUTE: Only after the earlier classification and selected execution mode
   authorize it; work one item at a time and test each

Execution boundary: Every instruction below to implement, fix, or execute assumes the earlier Writing Skills classification and selected execution mode have already authorized it.

Forbidden Responses

NEVER:

• "You're absolutely right!" (explicit CLAUDE.md violation)
• "Great point!" / "Excellent feedback!" (performative)
• "Let me implement that now" (before verification, classification, and mode selection)

INSTEAD:

• Restate the technical requirement
• Ask clarifying questions
• Push back with technical reasoning if wrong
• Proceed only through an authorized execution mode (actions > words)

Handling Unclear Feedback

If any item is unclear, STOP and do not implement anything yet. Ask for clarification on the unclear items first, because items may be related and partial understanding produces a wrong implementation. Worked example: examples/feedback-intake.md.

Source-Specific Handling

From the user

• Trusted - understand first; still apply the classification and mode gate before any mutation
• Still ask if scope unclear
• No performative agreement
• Proceed through the authorized mode or provide a technical acknowledgment

From External Reviewers

BEFORE selecting a mode:
  1. Check: Technically correct for THIS codebase?
  2. Check: Breaks existing functionality?
  3. Check: Reason for current implementation?
  4. Check: Works on all platforms/versions?
  5. Check: Does reviewer understand full context?

Push back with technical reasoning when the suggestion seems wrong. Say so and ask for direction when you cannot easily verify it. Stop and discuss with the user first when it conflicts with the user's prior decisions. Worked example: examples/feedback-intake.md.

Rule: "External feedback - be skeptical, but check carefully"

Structural Lifecycle Feedback

Treat lifecycle-sensitive review feedback as structural risk unless verification proves the concern is stale, invalid, already addressed, explanation-only, or safely inside the inline envelope. Lifecycle-sensitive feedback includes comments about operation start, readiness, success, failure, cleanup, retries, cancellation, disposal, restart, reconnect, stale state, stale events, concurrent or same-tick bypasses, correlation, ownership, or authoritative completion signals.

Structural-risk feedback requires the Writing Skills proportionality gate before inline or planned implementation selection. An in-scope product blocker that reaches implementation selection uses the existing planned route when structural risk requires it. Do not select inline merely because the reviewer's patch suggestion is small, the diff looks local, the user wants speed, or tests currently pass.

• Stale/invalid - retain the existing no-code response; do not select inline. Current code and current feedback-source state show the concern no longer applies or is technically incorrect; for GitHub/PR-thread-backed feedback, current thread state also supports that disposition.
• Already addressed - retain the existing no-code response; do not select inline. The pushed branch or current local diff contains the fix, and the same concern can be mapped to concrete evidence.
• Explanation-only - retain the existing no-code response; do not select inline. No code change is required, and a concise reply can explain why with source evidence.
• Safely inline - continue toward inline selection only when the Writing Skills proportionality gate authorizes inline selection and every normal inline condition is true. The lifecycle concern must not affect operation boundaries, ownership, ordering, correlation, cleanup, retry, failure, or externally visible behavior.

For executable lifecycle-sensitive concerns, check the operation lifecycle before writing code or a plan:

• Start boundary - what begins the operation and what prevents duplicate, same-tick, or concurrent starts?
• Readiness boundary - what state means the operation is allowed to proceed?
• Success boundary - what authoritative completion signal marks success, and who owns setting it?
• Failure boundary - what failures are recoverable, retryable, terminal, or user-visible?
• Ownership - which component owns state transitions, cleanup, disposal, cancellation, restart, reconnect, and externally visible effects?
• Identity / correlation - how events, callbacks, jobs, retries, or responses map to the current operation rather than a stale one.
• Stale state and events - how old events, old promises, cached state, or previous attempts are rejected or ignored.
• Retry / cancellation / disposal / restart / reconnect - how repeated or interrupted lifecycles avoid double effects and missed cleanup.
• Cleanup - who owns normal cleanup, stale cleanup, speculative or render-only cleanup, and cleanup after failure or cancellation?
• Tests - what focused checks cover normal, stale, cleanup, retry, cancellation, failure, same-tick, and concurrent paths?
• Docs / contracts - whether the review feedback changes public contracts, workflow policy, skill/agent contracts, generated-output expectations, or consumer-facing behavior.

Execution Mode Selection

After source-aware feedback intake and verification, classify each verified concern before changing code. Source-aware feedback intake means capturing the current feedback-source state for every concern, fetching current thread state when feedback is GitHub/PR-thread-backed, mapping feedback to the same concern, and separating executable feedback from stale, already-addressed, explanation-only, or unclear feedback before selecting a mode.

Proportionality gate (Writing Skills)

Before choosing inline or planned implementation, load the bundled references/finding-proportionality.md. Writing Skills remains the classification owner; this runtime copy is its portable installed representation and does not add policy here. Only an in-scope product blocker, or a proof/test correction at its existing proof owner, reaches mode selection through the existing bounded route. Proof/test corrections remain proof/test-only and cannot expand production behavior. Every other classification disposition bypasses inline/planned implementation selection and retains its existing no-code disposition or independent route.

Implementation selections:

• Inline execution - handle directly in this skill.
• Planned execution - write a verified review-response planning input, invoke play-planning, then hand the approved generated plan to play-subagent-execution.

Non-implementation outcome:

• No-code response - reply, report, or ask without changing code.

No-code response outcomes include technically invalid feedback, stale feedback, already-addressed feedback, explanation-only feedback, and needs-user-clarification feedback. No-code does not mean ignored: provide the verified evidence, keep unclear or unresolved concerns open, and follow the GitHub thread reply/refetching and resolution eligibility rules when applicable.

For an adjacent independently releasable defect, produce an evidence-bearing independent-owner, parent, or manual-action handoff through this existing no-code outcome. Keep the active issue unchanged, do not auto-create follow-up tracker work, and preserve the review thread until the handoff is recorded.

Inline execution is allowed only when every inline condition is true:

• The feedback is one or two clear, low-risk, local comments.
• The affected code is in the same file or tightly local files.
• There is no ambiguity after verification.
• There is no public contract, workflow-policy, skill/agent contract, schema, generated-output, security, lifecycle, data-loss, or cross-module behavior risk.
• The change needs no new test design beyond existing obvious focused checks.
• Quick verification can prove the fix without broader planning, and the fix can be explained clearly in-thread.

Planned execution is required for multi-item feedback outside the inline envelope. Planned execution is required for ambiguous feedback after clarification establishes an executable concern; unclear reviewer intent still stops for clarification before planning. Planned execution is required for policy-sensitive feedback. Planned execution is required for contract-sensitive feedback. Planned execution is required for schema changes. Planned execution is required for generated-output changes. Planned execution is required for security-sensitive changes. Planned execution is required for lifecycle changes. Planned execution is required for recovery behavior. Planned execution is required for data-loss risk. Planned execution is required for cross-module behavior. Planned execution is required for high-risk changes. Planned execution is required when audit evidence or traceability is needed. Planned execution is required when independent implementation/review gates are needed. Planned execution is required when explanation-only feedback is mixed with code changes.

For planned execution, do not independently author the full executor-ready implementation plan in this skill. Structural planned review-response work writes a verified .ephemeral/*-design.md planning input and invokes play-planning with:

Route: review-response-parent-owned
Design: <path>

Before the Write tool call for that planning input, compute the design path and apply the canonical .ephemeral write guard:

DESIGN_PATH=".ephemeral/$(date +%F)-review-response-design.md"
[ -L .ephemeral ] && { echo ".ephemeral must be a directory, not a symlink" >&2; exit 1; }
mkdir -p .ephemeral
[ -L "$DESIGN_PATH" ] && rm "$DESIGN_PATH"
[ ! -d "$DESIGN_PATH" ] || { echo "design path is a directory: $DESIGN_PATH" >&2; exit 1; }
[ ! -e "$DESIGN_PATH" ] || [ -f "$DESIGN_PATH" ] || { echo "design path exists but is not a regular file: $DESIGN_PATH" >&2; exit 1; }

The planning input must explicitly include:

• review thread/comment mapping;
• current feedback-source state;
• current thread state evidence when feedback is GitHub/PR-thread-backed;
• current code evidence;
• concern dispositions;
• root-cause or structural diagnosis for related, policy-sensitive, contract-sensitive, lifecycle-sensitive, or cross-module feedback;
• authoritative source for each disputed behavior;
• required fix strategy by cluster;
• Contract Decisions or an equivalent clearly labeled contract-decision section when review-response work creates or changes a boundary, or an explicit blocker or intentional implementation choice disposition with authority, risk, and proof expectation for any missing contract decisions;
• GitHub side effects outside executor scope.

play-planning owns task decomposition, contract-heavy tables, boundary-contract traceability, task contract checklists, traceability matrices, plan review, and executor-ready plan shape. This skill owns source-aware feedback intake, verification, execution-mode selection, no-code dispositions, follow-up commit continuity, GitHub thread replies/refetching, resolution eligibility, and final PR closeout. It also owns the verified review-response planning input.

After play-planning emits Plan written to <path>. and Reviewed digest: <sha256>, capture the path and exact reviewed digest in controller-local state, present the generated plan for user approval, and invoke play-subagent-execution only after approval with:

Plan: <path>
Expected digest: <sha256>

Immediately before that executor handoff, compute SHA-256 over the exact saved plan bytes with the portable shasum -a 256 / sha256sum plus awk '{print $1}' pattern. Validate the extracted field as lowercase 64-hex and compare it with the preserved reviewed digest. Any missing tool, unreadable plan, hashing failure, malformed digest, or mismatch stops before execution and routes the changed plan through a fresh play-planning wave; do not update the expected digest to match changed bytes.

The generated plan remains a valid direct/manual play-subagent-execution handoff under the executor's current structural task-contract gate. It must not rely on issue-priming --auto reduced-route behavior, because direct/manual review-response plans do not carry parent-owned issue-priming state, validated auto-handoff evidence, or a guaranteed downstream branch-review --fix loop. For Route: review-response-parent-owned, play-planning emits the plan path only after both Plan Review and Implementer Executability Review pass. A failed, missing, or unreadable executability review remains inside play-planning and stops before this approval gate or any execution handoff.

play-subagent-execution owns executor-owned mechanics after the handoff: task-contract validation, dispatch/skip-dispatch, review routing, snapshot handling, implementer lifecycle, final whole-implementation review for direct/manual calls, and whole-diff gate validation only when a caller-owned handoff supplies that gate.

Direct/manual review-response plans do not get an automatic whole-diff review after the executor's final code-quality reviewer. Run branch-review before opening or updating a PR when planned review-response work needs whole-diff coverage.

Plan Approval Gate

For planned review-response work, create and self-review the written .ephemeral/*-design.md planning input, invoke play-planning with Route: review-response-parent-owned and Design: <path>, and capture the emitted Plan written to <path>. and Reviewed digest: <sha256> lines before implementation, only after play-planning has completed both Plan Review and Implementer Executability Review. This gate borrows the approval-gate shape from play-brainstorm without invoking play-brainstorm and without making it a dependency of play-review-response.

Before handing the generated plan to play-subagent-execution, present the plan to the user with a distinct producer notice and approval prompt. Use the captured concrete plan path in human-facing approval text by replacing {captured-plan-path} below with the path captured from play-planning. Do not include a second Plan written to <path>. placeholder, because play-planning owns the single contract notice.

I wrote the review-response plan at {captured-plan-path}.
Please review it. I will not implement it until you approve the plan.

The plan approval gate is explicit:

• The planning input and generated plan must be Markdown-valid enough for explicit repository scans and remain agent-local evidence under .ephemeral/; they are not durable product, architecture, or workflow documentation.
• Run planning input self-review before invoking play-planning; play-planning owns plan self-review, Plan Review, and Implementer Executability Review before it emits Plan written to <path>..
• Wait for user approval before implementation begins.
• Approval happens after Plan written to <path>. and before play-subagent-execution.
• play-planning returns Plan written to <path>. for this route only after both Plan Review and Implementer Executability Review pass; failed, missing, or unreadable executability review remains inside play-planning and stops before this approval gate.
• If the user requests any generated-plan change, route every generated-plan revision back through play-planning, including plan self-review, Plan Review, and Implementer Executability Review, before renewed approval.
• Repeat the user approval loop until the user approves or stops the work. There is no fixed maximum for this human approval loop.
• Keep the separate play-planning agent-review cap out of the user approval gate; that cap governs planning-agent review rounds, not how many times the user may request plan changes before approval.

Planning Input Self-Review

Planning input self-review is semantic validation of the review-response planning input before invoking play-planning. Markdown lint may be useful, but it is not planning input self-review; formatting checks do not prove that reviewer concerns are understood, current, correctly classified, or executable.

Before invoking play-planning, the planning input must include a named Planning Input Self-Review section. The section must show every current review concern/comment maps to one of these dispositions: executable, stale/invalid, already addressed, explanation-only, unclear, or unresolved. Put the evidence inside that named section so the approval gate has one auditable review location.

For each concern, validate that:

• The reviewer concern is accurately restated.
• The current feedback-source state was captured and used.
• For GitHub/PR-thread-backed feedback, the current thread state was fetched and used.
• The current code evidence supports the disposition.
• The execution mode is justified under inline/planned/no-code rules.
• The authoritative source for each disputed behavior is identified.
• The required fix strategy by cluster is identified.
• Boundary-changing review-response planning inputs include Contract Decisions or an equivalent clearly labeled contract-decision section, or record an explicit blocker or intentional implementation choice disposition with authority, risk, and proof expectation for missing contract decisions.
• GitHub side effects are outside executor scope.
• The planning input is suitable for play-planning through Route: review-response-parent-owned and Design: <path>.

Treat review-feedback intake as a ledger of evidence. Record enough current feedback-source state, current thread state when the feedback is GitHub/PR-thread-backed, code evidence, disposition reasoning, and gaps to prove every review concern/comment maps to either a no-code disposition or an implementation work item. Then derive required fix strategy by cluster rather than mechanically creating one implementation task per review comment. The work items address the structural cause rather than only the visible comment text.

Invalid self-review examples:

• Markdown lint passed
• Planning input looks good
• All comments listed without concern-to-fix mapping

Valid self-review example:

Comment mapping: C1 and C3 map to lifecycle or correlation gap; C2 is
explanation-only.
Current feedback-source and code evidence: captured the current reviewer
feedback state, fetched unresolved GitHub PR threads at 2026-06-02, and
confirmed `src/worker.ts` still accepts stale completion callbacks.
Gaps: no test covers same-tick cancellation followed by stale completion.
Root-cause diagnosis: missing validation boundary at the operation owner.
Root-cause-derived fix strategy: strengthen the owner-side completion guard and
add stale-callback coverage, rather than one task per comment.
Residual risks: retry cleanup still needs focused verification.
Planning handoff suitability: design has source authority, is ready for
`Route: review-response-parent-owned` and `Design: <path>`, and GitHub closeout
remains with `play-review-response`.

GitHub reply, refetch, and resolution closeout remain owned by play-review-response and must not be dispatched as play-subagent-execution implementation tasks.

Root Cause / Structural Diagnosis

For multiple related comments, contract-sensitive, policy-sensitive, lifecycle-sensitive, or cross-module feedback, include a Root Cause / Structural Diagnosis section or equivalent evidence before deriving work items.

Classify each related feedback cluster using the closest diagnosis:

• isolated implementation mistake.
• duplicated source of truth.
• unclear ownership or authority.
• contract drift between producer and consumer.
• missing validation boundary.
• lifecycle or correlation gap.
• test fixture mismatch hiding the real contract.

For each cluster, identify the authoritative source for the disputed behavior and classify the fix strategy:

• patch local symptoms.
• consolidate authority.
• extract or strengthen a shared validation layer.
• update producer contract.
• update consumer adapter.
• document a no-code policy boundary.

After the executor returns, this skill resumes ownership of explanation-only replies, thread refetching, resolution eligibility, and final PR-thread closeout.

Plan-plus-executor handoff example:

Reviewer: "This routed feedback needs a coordinated correction."
Verification: current evidence identifies a policy-sensitive,
contract-sensitive, multi-surface concern with traceability needs.
Classification: in-scope product blocker (Writing Skills).
Mode: Planned execution.
Action: Apply the canonical `.ephemeral` write guard, write
`.ephemeral/<date>-review-response-design.md`, invoke `play-planning` with
`Route: review-response-parent-owned` and `Design: <path>`, wait for both
planning review gates to pass, capture `Plan written to <path>.` and
`Reviewed digest: <sha256>`, ask for approval using `{captured-plan-path}`
replaced with the captured path, wait for approval, rehash the exact saved plan
bytes, then invoke `play-subagent-execution` with `Plan: <path>` and
`Expected digest: <sha256>` only when the digest still matches.

Worked inline, no-code, and GitHub-closeout-exclusion scenarios: examples/execution-mode-scenarios.md.

YAGNI Check for "Professional" Features

When a reviewer suggests "implementing properly", grep the codebase for actual usage first. If nothing calls it, propose removing it. If it is used, let the classification and selected execution mode determine any work. Worked example: examples/yagni-check.md.

Rule: "You and reviewer both report to me. If we don't need this feature, don't add it."

Implementation Order

FOR multi-item feedback whose classification and selected mode authorize execution:
  1. Clarify anything unclear FIRST
  2. Then execute in this order:
     - Blocking issues (breaks, security)
     - Simple fixes (typos, imports)
     - Complex fixes (refactoring, logic)
  3. Test each fix individually
  4. Verify no regressions
  5. After verification, commit review-response work:
     - If this is an already-pushed or reviewed PR branch, use a follow-up commit and plain push
     - If the branch has not been pushed or reviewed, local cleanup is allowed

PR Branch Commit Continuity

Preserve review continuity. Once a PR branch has already been pushed or review has started, use normal follow-up commits and a plain push by default.

Pre-push local cleanup is allowed. Before a branch is pushed or reviewed, you may amend, squash, rebase, or otherwise clean local history according to the repo's normal workflow.

For an already-pushed or reviewed PR branch:

• Use normal follow-up commits for review-response fixes.
• Use a plain push after verification.
• Do not amend already-pushed commits by default.
• Do not force-push by default.
• Amend or force-push only when the user explicitly asks for cleanup/squash, or when the repository workflow explicitly requires rewritten history.

Why: reviewers need stable history and review continuity. Rewriting a reviewed branch can hide what changed since the last review, invalidate comment context, or make incremental review harder.

Examples:

Acceptable pre-push cleanup:
  You fix local review nits before opening or updating a PR for the first time.
  You amend the local commit, then push the cleaned branch.

Incorrect post-review rewrite:
  A reviewer comments on an already-pushed PR branch.
  You fix it with `git commit --amend` and `git push --force`.

Correct post-review response:
  A reviewer comments on an already-pushed PR branch.
  You fix it with a follow-up commit and `git push`.

Pre-Push Review Gate

Before any push, GitHub reply, GitHub resolve, or GitHub comment side effect for review-response work, stop at the Pre-Push Review Gate and wait for explicit approval unless an active owning workflow already has an approved posting gate that covers the same side effects.

The gate summary must include:

• Local changes since the review-response work began, including follow-up commit SHA when a commit exists.
• Verification run and result, including regression coverage or a clear reason no code change was needed.
• Thread disposition for each concern: behavioral fix, no-code explanation, stale/invalid/already-addressed, unresolved, or needs clarification.
• Intended external actions, such as push, in-thread reply, top-level PR comment, thread resolution, or leaving a thread unresolved.

Do not treat "push it", "respond", or "looks good" as permission to skip this gate when the workflow has not yet seen the local-state, verification, and intended-action summary. After approval, perform only the listed side effects; new side effects require another gate summary.

Pushed-Fix and Outcome Thread Closure

Use this closeout sequence only after current classification and the applicable selected outcome confirm a GitHub reply or closure on an already-pushed or reviewed PR branch.

Applicable outcomes:

• Inline execution - an already-authorized inline fix.
• Planned execution after executor returns - the returned fix evidence.
• No-code response - an evidence-backed explanation.

1. Verify the current review comments, current classification, and applicable selected outcome.
2. For inline execution, implement the already-authorized inline fix. For planned execution after executor returns, use the returned fix evidence. For a no-code response, prepare the explanation.
3. Run the relevant checks for the selected outcome.
4. When the selected outcome changes code, commit the response work with a follow-up commit when the branch is already pushed or reviewed.
5. Run the Pre-Push Review Gate before push, reply, resolve, or comment side effects.
6. When the selected outcome requires a push, push normally only after the gate approves that push.
7. Re-fetch PR review thread state after any intended push, or immediately before a no-code reply, and before any reply.
8. Confirm GitHub writes are permitted by explicit user approval or the active workflow's approved posting gate.
9. Reply in-thread with concise fix or explanation evidence.
10. Re-fetch PR review thread state again after the reply and immediately before any resolution. Re-fetch authorship/ownership after the reply and immediately before any resolution in that same current state so resolution is based on the latest reviewer identity or ownership, not on stale pre-reply metadata.
11. Resolve only eligible threads.

Safe-to-resolve criteria:

Permission to reply is not permission to resolve. Posting fix or no-code evidence after GitHub write approval only authorizes the reply; resolving the thread requires the separate eligibility gate below.

• GitHub writes are permitted by explicit user approval or the active workflow's approved posting gate.
• The latest fetched thread after the reply is still unresolved.
• The current post-reply fetched thread state identifies reviewer identity or ownership clearly enough to classify the thread as human-authored, bot-authored, or self-authored.
• The thread maps to the same concern that you verified and addressed.
• The pushed branch contains the fix, the in-thread reply carries returned correction evidence, or it explains an explicit no-code disposition that proves no code change is required.
• An adjacent independently releasable defect handoff alone is not resolution evidence; resolution requires returned correction evidence, an actual branch fix, or that explicit no-code disposition.
• For outdated unresolved threads, current code and current thread state show the underlying concern is stale, invalid, already addressed, or fully addressed by pushed or replied evidence.
• The post-reply refetch still maps the thread to the same concern and does not show new disagreement, new reviewer feedback, unclear ownership, or a newer conflicting state.
• The relevant checks have passed.
• The current actor has permission to resolve the thread.
• Human-authored review threads are eligible only with explicit current-list resolve approval, reviewer confirmation that the concern is addressed, or explicit repository policy delegation for resolving human-authored review threads.
• Bot-authored and self-authored review threads remain eligible for resolution under the Safe-to-resolve criteria when every other criterion passes.
• Replying or resolving does not bypass pr-review's user-gated posting/resolution workflow when that workflow is the active owner.

Edge dispositions:

• Explanation-only comments get an in-thread reply, then resolution only when the reply fully addresses the concern and the post-reply fetched thread is still unresolved.
• Human-authored review threads stay unresolved by default after fix or no-code replies unless explicit current-list resolve approval, reviewer confirmation, or explicit repository policy delegation exists.
• Stale or outdated threads are not resolved merely because they are outdated. Re-fetch current thread state, verify the underlying concern first, confirm pushed or replied evidence addresses that same concern, re-fetch after the reply, and apply the normal Safe-to-resolve criteria.
• Already-resolved threads are left alone. Do not add duplicate replies unless new information is needed.
• Unclear ownership stays unresolved and is reported to the user.
• Threads with unclear, partially fixed, or newly conflicting feedback stay unresolved and are reported to the user.

When To Push Back

Push back when:

• Suggestion breaks existing functionality
• Reviewer lacks full context
• Violates YAGNI (unused feature)
• Technically incorrect for this stack
• Legacy/compatibility reasons exist
• Conflicts with the user's architectural decisions

How to push back:

• Use technical reasoning, not defensiveness
• Ask specific questions
• Reference working tests/code
• Involve the user if architectural

Signal if uncomfortable pushing back out loud: "Strange things are afoot at the Circle K"

Acknowledging Correct Feedback

When feedback IS correct, state the fix and where it landed, or state the authorized outcome and show it in the code. ANY gratitude expression is forbidden. Approved and forbidden phrasings: examples/response-phrasing.md.

Why no thanks: Actions speak. State the authorized outcome. The code itself shows you heard the feedback.

If you catch yourself about to write "Thanks": DELETE IT. State the fix instead.

Gracefully Correcting Your Pushback

If you pushed back and were wrong, say what you checked, what the code actually does, and that you will follow the selected mode. No long apology, no defending why you pushed back, no over-explaining. Sample phrasings: examples/response-phrasing.md.

State the correction factually and move on.

Common Mistakes

Worked bad/good response pairs for these mistakes: examples/response-phrasing.md.

GitHub Thread Replies

Before replying or closeout, confirm the current classification and applicable selected outcome. When replying to inline review comments on GitHub, reply in the comment thread ({{tool:github-cli}} api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.

Reference the follow-up commit or fix in that reply while preserving the existing thread context. When a follow-up commit exists, include its commit SHA. Each reply should state the behavioral fix or no-code disposition; include regression coverage or reason no code change was needed and a concise verification summary. Because replies are shared comments, apply the Agent-Local Evidence Reuse Boundary in docs/specs/afds-workflow-routing.md. Do not include raw .ephemeral paths, transcripts, prompts, logs, validation-log dumps, stack traces, internal decision trails, or session chronology. Follow Pushed-Fix and Outcome Thread Closure before resolving any thread. Do not resolve continuity by replacing reviewed history unless the user explicitly asked for that cleanup or the repository workflow requires rewritten history.

Issue Batch Routing Reports

When invoked by issue-batch-routing or an owning workflow, this workflow produces issue-batch-routing reports for review-response plan approval gates, pre-push approval gates, PR-update or review-response closeout blockers, pushed head and verification result reports, and review-thread disposition reports.

Every report should include the source provider, source issue identifier, current feedback-source state, delegated owner-thread identity when known, branch, PR provider and identifier, head SHA, gate kind, relevant complete review-response route key, blocking evidence, intended or completed external actions, thread disposition, verification result, requested parent action, and next safe command or workflow.

Reports that name only a source issue or PR identity without provider-tagged source identity are incomplete for mixed-batch reconciliation; the router or owning workflow should wait or request manual action instead of accepting PR-only disposition.

This workflow does not own merge, source-issue status mutation, or generic CI repair outside review-response scope. Those cases become parent/manual-action reports or routes to the workflow that owns the specific gate.

The Bottom Line

External feedback = suggestions to evaluate, not orders to follow.

Verify. Question. Classify. Select a mode. Then execute.

No performative agreement. Technical rigor always.