{"id":"c49d7aeb-fbb8-4c54-9b0d-d16d8c8a5182","entityType":"agent","slug":"clawhub-drumrobot-consolidate","name":"consolidate","canonicalUrl":"https://www.xpersona.co/agent/clawhub-drumrobot-consolidate","canonicalPath":"/agent/clawhub-drumrobot-consolidate","generatedAt":"2026-10-09T18:09:40.031Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T12:30:38.837Z","emptyReason":null},"description":"Consolidate and respond to external feedback on PRs/issues. Topics — pr (workflow entrypoint + skip conditions), collect (gather AI reviews + superpowers load), internal (Internal Code Review fallback + UI capture), classify (dual-label Type|Severity + diff scope check), decide (user decision: findings + Formal Review), post (Summary + Formal Review + status + deferred), next (post-summary next-action ask). Use when: \"review consolidate\", \"PR review\", \"AI review\", \"CodeRabbit review\", \"Copilot review\", \"review check\", \"review summary\", \"merge ready\", \"internal review\", \"code-reviewer\", \"inline review\", \"line-level comment\", \"PR line review\".","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 2.7K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17ay1v6v88r2m102pvvc44gz183qcrm:consolidate","sourceUrl":"https://clawhub.ai/drumrobot/consolidate","homepage":"https://clawhub.ai/drumrobot/skills/consolidate","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/drumrobot/consolidate","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/drumrobot/skills/consolidate","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":68,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"consolidate technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T12:30:38.837Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T12:30:38.837Z","emptyReason":null},"stars":null,"forks":null,"downloads":2650,"packageName":null,"latestVersion":"0.8.0","tractionLabel":"2.7K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T12:30:38.808Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T12:30:38.837Z","lastCrawledAt":"2026-10-09T12:30:38.808Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T12:30:38.808Z","lastVerifiedAt":null,"highlights":[{"version":"0.8.0","createdAt":"2026-10-09T10:54:06.573Z","changelog":"Version 0.8.0 - Added resources/block-review-post-without-receiving-code-review.sh file. - Updated CHANGELOG.md, SKILL.md, and collect.md with workflow or documentation changes. - Removed obsolete skill-card.md file. - Documentation and flow have minor refinements and clarifications for interactive and post logic.","fileCount":21,"zipByteSize":125473},{"version":"0.7.1","createdAt":"2026-10-06T07:56:18.536Z","changelog":"consolidate v0.7.1 - Documentation updates and corrections across multiple guides (CHANGELOG.md, SKILL.md, classify.md, post.md) - Removed deprecated or redundant file: skill-card.md - No behavioral or functional changes; this is a documentation and maintenance release","fileCount":20,"zipByteSize":122758},{"version":"0.7.0","createdAt":"2026-09-30T14:21:07.268Z","changelog":"**Version 0.7.0** - Enforced that the AI Review Summary comment must be physically POSTed or PATCHed on the PR before declaring consolidation or merge (HARD STOP). - Updated the interactive mode logic to always trigger Steps 3 (collect.md) and 3.5 (internal.md), even when using local/CLI review tools. - Clarified that interactive mode, once auto-activated, applies to all POST steps in the consolidate run. - Improved documentation, especially contract details for interactive mode and new requirements around PR comment posting. - Removed obsolete file: skill-card.md.","fileCount":20,"zipByteSize":122282},{"version":"0.6.5","createdAt":"2026-09-20T11:23:09.529Z","changelog":"consolidate v0.6.5 - Added resources/block-consolidate-verify-format-mismatch.py for enhanced formatting verification. - Updated documentation in CHANGELOG.md, SKILL.md, and internal.md. - Removed obsolete skill-card.md file. - Incremented version to 0.6.5 in metadata.","fileCount":20,"zipByteSize":114841},{"version":"0.6.4","createdAt":"2026-09-18T15:53:13.414Z","changelog":"consolidate 0.6.4 - Version bump to 0.6.4. - Documentation updates to SKILL.md, CHANGELOG.md, internal.md, and pr.md. - Removed legacy file skill-card.md. - Minor clarifications and maintenance updates across topic and contract descriptions.","fileCount":19,"zipByteSize":110025},{"version":"0.6.3","createdAt":"2026-09-05T15:54:16.195Z","changelog":"consolidate 0.6.3 - Added resources/block-summary-status-vocab.py to support status vocabulary mapping. - Updated documentation in SKILL.md and CHANGELOG.md for improved clarity. - Enhanced post.md and scripts/verify_consolidate.py with additional logic and refinements. - Removed obsolete skill-card.md for consistency.","fileCount":19,"zipByteSize":106634},{"version":"0.6.2","createdAt":"2026-09-01T22:37:52.351Z","changelog":"consolidate 0.6.2 - Updated version metadata to 0.6.2. - Documentation and Markdown cleanup in SKILL.md; minor adjustments only. - Removed obsolete skill-card.md file. - Minor changes to scripts/verify_consolidate.py (details not shown). - No major behavioral or workflow changes introduced.","fileCount":18,"zipByteSize":100833},{"version":"0.6.1","createdAt":"2026-08-26T17:25:46.790Z","changelog":"Version 0.6.1 - Added block-summary-fabricated-claims.sh for enhanced resource management. - Updated documentation in SKILL.md, CHANGELOG.md, and post.md for workflow and usage clarity. - Removed deprecated skill-card.md file. - Minor improvements to interactive flow and edge case documentation.","fileCount":18,"zipByteSize":99304}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17ay1v6v88r2m102pvvc44gz183qcrm:consolidate","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s17ay1v6v88r2m102pvvc44gz183qcrm:consolidate` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/drumrobot/consolidate before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-09T18:09:40.025Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-consolidate/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T12:30:38.837Z","emptyReason":null},"readme":"Skill: consolidate\n\nOwner: drumrobot\n\nSummary: Consolidate and respond to external feedback on PRs/issues. Topics — pr (workflow entrypoint + skip conditions), collect (gather AI reviews + superpowers load), internal (Internal Code Review fallback + UI capture), classify (dual-label Type|Severity + diff scope check), decide (user decision: findings + Formal Review), post (Summary + Formal Review + status + deferred), next (post-summary next-action ask). Use when: \"review consolidate\", \"PR review\", \"AI review\", \"CodeRabbit review\", \"Copilot review\", \"review check\", \"review summary\", \"merge ready\", \"internal review\", \"code-reviewer\", \"inline review\", \"line-level comment\", \"PR line review\".\n\nTags: latest:0.8.0\n\nVersion history:\n\nv0.8.0 | 2026-10-09T10:54:06.573Z | auto\n\nVersion 0.8.0\n\n- Added resources/block-review-post-without-receiving-code-review.sh file.\n- Updated CHANGELOG.md, SKILL.md, and collect.md with workflow or documentation changes.\n- Removed obsolete skill-card.md file.\n- Documentation and flow have minor refinements and clarifications for interactive and post logic.\n\nv0.7.1 | 2026-10-06T07:56:18.536Z | auto\n\nconsolidate v0.7.1\n\n- Documentation updates and corrections across multiple guides (CHANGELOG.md, SKILL.md, classify.md, post.md)\n- Removed deprecated or redundant file: skill-card.md\n- No behavioral or functional changes; this is a documentation and maintenance release\n\nv0.7.0 | 2026-09-30T14:21:07.268Z | auto\n\n**Version 0.7.0**\n\n- Enforced that the AI Review Summary comment must be physically POSTed or PATCHed on the PR before declaring consolidation or merge (HARD STOP).\n- Updated the interactive mode logic to always trigger Steps 3 (collect.md) and 3.5 (internal.md), even when using local/CLI review tools.\n- Clarified that interactive mode, once auto-activated, applies to all POST steps in the consolidate run.\n- Improved documentation, especially contract details for interactive mode and new requirements around PR comment posting.\n- Removed obsolete file: skill-card.md.\n\nv0.6.5 | 2026-09-20T11:23:09.529Z | auto\n\nconsolidate v0.6.5\n\n- Added resources/block-consolidate-verify-format-mismatch.py for enhanced formatting verification.\n- Updated documentation in CHANGELOG.md, SKILL.md, and internal.md.\n- Removed obsolete skill-card.md file.\n- Incremented version to 0.6.5 in metadata.\n\nv0.6.4 | 2026-09-18T15:53:13.414Z | auto\n\nconsolidate 0.6.4\n\n- Version bump to 0.6.4.\n- Documentation updates to SKILL.md, CHANGELOG.md, internal.md, and pr.md.\n- Removed legacy file skill-card.md.\n- Minor clarifications and maintenance updates across topic and contract descriptions.\n\nv0.6.3 | 2026-09-05T15:54:16.195Z | auto\n\nconsolidate 0.6.3\n\n- Added resources/block-summary-status-vocab.py to support status vocabulary mapping.\n- Updated documentation in SKILL.md and CHANGELOG.md for improved clarity.\n- Enhanced post.md and scripts/verify_consolidate.py with additional logic and refinements.\n- Removed obsolete skill-card.md for consistency.\n\nv0.6.2 | 2026-09-01T22:37:52.351Z | auto\n\nconsolidate 0.6.2\n\n- Updated version metadata to 0.6.2.\n- Documentation and Markdown cleanup in SKILL.md; minor adjustments only.\n- Removed obsolete skill-card.md file.\n- Minor changes to scripts/verify_consolidate.py (details not shown).\n- No major behavioral or workflow changes introduced.\n\nv0.6.1 | 2026-08-26T17:25:46.790Z | auto\n\nVersion 0.6.1\n\n- Added block-summary-fabricated-claims.sh for enhanced resource management.\n- Updated documentation in SKILL.md, CHANGELOG.md, and post.md for workflow and usage clarity.\n- Removed deprecated skill-card.md file.\n- Minor improvements to interactive flow and edge case documentation.\n\nv0.6.0 | 2026-08-21T05:40:49.202Z | auto\n\nVersion 0.6.0\n\n- Added scripts/verify_consolidate.py for new verification or support tooling.\n- Removed deprecated skill-card.md file.\n- Updated SKILL.md, CHANGELOG.md, internal.md, next.md, and post.md for version bump and to reflect new/changed workflows.\n- Improved documentation of interactive mode: clearer contract for review-before-post, edge cases, and auto-activation on intent-matching args.\n- Refined workflow for handling both AI and internal review steps, ensuring sequential processing and response pairing.\n\nv0.5.4 | 2026-08-18T05:41:25.516Z | auto\n\nconsolidate 0.5.4\n\n- Updated SKILL.md to version 0.5.4 with no major workflow or feature changes.\n- Removed the obsolete skill-card.md file.\n- Documentation refreshed for clarity; no functional changes to review flow or topics.\n- Clean-up/reduction of redundant or outdated documentation artifacts.\n\nv0.5.3 | 2026-08-13T07:00:08.912Z | auto\n\nconsolidate skill v0.5.3\n\n- Updated documentation in SKILL.md, CHANGELOG.md, next.md, and post.md.\n- Version bump to 0.5.3.\n- Removed skill-card.md file.\n- No changes to core logic; this release is a documentation and cleanup update.\n\nv0.5.2 | 2026-08-09T14:11:13.691Z | auto\n\n- Added dependency on hook-kit to the consolidate skill.\n- Clarified and enforced the requirement to always route through the `collect` and `internal` steps, even when running local/CLI review tools.\n- Updated interactive auto-activation contract: any match in intent class table now gates all POST steps, including cases triggered by local tools.\n- Removed unused file `skill-card.md`.\n- Minor documentation updates and version bump to 0.5.2.\n\nv0.5.1 | 2026-08-06T09:21:35.247Z | auto\n\nconsolidate v0.5.1\n\n- Maintenance update: removed `skill-card.md` for leaner documentation.\n- Minor internal doc updates across `CHANGELOG.md`, `SKILL.md`, `internal.md`, and `post.md`.\n- No changes to core functionality or user-facing features.\n\nv0.5.0 | 2026-08-04T07:32:45.680Z | auto\n\n- Version bump to 0.5.0\n- Added script: block-noncompliant-review-comment.sh to resources\n- Removed outdated documentation: skill-card.md\n- Updated CHANGELOG and SKILL.md for improved interactive review contract and clarified auto-activation rules\n\nv0.4.0 | 2026-07-23T13:39:16.550Z | auto\n\nVersion 0.4.0\n\n- Added new script files: `resources/block-consolidate-summary-ask.sh`, `scripts/collect.sh`.\n- Removed file: `skill-card.md`.\n- Updated core documentation and workflow guides: `CHANGELOG.md`, `SKILL.md`, `classify.md`, `internal.md`, `post.md`, `pr.md`.\n- Improved or changed handling for PR review, feedback consolidation, internal review fallback, and AI review collection.\n- Enhanced or clarified options and contract for `--interactive` mode in the review and post workflow.\n\nv0.3.6 | 2026-07-19T05:38:58.213Z | auto\n\n- Bumped version to 0.3.6.\n- Updated documentation for `SKILL.md`, `CHANGELOG.md`, `post.md`, and `pr.md`.\n- Removed deprecated file: `skill-card.md`.\n- General documentation updates and refinements for workflow, options, and auto-activation logic.\n\nv0.3.5 | 2026-07-16T12:29:50.988Z | auto\n\n**consolidate v0.3.5**\n\n- Added README.md; removed skill-card.md.\n- Updated docs in SKILL.md and topic guides (collect.md, post.md, pr.md), clarifying workflow and options.\n- Improved descriptions of interactive review flow and auto-activation by intent keywords.\n- Minor reorganization and documentation cleanup throughout.\n- No breaking changes to workflow logic or core behavior.\n\nv0.3.4 | 2026-07-07T19:12:13.686Z | auto\n\nVersion 0.3.4\n\n- Version bump from 0.3.3 to 0.3.4 in SKILL.md.\n- Documentation updates across multiple guides (CHANGELOG.md, SKILL.md, classify.md, collect.md, decide.md, internal.md, post.md, pr.md).\n- No changes to workflow logic or options observed—documentation and metadata only.\n- Keeps behavior, options, and integration points unchanged.\n\nv0.3.3 | 2026-07-04T07:20:41.596Z | auto\n\nconsolidate v0.3.3\n\n- Version bump from 0.3.2 to 0.3.3.\n- Documentation updated in SKILL.md, CHANGELOG.md, and internal.md—no functional or behavioral changes to code.\n- Maintains sync between metadata and documentation for released version.\n\nv0.3.2 | 2026-06-26T16:24:06.870Z | auto\n\nVersion 0.3.2\n\n- Updated SKILL.md to bump version to 0.3.2 and remove references to the deleted file.\n- Removed skill-card.md, cleaning up unused documentation.\n- Minor updates in topic files (classify.md, next.md, post.md) for consistency with recent workflow or documentation changes.\n- CHANGELOG.md updated to capture these maintenance and documentation edits.\n\nv0.3.1 | 2026-06-19T23:10:37.415Z | auto\n\n**Added interactive review mode and intent-based activation.**\n\n- Introduced `--interactive` option: pauses for user review before each POST (Internal Review, Summary), enabling draft approval or edits.\n- Auto-activates interactive mode if caller args express an intent to review drafts before posting, with clear chat acknowledgement.\n- Documented intent classes (e.g., “review first”, “let me check”) that trigger interactive flow.\n- Clarified behavior for multiple artifacts, mid-flow activation, and edge cases.\n- Now depends on `github-flow` (in addition to `git-repo` and `superpowers`).\n- Removed legacy skill-card.md.\n\nv0.3.0 | 2026-06-12T15:36:33.255Z | auto\n\n- Bumped version to 0.3.0.\n- Updated documentation in SKILL.md, CHANGELOG.md, and next.md.\n- Removed obsolete skill-card.md file.\n\nv0.2.2 | 2026-06-11T14:36:45.926Z | auto\n\n- Added Copilot availability pre-check (Step 2.4) with automatic fallback to Internal Review if unavailable (no user prompt).\n- Expanded internal review process: decides between posting inline review comments or an issue comment based on findings.\n- Refined PR workflow steps and execution order for greater clarity.\n- Removed outdated skill-card documentation.\n\nv0.2.1 | 2026-05-27T10:08:12.063Z | auto\n\n**Summary: Adds worktree checkout to review process, updates workflow steps, and introduces new dependencies.**\n\n- Introduced mandatory worktree checkout (Step 2.7) for PR reviews to ensure accurate file states and line numbers.\n- Expanded and clarified PR review workflow steps, adding explicit re-review triggers and branching logic.\n- Declared a dependency on the git-repo skill for managing worktrees.\n- Added CHANGELOG.md and LICENSE files to the repository. \n- Updated documentation to reflect new steps and dependencies.\n\nv0.1.1 | 2026-05-22T07:35:55.691Z | user\n\n7-topic split + Mergeable unified Formal Review POST + UI capture verification + deferred registration.\n\nv0.1.0 | 2026-04-15T08:24:02.300Z | user\n\nInitial release: PR review consolidation for AI bot feedback (CodeRabbit, Copilot)\n\nArchive index:\n\nArchive v0.8.0: 21 files, 125473 bytes\n\nFiles: CHANGELOG.md (18173b), classify.md (16075b), collect.md (6245b), decide.md (20853b), internal.md (42582b), LICENSE (1063b), next.md (28566b), post.md (74764b), pr.md (41792b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-consolidate-verify-format-mismatch.py (10650b), resources/block-noncompliant-review-comment.sh (5426b), resources/block-review-post-without-receiving-code-review.sh (5919b), resources/block-summary-fabricated-claims.sh (8190b), resources/block-summary-status-vocab.py (9891b), scripts/collect.sh (3463b), scripts/verify_consolidate.py (23358b), skill-card.md (2059b), SKILL.md (8493b), _meta.json (130b)\n\nFile v0.8.0:SKILL.md\n\n---\nname: consolidate\ndepends-on: [git-repo, github-flow, hook-kit, superpowers]\nmetadata:\n author: es6kr\n version: \"0.8.0\" # x-release-please-version\ndescription: |\n Consolidate and respond to external feedback on PRs/issues. Topics —\n pr (workflow entrypoint + skip conditions),\n collect (gather AI reviews + superpowers load),\n internal (Internal Code Review fallback + UI capture),\n classify (dual-label Type|Severity + diff scope check),\n decide (user decision: findings + Formal Review),\n post (Summary + Formal Review + status + deferred),\n next (post-summary next-action ask).\n Use when: \"review consolidate\", \"PR review\", \"AI review\", \"CodeRabbit review\", \"Copilot review\",\n \"review check\", \"review summary\", \"merge ready\", \"internal review\", \"code-reviewer\",\n \"inline review\", \"line-level comment\", \"PR line review\".\nallowed-tools: [Agent, AskUserQuestion, Bash, Edit, Glob, Grep, Read, Write]\n---\n\n# Consolidate\n\nConsolidate and respond to external feedback on PRs and issues.\n\n## Options\n\n| Flag | Default | Behavior |\n|------|---------|----------|\n| `--interactive` | off | Before each POST (Internal Review at Step 3.5.3 / Summary at Step 7), pause and `AskUserQuestion` the drafted body to the user. User can approve, request edits, or reject. Edits applied → re-ask. Reject → abort POST for that artifact. |\n\n### Auto-activation by args keywords (HARD STOP)\n\nWhen the consolidate caller passes args containing any of the following intent classes (any language — match by meaning, not literal token), **treat `--interactive` as implicitly set** even if the flag was not literal. The keyword expresses the user's intent for review-before-post.\n\n| Intent class | Match signal |\n|--------------|--------------|\n| Explicit review request | Phrases requesting review of the draft before publishing — \"review first\", \"review before post\", \"review the draft\", localized equivalents (e.g., the Korean phrase meaning \"review needed\" / \"after review\") |\n| Interactive mode request | Words like `interactive` (any language transliteration), or phrases meaning \"conversational mode\" / \"step-by-step ask\" |\n| \"Important decision ask\" intent | Phrases stating that important decisions / important parts must be asked — e.g., \"ask important parts\", \"ask the key decisions\", localized equivalents |\n| Author-style review request | Phrases stating the user wants to see / review the artifact themselves — \"let me review\", \"let me see the draft\", \"after I check\" |\n\nWhen auto-activation fires, the caller MUST emit a one-line acknowledgement in chat before the first ask:\n\n```\nInteractive mode auto-activated by caller args (intent: ) — drafts will be reviewed before POST.\n```\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Treat args keyword as flavor text and continue deterministic POST | Match against the intent-class table above. On any match, enable `--interactive` for the entire workflow |\n| 2 | Activate interactive only for the matched step (e.g., only the Summary) | Once activated, applies to ALL POST steps in this consolidate run (Internal Review + Summary + any inline edits). One match → all-step gating |\n| 3 | Silent activation without chat acknowledgement | Emit the one-liner above so the user can confirm the intent was caught |\n| 4 | Map \"important decision ask\" only to scope-decision axes (Step 5 Axis B / Step 8 next-action) | Body content of Internal Review / Summary is an \"important decision\" too — every POSTed artifact is subject to review-before-post |\n| 5 | Directly running a local/CLI review tool (e.g., CodeRabbit CLI) and skipping the sequential topics of the `consolidate` skill (collect -> internal -> classify) | Even when running local CLI tools, always route through the `collect.md` and `internal.md` steps to ensure that the Internal Code Review comments and AI Review Summary are always posted as a pair |\n| 6 | Declaring consolidation completed or proceeding to PR merge without physically POSTing the AI Review Summary comment on GitHub (`gh pr comment` / `gh api POST`) | Must physically execute Step 7 (`post.md`) to POST or PATCH the AI Review Summary comment on the PR on GitHub before declaring consolidation complete or offering merge (HARD STOP) |\n\n### Interactive flow contract\n\nWhen `--interactive` is on (literal or auto-activated), each artifact POST follows this contract:\n\n1. **Draft** — author the body into `.tmp/-draft.md` (per `file-operations.md` `.tmp/` policy)\n2. **Present** — emit a chat summary of the draft (key sections, finding count, verdict line) + the `.tmp/` path\n3. **Ask** — `AskUserQuestion` with options:\n - `Approve as-is` — POST immediately\n - `Edit (specify in Other)` — capture user edits → apply via Edit → re-present → re-ask\n - `Reject — do not POST` — skip POST for this artifact, record skip reason in chat\n4. **POST** — only after Approve. Use existing medium decision (deterministic) for the POST mechanics.\n\n### Edge cases\n\n- **Already POSTed before interactive auto-activation realized**: see post.md \"Damage control — Summary already posted in wrong medium\" — content can be PATCHed in place. After `--interactive` auto-detection mid-flow, the caller asks the user whether to PATCH the already-posted artifacts with reviewed content.\n- **Multiple artifacts in one consolidate run** (Internal Review + Summary): ask each separately; do not bundle the two drafts into one ask.\n- **`--interactive` + `--inline` together**: inline annotation bodies are part of the Internal Review draft; review them in the same ask.\n\n## Topics\n\n| Topic | Description | Guide |\n|-------|-------------|-------|\n| classify | Step 4 Analyze and Classify (dual-label Type \\| Severity, PR scope cross-check) | [classify.md](./classify.md) |\n| collect | Step 3 Collect AI Reviews + Step 3.6 superpowers framework load | [collect.md](./collect.md) |\n| decide | Step 5 User Decision (Axis A/B) + Step 6 Fix or Reject | [decide.md](./decide.md) |\n| internal | Step 3.5 Internal Code Review Fallback (medium: review POST w/ inline when line-specific findings exist, else issue comment) + Step 4.5 UI capture verification | [internal.md](./internal.md) |\n| next | Step 8 Post-Summary Next-Action Ask | [next.md](./next.md) |\n| post | Step 7 Post Summary + Formal Review (unified vs separate) + Step 7.5 Status + Step 7.6 Deferred registration | [post.md](./post.md) |\n| pr | Workflow entrypoint — PR identify, skip conditions, Copilot availability pre-check (auto-fallback, no ask), Copilot sequential, worktree checkout, Rules | [pr.md](./pr.md) |\n\n## Topic Dependencies\n\n```\npr (entry: identify → skip → worktree checkout)\n └─→ git-repo/worktree (Step 2.7: check out PR branch into a worktree — all review runs against real files)\ncollect → internal (code-reviewer dispatch operates in the Step 2.7 worktree)\n```\n\n- Step 2.7 worktree checkout runs on every review (after skip conditions) so the code-reviewer reads real files, CONFLICTING is detected locally, and inline line numbers match HEAD.\n\n## Quick Reference\n\n### PR Review Workflow\n\nReview CodeRabbit/Copilot feedback on a PR, decide what to act on, and post an AI Review Summary comment.\n\nEntry: [`pr.md`](./pr.md) (Workflow index + Step 1, 2, 2.4, 2.5, 2.6, 2.7 + Rules)\n\nStep execution order:\n1. **`pr.md`** Step 1 (Identify PR) + Step 2 (Skip Conditions) + **Step 2.4 (Copilot availability pre-check — auto-fallback to Internal Review on unavailable, no ask)** + Step 2.5 (Copilot sequential, multi-PR only — skipped on unavailable) + Step 2.6 (re-review trigger policy — first vs re-review) + Step 2.7 (checkout PR branch into a worktree — MANDATORY, all reviews)\n2. **`collect.md`** Step 3 (Collect AI Reviews) + Step 3.6 (superpowers framework)\n3. **`internal.md`** Step 3.5 (Internal Review Fallback, walkthrough only / on failure — medium decision: inline targets (Critical+Important line-specific; `--inline` = all) → single review POST (body = findings + comments[] = inline, re-review = new POST); no inline targets → issue comment (re-review = PATCH)) + Step 4.5 (UI capture verification)\n4. **`classify.md`** Step 4 (Analyze and Classify)\n5. **`decide.md`** Step 5 (Formal Review Decision — Axis B only) + Step 6 (Fix or Reject — only on explicit user instruction)\n6. **`post.md`** Step 7 (Post Summary + Formal Review) + Step 7.5 (Status line) + Step 7.6 (Deferred registration)\n7. **`next.md`** Step 8 (Post-Summary Next-Action Ask)\n\nFile v0.8.0:README.md\n\n# consolidate\n\nConsolidate and respond to external PR/issue feedback — gather AI reviews (CodeRabbit, Copilot), classify findings by type and severity, post an AI Review Summary and Formal Review, then register deferred items.\n\n## Installation\n\n```bash\nnpx skills add es6kr/skills --skill consolidate\n```\n\nBrowse on ClawHub: \n\n### Peer skills\n\n`consolidate` depends on `git-repo` and `github-flow`. Install them so all flows work:\n\n```bash\nnpx skills add es6kr/skills --skill git-repo --skill github-flow\n```\n\nIt also uses the [`superpowers`](https://github.com/obra/superpowers) plugin for its code-review primitives. Install either the specific skills or the full plugin:\n\n```bash\n# Option 1 — just the code-review skills\nnpx skills add obra/superpowers --skill requesting-code-review --skill receiving-code-review\n\n# Option 2 — the full superpowers plugin (covers the whole dependency tree)\nnpx skills add obra/superpowers\n```\n\n## Usage\n\nInvoke with `/consolidate ` (for example `/consolidate pr `). See [`SKILL.md`](./SKILL.md) for the full topic list and workflow.\n\nFile v0.8.0:_meta.json\n\n{\n \"ownerId\": \"kn74k8yfvftx6f062qa8fzyd8h8373jd\",\n \"slug\": \"consolidate\",\n \"version\": \"0.8.0\",\n \"publishedAt\": 1791543246573\n}\n\nFile v0.8.0:CHANGELOG.md\n\n# Changelog\n\n## [0.8.0](https://github.com/es6kr/skills/compare/consolidate-v0.7.1...consolidate-v0.8.0) (2026-10-06)\n\n\n### Features\n\n* **hook-kit:** declarative step-dependency enforcement engine ([9e3d188](https://github.com/es6kr/skills/commit/9e3d18898453d20a947b74b24032e61bf13bc297))\n\n## [0.7.1](https://github.com/es6kr/skills/compare/consolidate-v0.7.0...consolidate-v0.7.1) (2026-10-04)\n\n\n### Bug Fixes\n\n* **consolidate:** unify Source, Type, and Severity into a single 3-line column ([#603](https://github.com/es6kr/skills/issues/603)) ([c4ef164](https://github.com/es6kr/skills/commit/c4ef16457eaedcdac22dc7ab74fcb0d3cbf6a276))\n* **hooks:** verify executable hook registrations ([1bd613a](https://github.com/es6kr/skills/commit/1bd613aba2aa5cb2509f3dacd53acc5eab3cbf3f))\n\n## [0.7.0](https://github.com/es6kr/skills/compare/consolidate-v0.6.5...consolidate-v0.7.0) (2026-09-30)\n\n\n### Features\n\n* **fix-plan, consolidate:** consolidate task coordination, review collection, and docs ([d6162d8](https://github.com/es6kr/skills/commit/d6162d8d25bb80c85aa2c5cd475afdf0ee638535))\n\n\n### Bug Fixes\n\n* **consolidate:** accept an engine-named Code Review in the provenance gate ([dbb93fb](https://github.com/es6kr/skills/commit/dbb93fb0c329e6efaa9ea1257058ef4455c4085c))\n* **consolidate:** enhance review collection, PATCH verification, and harness check ([858adef](https://github.com/es6kr/skills/commit/858adef07f212f09e550be77c7fc89cfd229e9fe))\n* **consolidate:** make the dispatch-failure history select the starting rung ([17637c3](https://github.com/es6kr/skills/commit/17637c303d26aed4af95514af44d527e7076e422))\n* **consolidate:** reconcile the two-comment invariant across pr/internal/post ([1e17091](https://github.com/es6kr/skills/commit/1e170913e104711bc124008a632360cc59c0f05d))\n* **consolidate:** reconcile the two-comment invariant and the provenance gate ([28d2f9a](https://github.com/es6kr/skills/commit/28d2f9a399e28342ef16cc9244279c85ec75bf39))\n* **consolidate:** Step 8 finding-handling ask must reuse posted Status column ([#561](https://github.com/es6kr/skills/issues/561)) ([2d310e3](https://github.com/es6kr/skills/commit/2d310e3cc51d4b28d711973c27bc94e4abae9d2e))\n\n## [0.6.5](https://github.com/es6kr/skills/compare/consolidate-v0.6.4...consolidate-v0.6.5) (2026-09-20)\n\n\n### Bug Fixes\n\n* address code review feedback ([0c08bfb](https://github.com/es6kr/skills/commit/0c08bfbf2b5b737fdce685c8f15ead56c64290f4))\n* **consolidate:** drop requesting-code-review suffix when bot-layer content is mixed in ([#498](https://github.com/es6kr/skills/issues/498)) ([66fb1be](https://github.com/es6kr/skills/commit/66fb1bedc768544415a808b2d33d96feeee0a3ea))\n* **consolidate:** guard verify_consolidate.py format contract at POST time ([#500](https://github.com/es6kr/skills/issues/500)) ([941023a](https://github.com/es6kr/skills/commit/941023a5fb36becfdc484017b8cde128078f07a9))\n\n## [0.6.4](https://github.com/es6kr/skills/compare/consolidate-v0.6.3...consolidate-v0.6.4) (2026-09-18)\n\n\n### Bug Fixes\n\n* **cleanup:** make the session-end report table self-sufficient ([#487](https://github.com/es6kr/skills/issues/487)) ([c4a0255](https://github.com/es6kr/skills/commit/c4a02557fb8de3b32cf337c549f62535dabf824b))\n* **consolidate:** count every finding source in verify_consolidate ([f12825a](https://github.com/es6kr/skills/commit/f12825aa4dc186fc6d4529d6f62fbfde524573f1))\n* **consolidate:** count every finding source in verify_consolidate ([2860dd0](https://github.com/es6kr/skills/commit/2860dd0c9dc8837d26c660da9b5ec6687fc4f80e))\n* **consolidate:** make the Workflow Index a traversal gate, not a reading suggestion ([#482](https://github.com/es6kr/skills/issues/482)) ([2d7bbad](https://github.com/es6kr/skills/commit/2d7bbada5775ed090e61ae9af171fa3e37d2de45))\n* **consolidate:** resolve git cat-file against -R repo instead of process cwd ([049614d](https://github.com/es6kr/skills/commit/049614d4c9213356250ccdc096c8ff38140d0e29))\n* **skills:** document canonical Do/Don't tables for Plane URLs, plan sync, and pre-merge reviews ([7069da8](https://github.com/es6kr/skills/commit/7069da85bb11bdcf0da8d9dc93619eeafc972dd2))\n\n## [0.6.3](https://github.com/es6kr/skills/compare/consolidate-v0.6.2...consolidate-v0.6.3) (2026-09-05)\n\n\n### Bug Fixes\n\n* **consolidate:** enforce the Summary Status vocabulary at post time and in verify ([18c07c3](https://github.com/es6kr/skills/commit/18c07c3b7c6df058d497c6c2d17771c6a1a781eb))\n* **fix-plan:** add simple-vs-session self-check before Orca recommendation ask ([46e5d77](https://github.com/es6kr/skills/commit/46e5d77e3faefb0524fb4e4e6e80aa056d2d66ca))\n\n## [0.6.2](https://github.com/es6kr/skills/compare/consolidate-v0.6.1...consolidate-v0.6.2) (2026-09-01)\n\n\n### Bug Fixes\n\n* **consolidate:** identify review artifacts by title line, not whole-body substring ([#397](https://github.com/es6kr/skills/issues/397)) ([8143da7](https://github.com/es6kr/skills/commit/8143da79baff109325d4e187d5ef4d67b6fe213d))\n* staging branch next-fix sync into main ([bbbd460](https://github.com/es6kr/skills/commit/bbbd460bf3b6b1cba4c6d07b3641afa734c89860))\n\n## [0.6.1](https://github.com/es6kr/skills/compare/consolidate-v0.6.0...consolidate-v0.6.1) (2026-08-26)\n\n\n### Bug Fixes\n\n* apply PR [#363](https://github.com/es6kr/skills/issues/363) Copilot Minor review findings ([731745c](https://github.com/es6kr/skills/commit/731745c6d67c329c8c6dde666107672282a3894a))\n* **consolidate:** add block-summary-fabricated-claims guard for Summary POST ([e2d054e](https://github.com/es6kr/skills/commit/e2d054edad4cca08307a99ceef927c156903f3e5))\n* promote next-fix batch (consolidate fabrication guard, session rewind, config-driven PR base) ([7ca0ccb](https://github.com/es6kr/skills/commit/7ca0ccbf13cefafedc33a16a7361756c95f8b8f6))\n* resolve PR [#363](https://github.com/es6kr/skills/issues/363) audit Pending findings (plane_bulk_update profile, hook checker schema, regex, dedup) ([19ffc83](https://github.com/es6kr/skills/commit/19ffc83f296ad5568b82a85b104fcf419580c102))\n\n## [0.6.0](https://github.com/es6kr/skills/compare/consolidate-v0.5.4...consolidate-v0.6.0) (2026-08-20)\n\n\n### Features\n\n* promote next-feat batch (hook registry schema, self-reference path anchoring) ([0c33ffa](https://github.com/es6kr/skills/commit/0c33ffac99a9237f4530566470dabeaea128c209))\n* promote next-feat staging (lifecycle guards, triage automation, and workflow safety procedures) ([77d58ac](https://github.com/es6kr/skills/commit/77d58ac3a771a4897043c9eea8b149ea1e8ba2ff))\n\n\n### Bug Fixes\n\n* **consolidate:** refresh the AI Review Summary before the merge ask when findings were fixed ([#348](https://github.com/es6kr/skills/issues/348)) ([9512c9c](https://github.com/es6kr/skills/commit/9512c9cdff7d1a0d2e36a8c70a468e2abca6e977))\n* **hook-kit,fix-plan,consolidate:** resolve review findings on registry fail-fast, add-item safety, and mechanical verification ([72fb280](https://github.com/es6kr/skills/commit/72fb28054ccd858aa56617e8a6a5d1fb5b9d2384))\n* promote next-fix batch (hook path repair, topic-dispatch scoping, conflict diagnosis) ([eb7ecb6](https://github.com/es6kr/skills/commit/eb7ecb61dda9701d78f12dc810781dc7cb687caa))\n\n## [0.5.4](https://github.com/es6kr/skills/compare/consolidate-v0.5.3...consolidate-v0.5.4) (2026-08-17)\n\n\n### Bug Fixes\n\n* **wip:** cross-ref PR-URL and TaskCreate subject repo-qualifier rules ([#186](https://github.com/es6kr/skills/issues/186)) ([4982364](https://github.com/es6kr/skills/commit/49823641a7b08123ebd0325273892bee41bc3280))\n\n## [0.5.3](https://github.com/es6kr/skills/compare/consolidate-v0.5.2...consolidate-v0.5.3) (2026-08-12)\n\n\n### Bug Fixes\n\n* **consolidate:** clarify tracking medium is the session workspace, not the reviewed PR's repo ([435b997](https://github.com/es6kr/skills/commit/435b997fa83072538393576b771efe3846e2da69))\n* **consolidate:** clarify tracking medium is the session workspace, not the reviewed PR's repo ([544bbca](https://github.com/es6kr/skills/commit/544bbca50b15ed22a18441b7848e8b96fa8e4bb1))\n* promote accumulated next-fix fixes to main ([803bbd3](https://github.com/es6kr/skills/commit/803bbd3b9e4f8367ee1b955cfa2b6a536f85cee0))\n\n## [0.5.2](https://github.com/es6kr/skills/compare/consolidate-v0.5.1...consolidate-v0.5.2) (2026-08-09)\n\n\n### Bug Fixes\n\n* **consolidate:** address CodeRabbit/Copilot review findings on PR [#270](https://github.com/es6kr/skills/issues/270) ([3b11a73](https://github.com/es6kr/skills/commit/3b11a730b5ad68803d35a8264eda540e48265d75))\n* **consolidate:** require merge-method precheck before squash-merge option label ([#269](https://github.com/es6kr/skills/issues/269)) ([1830341](https://github.com/es6kr/skills/commit/183034138eab3d72a8ecb1005db91b86797db0ba))\n* declare undeclared skill-to-skill dependencies (7 skills) ([#271](https://github.com/es6kr/skills/issues/271)) ([36a9f9d](https://github.com/es6kr/skills/commit/36a9f9d7c1fac9bb1c4c96b325a067ab92ad0da7))\n* promote accumulated next-fix fixes to main ([95656e9](https://github.com/es6kr/skills/commit/95656e9b551ee0bb77904a0a571d49c53bc01cc9))\n\n## [0.5.1](https://github.com/es6kr/skills/compare/consolidate-v0.5.0...consolidate-v0.5.1) (2026-08-05)\n\n\n### Bug Fixes\n\n* promote next-fix staging (38 fixes across 16 skills) ([94f8c33](https://github.com/es6kr/skills/commit/94f8c33800ce411ae63e22c5259cdae8435508a4))\n\n## [0.5.0](https://github.com/es6kr/skills/compare/consolidate-v0.4.0...consolidate-v0.5.0) (2026-08-03)\n\n\n### Features\n\n* **consolidate:** cross-platform noncompliant-review-comment guard ([#166](https://github.com/es6kr/skills/issues/166)) ([168fb9c](https://github.com/es6kr/skills/commit/168fb9cfecc3249c181572910a9925257fbe52a2))\n* promote next-feat to main ([4fbe313](https://github.com/es6kr/skills/commit/4fbe31332c58bf24327d819cc9204ebda2d4afa8))\n\n## [0.4.0](https://github.com/es6kr/skills/compare/consolidate-v0.3.6...consolidate-v0.4.0) (2026-07-23)\n\n\n### Features\n\n* **consolidate:** address PR 134 reviews and reflect orange/yellow severity display rules ([e6118d0](https://github.com/es6kr/skills/commit/e6118d0fb0217a4c4ad388b82e574203a8f9258e))\n* **next-feat:** accumulate features for hook-kit context gate ([df4f73a](https://github.com/es6kr/skills/commit/df4f73ae4d27d4919105da70c6c94a14a32e8056))\n\n\n### Bug Fixes\n\n* **consolidate:** change status column Fixed emoji to green circle (🟢) ([74fa3e5](https://github.com/es6kr/skills/commit/74fa3e58fd655c388454065374c8fcd27e790281))\n* **consolidate:** prohibit using Verified status for valid findings, use Pending or Deferred instead ([8540e4b](https://github.com/es6kr/skills/commit/8540e4b86e0e63e26b295e5beca863dbfefd08a0))\n* **next-fix:** accumulate bug fixes for docxport, wip, fix-plan, and hook-kit ([6eec083](https://github.com/es6kr/skills/commit/6eec083b7fbc429bdabcfcc89d7778b185dd7497))\n* skills body bundle — consolidate/fix/hook-kit refinements + English-clean guard hooks (Ralph-loop bypass) ([2e26f41](https://github.com/es6kr/skills/commit/2e26f412a5b963984898e13caaca186c3617ca08))\n\n## [0.3.6](https://github.com/es6kr/skills/compare/consolidate-v0.3.5...consolidate-v0.3.6) (2026-07-19)\n\n\n### Bug Fixes\n\n* **claude-session,consolidate,next:** promote next-fix staging ([902cfa5](https://github.com/es6kr/skills/commit/902cfa57de68d9f5487425b524ffa4441f81f302))\n* **consolidate:** extend Step 2.3 to three-axis duplicate-review check ([8b07965](https://github.com/es6kr/skills/commit/8b0796549215d4abb0fa349f4d5c5ba361aada88))\n* **consolidate:** skip AI Review Summary posting on draft PRs ([#99](https://github.com/es6kr/skills/issues/99)) ([fa7987a](https://github.com/es6kr/skills/commit/fa7987ab4a082e86e546161279b638f0a3be50c0))\n\n## [0.3.5](https://github.com/es6kr/skills/compare/consolidate-v0.3.4...consolidate-v0.3.5) (2026-07-16)\n\n\n### Bug Fixes\n\n* **consolidate,fix-plan:** promote next-fix staging (review hardening + periodic archive) ([24726e9](https://github.com/es6kr/skills/commit/24726e99a5b2972f706d8749ea3a45cbc358984b))\n* **consolidate:** harden review handling + finding-number backticks ([bc68aab](https://github.com/es6kr/skills/commit/bc68aab0c78adea36c6597213c3e7aa02201ac68))\n* **consolidate:** require human reviewer check and collect existing Copilot reviews ([e862c55](https://github.com/es6kr/skills/commit/e862c5536b6d4474f78ab7ec17179bca7aa5fd16))\n\n\n### Documentation\n\n* add install-guide READMEs for consolidate, git-repo, skill-kit ([380db80](https://github.com/es6kr/skills/commit/380db8070a60dbfe1be29d940a6740e1119db748))\n* add install-guide READMEs for consolidate, git-repo, skill-kit ([d9bec4b](https://github.com/es6kr/skills/commit/d9bec4bb17c294a40c373c376a2f22aa0d3c04f2))\n* correct skills install command (add, not install) + superpowers namespace ([ed8fb1a](https://github.com/es6kr/skills/commit/ed8fb1ab2cd251e2395363948104bd3d3915f010))\n\n## [0.3.4](https://github.com/es6kr/skills/compare/consolidate-v0.3.3...consolidate-v0.3.4) (2026-07-07)\n\n\n### Bug Fixes\n\n* **consolidate:** add review-state matrix, rate-limit retrigger discipline, engine-selection rework ([ce55aca](https://github.com/es6kr/skills/commit/ce55aca440cd424c4195140acdc9019cb8097aae))\n* **consolidate:** address PR review findings — third trigger branch in self-check, example disambiguation ([294e0df](https://github.com/es6kr/skills/commit/294e0dffaf342da5ab7521681eb35ba0dff3be76))\n* **consolidate:** align internal-review trigger wording with visibility×tier matrix ([15584b3](https://github.com/es6kr/skills/commit/15584b37c7933bcf4815ef8950882903ba67fac3))\n* **consolidate:** require subject identification in review-event ask templates ([8b9d6d7](https://github.com/es6kr/skills/commit/8b9d6d76048dec5b2c18ebc2b2e8cc474e7d61c8))\n* **skills:** review-feedback bundle — consolidate trigger wording + fix wiki paths ([784854e](https://github.com/es6kr/skills/commit/784854e3e07696ca8d16274215004488861862d1))\n\n## [0.3.3](https://github.com/es6kr/skills/compare/consolidate-v0.3.2...consolidate-v0.3.3) (2026-07-03)\n\n\n### Bug Fixes\n\n* **consolidate:** add Step 3.5.0 CodeRabbit CLI local pre-check before superpowers fallback ([892e42b](https://github.com/es6kr/skills/commit/892e42b512b48edb3a303141883110d7f28dedd2))\n* **skills:** patch bundle — consolidate/next/fix/skill-kit/github-flow ([3cb90cb](https://github.com/es6kr/skills/commit/3cb90cb7601f619b63518860bebfb693d58a7633))\n\n## [0.3.2](https://github.com/es6kr/skills/compare/consolidate-v0.3.1...consolidate-v0.3.2) (2026-06-25)\n\n\n### Bug Fixes\n\n* apply PR [#62](https://github.com/es6kr/skills/issues/62) AI review findings (14) ([8132a2b](https://github.com/es6kr/skills/commit/8132a2b001fbd10e3db618decf989f8cf84b1b6b))\n* **consolidate:** post-mortem Status column spec — block fix_plan tracking tags ([ad94f03](https://github.com/es6kr/skills/commit/ad94f03b6a715ce5eb067d41f2b47042048c084c))\n* **fix:** split Step 2 medium by content type — case history to failed-attempts.md ([#62](https://github.com/es6kr/skills/issues/62)) ([747b3f9](https://github.com/es6kr/skills/commit/747b3f957ca0fefdbc5044eb08f66b8aafc1e26a))\n\n## [0.3.1](https://github.com/es6kr/skills/compare/consolidate-v0.3.0...consolidate-v0.3.1) (2026-06-19)\n\n\n### Bug Fixes\n\n* bundle skill patches across 7 scopes ([f18f47c](https://github.com/es6kr/skills/commit/f18f47c2d05f13b8e3f3ad42675a2dabbb31c824))\n* **consolidate:** add --interactive mode + author≠me Formal Review POST policy ([d1d5a41](https://github.com/es6kr/skills/commit/d1d5a4125443bc26c82ec923095a17ef1fafe49e))\n* **consolidate:** add github-flow to depends-on for accurate dependency graph ([0c7e088](https://github.com/es6kr/skills/commit/0c7e08832fcc16cb52f967fb68bfaa09078cbd81))\n* **consolidate:** convert depends-on to block-style for strictyaml compat ([00d733f](https://github.com/es6kr/skills/commit/00d733f8ada220448eb8cf09378690685ffa49c3))\n* **consolidate:** sort depends-on + disambiguate cross-references ([6c06b04](https://github.com/es6kr/skills/commit/6c06b049363d66a96aee80a85bd1e99f3feada1c))\n\n## [0.3.0](https://github.com/es6kr/skills/compare/consolidate-v0.2.2...consolidate-v0.3.0) (2026-06-12)\n\n\n### Features\n\n* decompose workflow/git rules + rename web-ui-test→web-browser ([#50](https://github.com/es6kr/skills/issues/50)) ([e10d48f](https://github.com/es6kr/skills/commit/e10d48fea4e507b95888de44812b53484d32128d))\n\n## [0.2.2](https://github.com/es6kr/skills/compare/consolidate-v0.2.1...consolidate-v0.2.2) (2026-06-11)\n\n\n### Bug Fixes\n\n* **consolidate:** Copilot availability pre-check, inline review medium, finding-first ordering, authorship gate ([#49](https://github.com/es6kr/skills/issues/49)) ([7bc3ba2](https://github.com/es6kr/skills/commit/7bc3ba21978a0296809f92caabcc080dffa35d84))\n\n## [0.2.1](https://github.com/es6kr/skills/compare/consolidate-v0.2.0...consolidate-v0.2.1) (2026-05-27)\n\n\n### Bug Fixes\n\n* **consolidate:** Step 2.7 worktree checkout + Axis B-before-medium gate + Step 2.6 re-review trigger policy ([1e11ee3](https://github.com/es6kr/skills/commit/1e11ee36d78f4ab64a9f8f8800f51108d3012b14))\n\n## [0.2.0](https://github.com/es6kr/skills/compare/consolidate-v0.1.0...consolidate-v0.2.0) (2026-05-24)\n\n\n### Features\n\n* publish 6 skills, rename folders to match slugs, add skill-kit find topic ([cc9859d](https://github.com/es6kr/skills/commit/cc9859ddbb2fa87e978a0f34c2ec6d18b9573995))\n* publish 7 new skills, update 4 existing skills ([dce016d](https://github.com/es6kr/skills/commit/dce016da291f4c9da03746f8be668fa5db04e578))\n\n\n### Bug Fixes\n\n* address CodeRabbit and Copilot review on PR [#11](https://github.com/es6kr/skills/issues/11) ([198aa0f](https://github.com/es6kr/skills/commit/198aa0f3b7afce702586100e8c697301bb18021d))\n* address CodeRabbit review findings on PR [#4](https://github.com/es6kr/skills/issues/4) ([bbaefdc](https://github.com/es6kr/skills/commit/bbaefdc8a88f26b0b072e115d0696e732ac52e0c))\n\n\n### Refactor\n\n* **consolidate:** split pr-review.md into 7 topics + translate to English ([7482a62](https://github.com/es6kr/skills/commit/7482a6213f1680123f100a4528dc6b7beb16bc52))\n* **consolidate:** split pr-review.md into 7 topics + translate to English ([77caf0b](https://github.com/es6kr/skills/commit/77caf0bef5e96ff0281e886f34e0863f8036f505))\n\nFile v0.8.0:classify.md\n\n# Analyze and Classify\n\nClassify each finding using the verify→evaluate→respond pattern. Apply PR diff scope cross-check + option grouping + dual-label (Type | Severity).\n\nEntry: `Skill(\"consolidate\", \"classify ...\")` or `pr.md` Workflow Step 4.\n\n## Step 4: Analyze and Classify (verify before accepting)\n\nFor each feedback item, apply the **verify→evaluate→respond** pattern loaded from `superpowers:receiving-code-review`:\n\n1. **READ**: Complete feedback without reacting\n2. **VERIFY**: Check against codebase reality — `grep` for actual usage, read the implementation being criticized\n3. **EVALUATE**: Is this technically sound for THIS codebase? YAGNI check — if the suggestion adds unused functionality, classify as Rejected\n\n> **The `receiving-code-review` load is justified ONLY by producing explicit validity verdicts (Step 4-0) — including ⚪ Rejected where warranted.** If a consolidate run defaults every finding to Deferred and produces zero Reject consideration, the skill load was decorative: the framework's core verb is \"push back when wrong\", not \"defer everything\". A Summary with no Reject path exercised does not need `receiving-code-review` at all.\n\n### Step 4-0: Validity verdict (MANDATORY — operationalize receiving-code-review, runs BEFORE 4-A/Severity)\n\n**Validity (valid vs reject) and timing (now vs defer) are SEPARATE axes. Every finding must get an explicit validity verdict FIRST.** Timing (immediate fix / Deferred) applies **only to findings already judged VALID**. A wrong / inapplicable finding is ⚪ **Rejected** — it must NOT be silently carried as \"Deferred\" (Defer is a timing decision for valid findings, never a substitute for the Reject validity verdict).\n\nPer finding, record one verdict:\n\n| Verdict | When | Next |\n|---------|------|------|\n| ✅ **VALID** | Verified correct for THIS codebase | → Step 4-A scope + Severity + timing (now/defer) |\n| ⚪ **REJECTED** | One of the Reject reasons below holds | → pushback track (reason mandatory; NOT carried into apply/defer groups) |\n\n**Reject reasons (any one ⇒ ⚪ Rejected — not Deferred):**\n\n1. **YAGNI** — adds unused functionality (grep confirms no caller / no need)\n2. **Technically inappropriate** — wrong for this stack/platform/version\n3. **Contradicts the author's deliberate or documented intent** — the PR/commit/issue shows the author intentionally chose the criticized structure (e.g., a deliberately-built merge/TDD structure, an explicit architectural decision). A reviewer preference against a deliberate author choice is Rejected, not Deferred\n4. **False premise** — VERIFY failed: the finding's factual claim is wrong (e.g., \"PR introduced regression in X\" but `git log ..HEAD -- X` is empty — see Step 4-A #7)\n5. **Already handled elsewhere** — the concern is covered by existing code/middleware/tests the reviewer missed\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Default a finding to `🟡 Deferred` without a validity verdict | Assign VALID or ⚪ REJECTED first. Defer only a VALID finding |\n| 2 | Carry a wrong / author-contradicting finding as \"Deferred (author follow-up)\" | A wrong finding is ⚪ Rejected with reason. Deferring it dumps invalid work on the author |\n| 3 | Produce a Summary where every finding is Deferred and none was Reject-considered | That means `receiving-code-review` was loaded but unused (decorative). Each finding's verdict must show the validity judgment was actually made |\n| 4 | Treat \"Reject\" as confrontational and soften to Defer | Reject with a one-line technical reason is the honest verdict the framework requires (\"push back when wrong\") |\n\n**Self-check (before Step 4-A / Severity / option construction):**\n\n1. Does **every** finding have an explicit VALID or ⚪ REJECTED verdict? (no finding reaches Severity/timing without it)\n2. For each ⚪ REJECTED, is exactly one Reject reason (1–5 above) cited in one line?\n3. Did you actively consider the Reject path for each finding — not just default to VALID→Defer? (If zero findings were even Reject-evaluated, re-run this step — the `receiving-code-review` load is otherwise decorative)\n4. Are any \"Deferred\" findings actually Reject candidates (wrong / contradicts author intent / false premise)? → reclassify to ⚪ Rejected\n\n### Step 4-A: PR diff scope cross-check (MANDATORY before classifying deferred)\n\n**Before classifying any finding, cross-check the finding's file path against the result of `gh pr view --json files` (the list of files this PR actually modified).** If the file referenced by the finding is **included in the PR diff, the \"outside PR scope\" label is forbidden** — classify it as an immediate fix candidate within the same PR.\n\n```bash\n# Collect PR diff file list (run once before classification)\nGH_TOKEN=\"$(gh auth token --user )\" gh pr view -R / --json files --jq '.files[].path' | sort > /tmp/pr-${N}-files.txt\n```\n\nAfter cross-checking, explicitly mark the **scope label** in the finding classification report:\n- ✅ **In diff** — finding file is inside the PR diff. Immediate fix candidate (deferred default is forbidden regardless of Severity)\n- ❌ **Outside diff** — finding file is outside the PR diff. May be classified as deferred\n\n#### Don't / Do table (HARD STOP — PR scope inference forbidden)\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Inferring \"this is only scope X\" from PR title/branch name (`spike/`, `feat:`, etc.) → classifying findings on other files as deferred | Measure with `gh pr view --json files` → if finding file is in diff, \"outside PR scope\" label is forbidden |\n| 2 | Asserting \"this is a spike PR, so packages/web changes are external work\" | Even in a spike PR, if packages/web files are in the diff, that part is within the same PR scope |\n| 3 | Autonomously judging \"this finding naturally belongs in a separate PR\" | Scope is a user decision. For findings inside the diff, include \"immediate fix\" as the default option candidate |\n| 4 | Automatically deferring when Severity is Minor | Severity and scope are separate dimensions. Minor + In diff = immediate fix possible. Only Minor + Outside diff defaults to deferred |\n| 5 | Deferring because \"this file seems unrelated to the PR\" | \"Seems\" is not a judgment. Measure with `gh pr view --json files` |\n| 6 | Using `git diff ..HEAD --name-only` (two-dot, bidirectional) as the PR scope source | Two-dot includes files that `` has but `HEAD` does not (i.e., main's later changes that PR did not absorb). Use `gh pr view --json files` (PR-touched only) or `git diff ...HEAD` (three-dot, single-direction) |\n| 7 | Asserting \"PR modifies file X\" because `git diff ..HEAD` lists X | Cross-check: `git log ..HEAD -- ` — if empty, PR has zero commits touching the file (the two-dot diff is showing main's later change in reverse). The finding's \"regression introduced by PR\" claim is false; squash merge preserves main's change because PR's change set is empty for that file |\n\n#### Self-check (before every classification)\n\n1. Do you have the result of `gh pr view --json files` in memory?\n2. Did you cross-check each finding's file path against the diff file list?\n3. Did you add a **scope label** column (In diff / Outside diff) to the classification report table?\n4. For items classified as deferred, did you review **In diff** items for promotion to immediate fix candidates?\n5. **Two-source cross-check (HARD STOP)** — for any finding that claims \"PR modified file X\", verify BOTH: (a) `gh pr view --json files` lists X, AND (b) `git log ..HEAD -- ` returns 1+ commits. If (a)=yes and (b)=empty, or (a)=no and (b)=any, the finding is suspect — the file is most likely main's change PR did not absorb. The squash merge preserves main's state for files PR did not touch (commit count 0 in (b)) — \"pre-merge rebase required\" claims must be backed by (b) ≥ 1.\n\n### Step 4-B: Option grouping guide (MANDATORY — before constructing Step 5/Step 8 options)\n\nWhen bundling classified findings into AskUserQuestion options, the **finding-count cumulative** pattern (A only / A+B / A+B+C / all) is forbidden. Instead, generate option candidates by grouping the **Apply group** and **Deferred group** each by semantic unit.\n\n#### Apply group (natural per commit)\n\n| Grouping criterion | Bundling example |\n|-------------------|------------------|\n| **Same file** | A (App.svelte:23) + other App.svelte changes → same commit |\n| **Same domain** | E (extension.ts openTerminalHere) — extension domain. If it follows the same pattern as startClaudeInFolder, commit together |\n| **Same abstraction layer** | UI fix (A, B), test infra (D), core (C) — each as a separate commit is natural |\n| **Sequential dependency** | C (cleanup.ts defensive guard) → D (cleanup-related test) → same commit |\n| **Trivial fix bundle** | Multiple 1-line fixes bundled into one chore commit |\n\n#### Deferred group (follow-up bundle)\n\n| Grouping criterion | Bundling example |\n|-------------------|------------------|\n| **Same follow-up PR target** | B + additional web UI refactor findings → separate web-cleanup PR |\n| **Same issue unit** | E (terminal mode regression) → register as separate issue |\n| **Unrelated deferreds separated** | If each goes to a different follow-up, separate them in options too (standalone items, no bundling) |\n\n#### Don't / Do table\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Finding-count cumulative options (\"A only / A+B / A+B+C / all\") | Semantic group options (\"UI one-liner bundle / extension domain / test infra / all\") |\n| 2 | Unioning findings from separate domains into one option (\"A + D immediate fix\") | If domains differ, separate the options, or explicitly state the reason for bundling (e.g., \"for atomic verification\") |\n| 3 | Compressing deferreds into a single option (\"D + E deferred\") | If the deferred group has different follow-ups, explicitly separate follow-up medium in option description |\n| 4 | Including C (Rejected) finding in apply option candidates | Rejected belongs to a separate pushback comment track. Don't bundle with apply options (apply option + separate pushback) |\n| 5 | Always adding \"fix all\" as the last default option | If \"fix all\" forms a natural atomic bundle, make it the first option; otherwise exclude |\n\n#### Self-check (before every option construction)\n\n1. Are option candidates finding-count cumulative? → If yes, reconstruct as semantic groups\n2. Do findings within each option naturally bundle into the same commit?\n3. If there are deferred options, is the follow-up medium (separate PR / separate issue / checklist) natural?\n4. Are Rejected findings separated from apply options? (Pushback is a separate track)\n5. Does the option label make the group meaning clear at a glance? (e.g., \"UI one-liner bundle\" vs \"fix 2 items\")\n\n#### Violation case\n\nIn the re-asked AskUserQuestion, options \"A only / A+B+E / A+B+D+E / all 5\" were presented. Finding-count cumulative pattern. User pointed out: \"Also consider harmony between apply features and between deferred features.\" Resolved by adding this Step 4-B.\n\n### Dual-label (Type | Severity, orthogonal)\n\nClassify using **CodeRabbit-style dual-label** (category + severity combination):\n\n> **⚠️ Two axes are orthogonal (HARD STOP)**: **Type category** (what it is) and **Severity category** (how important) are **separate classification axes**, and one finding simultaneously holds one value on each axis. You cannot \"downgrade/upgrade\" one axis to another. Example: \"Change Important → Potential\" = ❌ invalid request (Important is Severity, Potential is Type). \"Downgrade Important → Minor\" = ✅ movement within the same axis (Severity).\n\n**Type category** (what it is — Category Type):\n\n| Label | Meaning |\n|-------|---------|\n| ⚠️ Potential issue | Possible bug, security risk, logic error |\n| 🛠️ Refactor suggestion | Refactoring, structural improvement |\n| 📝 Nitpick | Naming, style, minor improvement |\n| 💡 Tip | Reference info, alternative suggestion |\n| ✅ Verification | Verification needed |\n\n**Severity category** (how important — Severity):\n\n| Label | Meaning | Action |\n|-------|---------|--------|\n| 🔴 Critical | Must fix — blocks merge | Fix required |\n| 🟠 Important | Should fix — does not block merge | Should fix |\n| 🟡 Minor | Optional fix — Nitpick level | Evaluate with user |\n| 🟢 No issue | No action needed | No action |\n| ⚪ Rejected | Technically inappropriate | Reject with reasoning |\n\n**Notation format**: `Type | Severity` — e.g., `⚠️ Potential issue | 🔴 Critical`, `🛠️ Refactor | 🟠 Important`, `📝 Nitpick | 🟡 Minor`\nIn the AI Review Summary findings table, `Source`, `Type`, and `Severity` are unified into a single 3-line cell under `Source / Classification` (`

`) to preserve horizontal column width for `Location` and `Finding`.\n\n**Orthogonal matrix example** (one finding has one value on each axis):\n\n| Type ＼ Severity | 🔴 Critical | 🟠 Important | 🟡 Minor |\n|------------------|-------------|--------------|----------|\n| ⚠️ Potential | Security vulnerability (immediate fix) | Suspected 1-day blocking timezone handling | Uncovered edge case |\n| 🛠️ Refactor | Missing API permission guard | Introduce helper for 29 fields | Variable name consistency |\n| 📝 Nitpick | (rare) | (rare) | Missing screenshot attachment |\n\n**Axis confusion forbidden Don't / Do**:\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | \"Change Important → Potential\" (different axis) | \"Downgrade Important → Minor\" (within Severity axis) or \"Reclassify Potential → Refactor\" (within Type axis) |\n| 2 | In AskUserQuestion, presenting handling options bundled by only one axis label | Confirm the intent axis first, then ask: \"Downgrade Severity?\" vs \"Reclassify Type?\" |\n| 3 | User says \"treat as Potential\" → replacing Severity Important with Potential | \"Treat as Potential\" is a Type change request. Or if user intent is ambiguous, use AskUserQuestion to confirm which axis |\n| 4 | Changing only one axis and omitting the other axis notation | Keep both Type + Severity explicitly (e.g., `⚠️ Potential` + `🟠 Important`) |\n\n**Self-check (whenever the user instructs a change with category/severity keywords)**:\n\n1. Is the word the user mentioned a **Type axis** word (Potential/Refactor/Nitpick/Tip/Verification)? Or a **Severity axis** word (Critical/Important/Minor/No issue/Rejected)?\n2. If neither axis has the word or it's ambiguous → use AskUserQuestion to confirm which axis the change is on\n3. Changing one axis does not touch the other axis notation (e.g., when Important → Minor, Type notation `⚠️ Potential` stays unchanged)\n\n**Severity label rule**: All review comments (Internal Code Review, AI Review Summary) use the same dual-label standard.\n\n**Blind acceptance forbidden.** Each Actionable/Suggestion item must have a one-line verification note: what was checked and why it's valid.\n\nPresent classified results to user via text summary. **Do NOT auto-fix anything.**\n\n### Checklist extraction guide (required)\n\nAll Actionable items (feedback requiring a fix) must be extracted as individual tasks under the corresponding PR section of the checklist. This record prevents omissions and becomes the concrete backlog for the code workflow.\n\n- **Format**: `- [ ] [REVIEW_FEEDBACK] {reviewer name}: {issue summary} — {specific fix direction/location}`\n- **Example**: `- [ ] [REVIEW_FEEDBACK] CodeRabbit: Keyboard shortcut not working — Add focus() call when MessageEditor.svelte dialog show=true`\n\n> **Ralph (autonomous mode) exception**: AskUserQuestion is unavailable. Skip Step 5 (`decide.md`) and proceed directly to Step 7 (`post.md`) to post the Summary immediately. Record all Actionable items as `[REVIEW_FEEDBACK]` entries in the checklist per the extraction guide above, awaiting code application in the next loop.\n\n## Next\n\n→ `decide.md` (Step 5 User Decision + Step 6 Fix)\n\nFile v0.8.0:collect.md\n\n# Collect AI Reviews\n\nCollect AI reviews (CodeRabbit, Copilot, etc.) posted on the PR and load the verify→evaluate→respond framework.\n\nEntry: `Skill(\"consolidate\", \"collect ...\")` or `pr.md` Workflow Step 3.\n\n## Step 3: Collect AI Reviews\n\nRather than running separate manual commands, run the consolidated collection script:\n\n```bash\nbash ~/.claude/skills/consolidate/scripts/collect.sh [account]\n# e.g., bash ~/.claude/skills/consolidate/scripts/collect.sh daegunsoftDev/turborepo-web 412 daegunjhy\n```\n\nIf you prefer running individual commands manually:\n\n```bash\n# PR review comments (inline)\ngh api repos/{owner}/{repo}/pulls/{number}/comments\n\n# PR issue comments (summary)\ngh pr view --comments --json comments\n```\n\nIdentify reviews from:\n- `coderabbitai[bot]` — CodeRabbit\n- `copilot[bot]` — GitHub Copilot\n- Other bots with `[bot]` suffix\n\n> **Bot login differs by API surface (poll/filter gotcha)**: GraphQL (`gh pr view --json reviews`) returns `author.login` WITHOUT the suffix (e.g. `copilot-pull-request-reviewer`), while REST (`gh api .../pulls/{N}/reviews`) returns `user.login` WITH it (e.g. `copilot-pull-request-reviewer[bot]`). An exact-match jq filter written for one surface silently matches nothing on the other — a completion poll can time out while the review has already arrived. Use a substring/`test()` match (e.g. `test(\"copilot\")`) or match per surface.\n- **Human MEMBER/OWNER reviews and review-shaped comments (HARD STOP)** — enumerate every `reviews[]` entry whose `author.is_bot == false`, plus every `comments[]` entry whose `authorAssociation` is `MEMBER`/`OWNER`/`COLLABORATOR` AND whose body contains a review-style header (Code Review headers, `### Findings`, `### Issues`, `Critical`, `Important`, `Should fix`, `Must fix`, localized equivalents in any language). Each such reviewer (login) is a distinct **Source** that must be carried forward into the findings table — do not collapse them under \"Internal Code Review\". Query: `gh pr view --json reviews,comments --jq '[.reviews[] | select(.author.is_bot==false) | {kind:\"review\", login:.author.login, body}] + [.comments[] | select(.authorAssociation == \"MEMBER\" or .authorAssociation == \"OWNER\" or .authorAssociation == \"COLLABORATOR\") | {kind:\"comment\", login:.author.login, body}]'`. Cross-check returned bodies for review-style headers before declaring a `comment` entry a review source.\n\n### Zero-findings completion state (do NOT treat as missing review)\n\nCodeRabbit's summary comment \"**No actionable comments were generated in the recent review**\" is a **completed review with verdict 0 findings** — the walkthrough is usually collapsed inside that same comment. It is NOT a rate-limit / pending / failure state, and it is NOT grounds for a re-review trigger (see `pr.md` Step 2.6 state matrix).\n\nHandling: record the reviewer in the matrix with verdict \"no actionable findings\" and continue to classify/post — `post.md` already supports a clean-reviewer row (\"state 'No actionable findings' in the table if all reviewers are clean\").\n\n### Source-Specific Handling\n\nAll AI reviewers are **external reviewers** — treat their suggestions as proposals to evaluate, not orders to follow.\n\n| Reviewer | Strengths | Watch out |\n|----------|-----------|-----------|\n| **CodeRabbit** | Full codebase context, walkthrough, security checks | Can suggest over-engineering; may not understand project conventions |\n| **Copilot** | Inline code suggestions, style consistency | May miss cross-file context; suggestions can break other callers |\n\nBefore accepting any suggestion:\n1. Check: Technically correct for THIS codebase?\n2. Check: Breaks existing functionality or callers?\n3. Check: Reason for current implementation? (grep for usage)\n4. Check: Works on all platforms/environments?\n5. Check: Conflicts with user's prior architectural decisions?\n\n\n## Step 3.6: Invoke superpowers:receiving-code-review\n\n**MANDATORY**: Before analyzing, invoke the review-receiving skill to load the verification framework:\n\n```text\nSkill(\"superpowers:receiving-code-review\")\n```\n\nThis loads the verify→evaluate→respond protocol. Follow it for every feedback item in Step 4 (classify).\n\n**Proactive Plugin Installation (HARD STOP)**: `superpowers` MUST be installed as a **plugin** (`obra/superpowers`), NOT as individual skills via `npx skills add`. If the plugin is not present, install it via the plugin management mechanism:\n```bash\n# Plugin installation for superpowers\nclaude plugin add obra/superpowers\n```\nCheck and install any other missing peer skills or plugins (like `git-repo` or `github-flow` from `es6kr/skills`) in the same manner.\n\n**Abort if unavailable (HARD STOP)**: If the skill remains unavailable even after the installation attempt, or if the installation command fails, **immediately abort the consolidate procedure**. Report to the user \"Cannot use the `superpowers:receiving-code-review` skill; aborting consolidate\" and terminate. Analyzing reviews without the verify→evaluate→respond framework risks blind acceptance, so alternative continuation is prohibited.\n\n## Re-checking a previously-posted AI Review Summary\n\nWhen following up on a `[REVIEW_FEEDBACK]` fix_plan entry (checking whether a previously-deferred finding is still outstanding), don't re-parse `gh pr view --json comments`'s output by hand — extract the already-posted Findings table structurally:\n\n```bash\nuv run python ~/.claude/skills/consolidate/scripts/extract-review-findings.py \n```\n\nPrints `{\"comment_url\": \"...\", \"findings\": [{\"#\": \"1\", \"Source\": \"...\", ...}, ...]}` — one dict per row, keyed by whatever column headers the table actually used (column layout varies slightly across sessions — e.g. `Source`/`Location` vs `Reviewer`/`File:Line`). Errors with `{\"error\": \"no AI Review Summary comment found\"}` (exit 1) if the PR has no posted summary yet.\n\n## Next\n\n→ If the external AI review is walkthrough only / in a failure state, go to `internal.md` (Step 3.5 Internal Review Fallback)\n→ Otherwise, go to `classify.md` (Step 4 Analyze and Classify)\n\nFile v0.8.0:decide.md\n\n# User Decision (Formal Review) + Fix\n\nPresent classification results to the user from Step 4 and decide on Axis B (Formal Review action) only. AI Review Summary posting and Findings deferred registration are **procedure** (Step 7 / 7.6), not user decisions. fix is only executed when the user explicitly instructs (typically via Step 8 next-action or follow-up turn).\n\nEntry: `Skill(\"consolidate\", \"decide ...\")` or `pr.md` Workflow Step 5 / Step 6.\n\n## Step 5: Formal Review Decision (Axis B only)\n\n**Axis A (Findings handling) ask is forbidden (HARD STOP — 3 recurrences 2026-05-24)**.\n\nThe AI review handling flow is procedure:\n- Condition (a): CodeRabbit walkthrough + Copilot review both posted normally → Step 7 auto-post AI Review Summary\n- Condition (b): CodeRabbit walkthrough only OR Copilot error → Step 3.5 Internal Review Fallback → Step 7 auto-post AI Review Summary\n- Actionable findings → Step 7.6 auto-register to fix_plan.md `[REVIEW_FEEDBACK]` (defer by default)\n- fix is a **separate step only on explicit user instruction** (Step 8 next-action or a follow-up turn like \"apply the review\")\n\n**Step 5 is Axis B (Formal Review action) only**. Ask only when you are a requested reviewer. Otherwise skip Step 5 and proceed directly to Step 7.\n\n### Axis B ask precedes Summary medium decision/posting (HARD STOP — added 2026-05-26)\n\n**When you are a requested reviewer, the Step 5 Axis B ask MUST precede the Step 7 Summary posting (whether issue comment or Formal Review body).** \"Summary = procedure (automatic)\" applies only to **Axis A (findings handling / whether to post)**, **not to the medium decision**. The Summary's medium (issue comment vs Formal Review body) is **dependent on the Axis B answer**, so posting the Summary in any medium before the Axis B answer strips the user of their Formal Review decision authority.\n\n#### Don't / Do table\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | As a requested reviewer, post the Summary as an issue comment without the Axis B ask | Axis B ask **first** → decide the medium per the answer (APPROVE/COMMENT/REQUEST_CHANGES/Skip) → then post |\n| 2 | Execute post.md's \"Non-Mergeable → issue comment only, Formal Review skipped\" auto-rule without asking when `mergeable: CONFLICTING` | Even when CONFLICTING, a requested reviewer asks Axis B first. The medium auto-skip applies **only after** the ask answer |\n| 3 | \"Summary is automatic procedure, so post it now and handle Axis B later\" | \"Summary auto-post\" is limited to Axis A (whether to post). The medium depends on Axis B → ask first |\n| 4 | Evaluate post.md's medium table before the Axis B ask to fix the medium | The medium table takes **both** the Axis B answer + mergeable. Do not finalize the medium while Axis B is unanswered |\n\n#### Self-check (every time before posting the Summary — HARD STOP)\n\n1. Are you a requested reviewer? (`gh pr view --json reviewRequests` + cross-check active account) → If No, this gate does not apply (auto-post issue comment OK)\n2. If Yes, **has the Axis B ask already been answered?** → If No, **posting the Summary is forbidden**. Call the Axis B ask first\n3. Only after the Axis B answer, decide the medium (feed the Axis B answer + mergeable into the post.md Step 7 medium table)\n4. If the thought \"it's CONFLICTING so it's an issue comment anyway\" arises = violation signal. Even CONFLICTING requires the Axis B ask first\n\n### Don't / Do — Axis A ask forbidden (HARD STOP)\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Call an Axis A ask (\"Post summary as-is / Fix actionable items / Skip\") | Proceed automatically to Step 7. Posting the Summary is procedure, not a user decision |\n| 2 | Ask the user about Findings handling | Findings are auto-registered to fix_plan.md `[REVIEW_FEEDBACK]` in Step 7.6 (defer by default) |\n| 3 | \"fix is more natural, so Recommended\" / \"it's Critical/Important, so recommend fix\" thinking | fix only on explicit user instruction. No auto-recommendation |\n| 4 | Apply the archive rule \"no auto-application\" to Summary posting too | \"No auto-application\" applies only to fix (code changes). Summary posting is procedure (separate domain) |\n| 5 | Bundle Summary posting + Findings handling into one ask | Summary = procedure (automatic), Findings = auto deferred registration. fix is a separate step (Step 8 or explicit instruction) |\n\n### Self-check (before entering Step 5)\n\n1. Are you a requested reviewer? (`gh pr view --json reviewRequests`) → If Yes, ask Axis B only. If No, skip Step 5 → Step 7\n2. Are you building an Axis A option? → Don't. Proceed automatically to Step 7\n3. If a \"Fix actionable items\" or \"Whether to post the Summary\" option appears = violation\n5. Does the ask question text identify the subject PR (`PR # (/)` + URL)? Nickname-only subject = violation\n4. **Is `AskUserQuestion` actually callable in this context?** If it errors \"not enabled\" / you are headless (`claude -p` / Ralph) → do NOT re-pose Axis B as text. Apply the severity default (Critical → REQUEST_CHANGES, else COMMENT only — never auto-APPROVE) and continue to Step 7 (see \"AskUserQuestion unavailable → deterministic Formal Review default\")\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Place \"Fix actionable items\" as the first option + mark it Recommended | Place \"Post summary as-is\" as the first option. Fix goes second-or-later (Recommended marking forbidden) |\n| 2 | \"Fix is more efficient, so mark it Recommended\" / \"Critical/Important findings → recommend fix\" thinking | Independent of efficiency or severity. Acting on the AI review is the user's autonomous decision. Recommended marking itself is forbidden |\n| 3 | Auto-place \"Fix actionable\" as the first option when severity is Critical/Important | Severity belongs in the option description. Order prioritizes \"decision preservation\" |\n| 4 | \"User decides on fix anyway, so first-position is fine\" thinking | First option = implicit Recommended. Order itself is a statement of intent |\n\n### Axis B: Formal Review action (HARD STOP — required when you are a requested reviewer)\n\n**Pre-check: am I a requested reviewer?**\n\n```bash\nGH_TOKEN=\"$(gh auth token --user )\" \\\n gh pr view -R / --json reviewRequests --jq '.reviewRequests[].login'\n# Match against current `gh auth status` active account\n```\n\n**Subject identification (HARD STOP)**: every Axis B / review-event ask MUST identify the subject PR explicitly — `PR # (/)` plus the PR URL (the `PR #` prefix form is also what ID-guard hooks accept — `/#` alone is rejected) — in the question text. A session often carries multiple open PRs; a nickname-only subject (\"the bundle PR\", \"this PR\") makes the verdict ambiguous. When a guard hook rejects `#N` tokens, prefix them (`PR #N`) — never drop the identifier.\n\nIf the current account appears in `reviewRequests`, present the Axis B ask (the only ask in Step 5 — Axis A has been removed per the HARD STOP above):\n\n```javascript\nAskUserQuestion({\n question: \"[PR # (/) — ] Formal Review action (you are a requested reviewer)?\",\n options: [\n { label: \"APPROVE\", description: \"Findings clean / Critical 0 / merge OK\" },\n { label: \"REQUEST_CHANGES\", description: \"Critical findings exist — block merge\" },\n { label: \"COMMENT only\", description: \"No formal verdict — just post review body\" },\n { label: \"Skip formal review\", description: \"Issue comment Summary only (no PR-level review)\" }\n ]\n})\n```\n\n**Why Axis B matters even though Axis A is removed**: Posting the Summary as an issue comment (Step 7 procedure) is *not* the same medium as a GitHub Formal Review. Formal Review (B) is a separate medium — GitHub PR review state (APPROVE / CHANGES_REQUESTED / COMMENTED) that gates merge. Posting the Summary issue comment without an APPROVE (B) leaves the PR blocked by an unfulfilled review request even if all CI/tests pass.\n\n#### Conditional gate: merge-recommendation verdict → no Skip option (HARD STOP)\n\n**If the AI Review Summary verdict in Step 7-A indicates merge recommendation** (🟢 / \"Merge OK\" / \"Ready to merge\" / \"Merge ready\"), remove the `Skip formal review` option from Axis B. The user must choose APPROVE / REQUEST_CHANGES / COMMENT — not Skip. Reason: Skip leaves `reviewDecision: REVIEW_REQUIRED` unresolved, contradicting the merge-recommendation verdict.\n\n```javascript\n// When AI Review Summary verdict = merge-recommendation\nAskUserQuestion({\n question: \"[PR # (/) — ] Formal Review action (Summary verdict = merge recommendation — Skip not allowed)?\",\n options: [\n { label: \"APPROVE\", description: \"Findings clean / Critical 0 / merge OK — default for merge-recommendation verdict\" },\n { label: \"REQUEST_CHANGES\", description: \"Re-evaluation: Critical findings actually exist — block merge\" },\n { label: \"COMMENT only\", description: \"Verdict reconsidered: post review body without merge gating verdict\" }\n ]\n})\n```\n\nIf the Summary verdict is non-merge (Critical findings exist, Test Plan incomplete, CI failing), keep all 4 options including Skip.\n\n#### AskUserQuestion unavailable → deterministic Formal Review default (HARD STOP)\n\n**When `AskUserQuestion` cannot be called — autonomous mode (`claude -p` / Ralph) OR the tool is disabled in the current context (returns \"not enabled in this context\") — do NOT stop and re-pose the Axis B question as plain chat text.** A text question is the forbidden medium (see `ask-user` guards) AND it stalls the workflow when a deterministic default already exists. Instead, **auto-apply the Formal Review default from the finding severity** and continue to Step 7:\n\n| Highest finding severity | Auto-applied Formal Review event | Reason |\n|--------------------------|----------------------------------|--------|\n| 🔴 Critical present (≥1) | **REQUEST_CHANGES** | Critical blocks merge — an autonomous reviewer must block, not pass |\n| No Critical (Important/Minor/clean) | **COMMENT only** | Post the review body without a merge-gating verdict. An autonomous reviewer must **never** self-grant APPROVE |\n\n**Never auto-APPROVE.** APPROVE grants merge authority and is a human decision; an autonomous/headless reviewer downgrades the merge-recommendation default (which would be APPROVE in interactive mode) to **COMMENT only**. The human merges (or explicitly APPROVEs later) at their discretion.\n\nDetection of unavailability: the `AskUserQuestion` call errors with \"No such tool\" / \"not enabled in this context\", OR the environment is headless (`claude -p` / Ralph `.ralph/` workspace). On any of these → skip the ask, compute the default from the table above, record the auto-applied event + reason in chat, and proceed to Step 7. The Summary's medium follows the auto-applied event exactly as if the user had chosen it.\n\n### Combined Don't / Do — Axis B (requested reviewer + tool-unavailable fallback)\n\nRows 1-3 cover the tool-unavailable fallback; rows 4-8 cover the general Axis B requested-reviewer scenario.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | `AskUserQuestion` errors \"not enabled\" → re-pose Axis B as a plain-text question and stop, waiting for the user | Tool unavailable → auto-apply the severity default (Critical → REQUEST_CHANGES, else COMMENT only) → continue to Step 7 in the same turn |\n| 2 | Auto-apply APPROVE because the verdict was merge-recommendation and the tool is unavailable | Autonomous reviewers never self-APPROVE. Merge-recommendation + no-Critical + tool-unavailable = **COMMENT only** (the human grants APPROVE) |\n| 3 | Treat \"AskUserQuestion unavailable\" as a hard blocker that ends the consolidate run | It is a fallback branch, not a blocker. The deterministic default keeps the run going |\n| 4 | Post issue comment Summary and end, when you are a requested reviewer | Axis B is mandatory when you are a requested reviewer — answer Axis B before entering Step 6/7 |\n| 5 | Assume \"Summary comment counts as APPROVE\" | Issue comment ≠ Formal Review. GitHub merge gates check the `reviews` array, not issue comments |\n| 6 | Skip Axis B because findings are clean | Clean findings + requested reviewer = APPROVE (default), still requires the explicit POST |\n| 7 | Present Skip option when Summary verdict is merge-recommendation | Remove Skip option for merge-recommendation verdicts. Skip + merge-OK verdict = contradiction (reviewDecision unresolved) |\n| 8 | Post Summary verdict = \"🟢 merge OK\" but answer Axis B as Skip | Summary verdict and Formal Review action must align — merge-recommendation Summary mandates APPROVE/REQUEST_CHANGES/COMMENT |\n| 9 | Ask with a nickname-only subject (\"the bundle PR\", \"this PR\") when the session has 1+ other open PRs | Question text opens with `[PR # (/) — ]` — the subject binding is part of the ask, not inferable context |\n\n### Step 5 AskUserQuestion option drift forbidden\n\nStep 5 asks only Axis B (Formal Review action). **Detailed fix-scope options like \"which Critical to apply\" belong in Step 6 and only on explicit user instruction**. If the Step 5 question drifts into a \"fix-scope multiSelect\" or reintroduces an Axis A \"whether to fix\" option, it's a signal that both Step 3.5.3 and Step 7 (posting) are being forgotten.\n\n## Step 6: Fix or Reject (only on explicit user instruction)\n\n**Fix is executed only on explicit user instruction** — typically from the Step 8 next-action ask after Summary posting, or from a follow-up user turn such as \"apply the review\". There is no Step 5 fix-approval gate (Axis A has been removed). **Critical items, if the user instructs a fix, must be fully fixed and verified before re-posting the updated Summary** so the Summary verdict reflects the actual code state.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | code-reviewer reports \"Must Fix\" → immediately execute Edit | Wait for explicit user fix instruction (Step 8 or follow-up turn) → Edit → Critical fully verified → re-post or update Summary → Step 8 merge ask |\n| 2 | Skip ask with \"Critical, so of course fix it\" reasoning | Even Critical requires an explicit user fix instruction. Severity ≠ autonomous fix authority |\n| 3 | Receive code-reviewer result → skip posting review comment → fix immediately | Post Step 3.5.3 comment → Step 4 classification → Step 5 Axis B (if requested reviewer) → Step 7 Summary post → Step 8 next-action ask (fix lands here only if user instructs) |\n\n### Branch ownership check before fixing\n\n| Branch creator | Allowed action |\n|----------------|---------------|\n| Self (gh issue develop) | Code fix + commit + push |\n| Others (dependabot, user branch) | Comment-only — no code changes |\n\n### Pushback procedure (for Rejected items)\n\nWhen a suggestion is technically incorrect, YAGNI, or conflicts with architecture:\n\n1. Write a concise technical reason (not defensive, not performative)\n2. Reply in the PR review thread: `gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies -f body=\"...\"`\n3. Record in checklist as `[REJECTED]` with reason\n\nExample pushback:\n```text\nSuggestion: \"Add retry logic for this API call\"\nRejection: \"Caller already handles retries (see middleware.ts:45). Adding here creates double-retry. YAGNI.\"\n```\n\n### Fixing accepted items\n\n**Critical/Important items must be fixed AND verified before proceeding to the next stage (Summary posting, merge recommendation):**\n\n1. Code fix + commit + push\n2. Wait for CI pass (`gh run watch` or `gh pr checks`)\n3. **Runtime verification of the fix's actual behavior (HARD STOP)** — see \"Review-suggested API call runtime verification\" below\n4. Check `[x]` for the corresponding item in PR Test plan (`gh pr edit --body`) **only after step 3 passes**\n5. Post Summary and recommend merge only after verification is complete\n\nThe \"Shall we merge?\" question is allowed only after all Critical items have been fully verified.\n\nAfter fixing, commit with message referencing the review:\n```text\nfix: address CodeRabbit review on PR #NUMBER\n```\n\n### Review-suggested API call runtime verification (HARD STOP)\n\n**When a review suggestion (AI bot OR Internal Code Review subagent) replaces one API call with another (e.g., \"prefer X over Y\", \"use vscode.open instead of openExternal\"), CI pass + type-check + build success do NOT verify the fix. Runtime verification is mandatory before claiming the Important/Critical is fixed.** CI checks compile-time correctness, not API semantics. A wrong API substitution (e.g., a command that resolves URIs as file paths when the original handled them as extension URIs) compiles cleanly, builds cleanly, and breaks at the first user click.\n\n#### Why this rule\n\nThe fix author is often the same agent that wrote the review (Internal Code Review = code-reviewer subagent dispatched by this skill). Internal Review suggestions inherit the same blind spots that produced them — runtime verify is the only independent check. AI bot suggestions (CodeRabbit, Copilot) have analogous risk: pattern-match correctness without dispatch-semantics verification.\n\n#### Don't / Do\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | \"CI pass + type-check + build OK → Important fixed\" report | CI pass + build OK ≠ runtime correctness for API-substitution fixes. Add a runtime verification step before checking PR Test Plan items |\n| 2 | \"Review suggestion came from a trusted source (Internal Review / CodeRabbit), so apply + commit\" | Internal Review's author may be the same agent that wrote the buggy code. **Look up authoritative docs for the new API** (context7, official API ref, working PoC in the same repo) — if the docs/PoC contradict the suggestion, push back instead of applying |\n| 3 | \"API replacement is a 1-line change so verify is overkill\" | API replacement is HIGH risk. Wrong API often compiles cleanly. 1-line changes need MORE verify, not less — the wrong API hides in a single working-looking line |\n| 4 | Push the fix and rely on PR Test Plan checkbox as the verify | The checkbox is just a checkbox. The verify is the actual runtime exercise (install vsix → click → observe behavior; or curl the affected endpoint; or load the changed UI route) |\n| 5 | \"Author of the suggestion already explained why\" → trust without independent check | The explanation may be wrong. **Cross-check against**: (a) authoritative API docs, (b) an existing working sibling implementation in the same repo (e.g., `feat/resume-in-extension` PoC branch for this PR), (c) ride a runtime smoke test |\n\n#### Self-check (every time before checking the PR Test Plan item as `[x]`)\n\n1. Did this fix REPLACE one API call with another (e.g., `vscode.env.openExternal` → `vscode.commands.executeCommand('vscode.open', ...)`)? — Yes ⇒ rule applies\n2. Did you look up authoritative documentation (context7 / official API ref) for the NEW API's actual semantics? — `vscode.open` handles file/URL paths, NOT extension URIs; that fact would have killed the suggestion at design time\n3. Is there a working sibling implementation in the same repo using the OLD API? (`git branch -a` for PoC branches, `grep` for similar call sites) — if yes, the OLD API is the proven path; replacing it requires positive evidence the NEW API is superior, not just \"more correct in theory\"\n4. Did you exercise the changed code path at runtime? (vsix install + manual click for extension code; curl for endpoints; browser navigation for routes)\n5. Did the runtime exercise produce the expected outcome, OR did it produce a new error (e.g., `EntryNotFound`)?\n\nIf step 5 produced a new error, **REVERT the API substitution immediately** and downgrade the finding in the Summary (e.g., Important → Minor, deferred — \"no reliable success signal exists for this dispatch; openExternal best-effort is the accepted path per PoC branch\").\n\n#### Cross-reference\n\n- `~/.agents/rules/external-publication-verification.md` — covers PR-body claims and external public statements\n- `superpowers:receiving-code-review` \"Verify before implementing\" — covers external bot review reception\n- This rule covers **the gap** between those two: applying an Internal Review's own suggestion + the runtime verify obligation specifically for API-substitution fixes\n\n### 'Apply' interpretation rule for user instructions\n\nWhen the user specifies an application scope such as \"apply only X\" or \"don't apply X\", it **by default means code implementation scope**. If AI Review Summary editing is required, the user explicitly states the target like \"in the Summary\" or \"remove from the review\". When the target is unclear, **use AskUserQuestion to confirm \"is it code implementation scope or Summary editing?\"** — arbitrary interpretation is forbidden.\n\n## Next\n\n→ `post.md` (Step 7 Post AI Review Summary + Formal Review)\n\nFile v0.8.0:internal.md\n\n# Internal Review Fallback + UI Capture Verification\n\nInternal Code Review fallback when external AI review is insufficient — CodeRabbit walkthrough-only (e.g., PRIVATE+Free) or Copilot failure — + UI change PR capture attachment verification.\n\nEntry: `Skill(\"consolidate\", \"internal ...\")` or `pr.md` Workflow Step 3.5 / Step 4.5.\n\n## Step 3.5.0: Internal-review engine selection (superpowers default; CLI = bot-review substitute only)\n\n**The Internal Review engine is provided by the `superpowers` plugin (`superpowers:code-reviewer` agent) by DEFAULT.** CodeRabbit CLI local is NOT an internal-review engine — it is a **bot-review-layer substitute**, used only when the bot layer produced nothing: **no CodeRabbit cloud review evidence on the PR AND Copilot unavailable/failed**. (User policy — see failed-attempts.md \"0-findings\".)\n\n**Two engine layers (do not mix)**:\n\n| Layer | Engines | Purpose |\n|-------|---------|---------|\n| **Bot review layer** | CodeRabbit cloud, Copilot; **CodeRabbit CLI local as substitute when BOTH are unavailable** | External AI bot findings |\n| **Internal review layer** (Step 3.5) | **superpowers code-reviewer agent — always** | Second **independent** perspective (different engine from the bot layer) |\n\n**Why superpowers is the internal default**: CodeRabbit cloud + CodeRabbit CLI share the same AI engine. When any CodeRabbit review evidence already exists on the PR (walkthrough, prior CLI run), running CLI again duplicates the same engine and adds zero independent perspective — the internal review's purpose. The CLI's tier/visibility bypass matters only when the bot layer is empty.\n\n**Engine-duplication gate (HARD STOP — before running ANY review engine)**: enumerate engines that already produced review evidence on this PR (cloud walkthrough/summary comment, Copilot review, a prior CLI run recorded in the existing Internal Review comment or session tracker). Running an engine that already reviewed this PR = duplicate → **forbidden without an explicit user ask**.\n\n**Re-review exception — two bot reviews already in (operator policy)**: when the bot layer already carries **two independent engine reviews** on this PR, a further review is scoped to the **delta that findings-application produced** — and that re-review is **sufficient, not mandatory**. In that situation CodeRabbit CLI *is* permitted even though it duplicates the cloud CodeRabbit engine, because a re-review of applied fixes is a different act from a first review of the same diff. The duplication the gate above forbids is re-running an engine against a diff it has already reviewed; re-running it against the fixes made in response to its own findings is the intended use.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Treat a re-review of applied fixes as a duplicate run and refuse the CLI | Two bot reviews already present → CLI permitted for the findings-applied delta |\n| 2 | Make the delta re-review mandatory before the Summary can be posted | It is sufficient, not required. No applied findings yet = nothing to re-review = proceed |\n| 3 | Re-review the whole diff when only a subset of findings was applied | Scope the re-review to the applied delta |\n\n**Self-check (before invoking any engine on a PR that already has bot reviews)**: how many independent engines reviewed this PR? If two or more — is there an *applied-findings delta* to re-review? No delta → no re-review needed. Delta present → the CLI is an allowed engine for it, duplication notwithstanding.\n\n**CodeRabbit invocation-mode matrix** (self-contained — do not rely on external rule files):\n\n| Repo visibility | Cloud Free | Cloud Lite/Pro/Team | CLI local | superpowers code-reviewer |\n|-----------------|------------|---------------------|-----------|--------------------------|\n| PUBLIC | Walkthrough + line-by-line | Full (Pro+ adds advanced rules) | Full (CLI auth) | Full |\n| PRIVATE | **Walkthrough only / line-by-line blocked** | Full | Full (visibility-agnostic) | Full |\n| INTERNAL (Enterprise) | per org plan | Full | Full | Full |\n\nThe PRIVATE+Free row explains why cloud output may be walkthrough-only — but that alone does NOT route to CLI. Cloud walkthrough evidence = the CodeRabbit engine already reviewed → the internal review runs on **superpowers** (different engine). yaml updates do not unlock line-by-line on PRIVATE+Free; only plan upgrade does.\n\n**CLI-substitute procedure (ONLY when bot layer is empty — no cloud CodeRabbit evidence AND Copilot unavailable)**:\n\n1. Confirm the bot layer is empty:\n ```bash\n # CodeRabbit cloud evidence (walkthrough / summarize / zero-findings verdict)\n gh api repos/{owner}/{repo}/issues/{N}/comments \\\n --jq '[.[] | select(.user.login | test(\"coderabbit\"; \"i\"))] | length'\n # Copilot availability: pr.md Step 2.4 result\n ```\n Cloud evidence ≥1 OR Copilot available → **skip CLI entirely**; internal review = superpowers (Step 3.5).\n\n2. Bot layer empty → probe CLI availability + auth:\n ```bash\n command -v coderabbit && coderabbit auth status 2>&1 | head -3\n ```\n\n| Probe outcome | Action |\n|--------------|--------|\n| CLI installed + authenticated | Run `coderabbit review --agent -t all` in the worktree (from `pr.md` Step 2.7) → CLI output fills the **bot layer** (record as such in the reviewer matrix). The internal review (Step 3.5, superpowers) still runs on top |\n| CLI installed, not authenticated | AskUserQuestion: run `coderabbit auth login` (interactive) → after auth, retry probe. On user decline → bot layer stays empty; proceed with superpowers internal review only |\n| CLI not installed | AskUserQuestion: install CodeRabbit CLI (https://www.coderabbit.ai/cli) → after install, retry probe. On user decline → bot layer stays empty; proceed with superpowers internal review only |\n\n3. Reviewer matrix entry in Summary records the layers separately: bot layer (`CodeRabbit cloud` / `Copilot` / `CodeRabbit CLI local (substitute — bot layer empty)` / `none`) + internal layer (`superpowers code-reviewer`).\n\n**Don't / Do**:\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Run CodeRabbit CLI as the internal-review engine when cloud walkthrough-only triggered | Internal review = superpowers code-reviewer (default, always). CLI is a bot-layer substitute only when cloud evidence is absent AND Copilot is unavailable |\n| 2 | Run an engine that already produced review evidence on this PR (cloud walkthrough exists → run CLI; prior CLI run exists → run CLI again) | Engine-duplication gate: same engine twice = zero added perspective. Ask the user explicitly before any duplicate-engine run |\n| 3 | PATCH an existing Internal Review comment without Reading its current body first | Read the existing body. If it carries an accepted agent-based review, the replacement must supersede it with equal-or-greater verification depth — never overwrite it with tool-status output |\n| 4 | Use tool status lines (`findings: 0`) as the Internal Review body | The body must show what was verified and how (per-hunk verification notes). A zero-findings tool run is evidence, not a review |\n| 5 | Install CLI silently, or use CLI without `coderabbit auth status` check | Offer install/re-auth via AskUserQuestion — install + `coderabbit auth login` require user interaction |\n| 6 | Modify `.coderabbit.yaml` (cloud config) hoping to unlock CLI/agent capabilities | yaml is the cloud-config medium only. CLI/agent capabilities are mode-orthogonal — yaml has no effect on them |\n\n### Two rules pointing opposite ways is itself an ask trigger (HARD STOP)\n\nThe gates in this skill are written as HARD STOPs, which makes wording strength a tempting tie-breaker when two of them disagree. It is not one. When two artifacts — two topics, a topic and a verifier script, a skill and a workspace-level gate — give **opposite instructions for the same situation**, that contradiction is the finding, and resolving it by obeying whichever is phrased more forcefully hides it.\n\nStop and ask, presenting both instructions and what each would produce. Adopting the stronger-sounding one silently converts a documentation defect into a behavioural one, and the next run hits it again with no record that it happened.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Compare wording strength (HARD STOP vs a plain table row) and follow the louder one | Strength does not rank instructions. Surface the conflict and ask |\n| 2 | Pick one side, proceed, and leave the contradiction in place | The conflict is a finding — record it so the rule can be reconciled |\n| 3 | Read one gate's phrasing as license to manufacture a trigger another gate says is absent | A routing/verification requirement presupposes its trigger; it never creates one |\n\n**Self-check (whenever two gates seem to apply and disagree)**: can I satisfy both at once? If no, am I about to choose by phrasing strength? Then ask instead — and note which two artifacts conflicted.\n\n**Self-check (before dispatching any review engine in Step 3.5)**:\n\n1. Which engines already reviewed this PR? (cloud comments, Copilot reviews, prior CLI runs in the existing Internal Review comment / session tracker) — enumerate before choosing\n2. Is the candidate engine a duplicate of an existing one? → If yes, STOP — explicit user ask required\n3. Is the bot layer empty (no cloud evidence AND Copilot unavailable)? → Only then is CLI a legitimate substitute; otherwise internal review = superpowers only\n4. Before PATCHing an existing Internal Review comment, did you Read its current body and confirm the new body supersedes (not degrades) it?\n5. Reviewer matrix line in Summary names both layers (bot layer engines + internal layer superpowers)?\n\n---\n\n## Step 3.5: Internal Review Fallback\n\n**Trigger conditions** (run fallback if any of these apply):\n- **CodeRabbit is walkthrough only** (line-by-line blocked — e.g., PRIVATE+Free per the invocation-mode matrix above; note PUBLIC+Free does provide line-by-line, so it does not trigger this fallback)\n- **Reviewer failure/error** — review is impossible such as Copilot \"encountered an error\"\n- **Copilot subscription unavailable** — `pr.md` Step 2.4 availability pre-check returned not-available (free account / no org seat / 404 on `/user/copilot_billing` and `/orgs//copilot/billing`). **This is the auto-fallback path — no AskUserQuestion required.** Record the substitution in the Summary's reviewer matrix (e.g., \"Copilot unavailable on the acting account/org — auto-fallback per Step 2.4\")\n\n**Worktree (from Step 2.7)**: the PR branch is already checked out into a worktree by `pr.md` Step 2.7. Dispatch the code-reviewer **against that worktree path** so it reads real files (not just `gh pr diff`) and can run tests/build locally. Pass the worktree path in the agent prompt (`Repository: `). The reviewer should still use `gh pr diff ` for the canonical PR diff, but reads file bodies + runs verification in the worktree.\n\n### Pre-dispatch gate — the failure history selects the starting rung (HARD STOP)\n\nThe ladder below is **reactive**: it says what to do after a dispatch fails. That wastes a dispatch when the failure is already known to be deterministic in this environment. **Before the first dispatch**, grep the recurrence store for this dispatch's failure class and read the result as a rung selector:\n\n```bash\ngrep -rn --include=\"*.md\" -oE \"\" \\\n \"${FA_DATA_DIR:-$HOME/.claude/skills/cleanup/data}\"\n```\n\n| Standing history | Start at |\n|---|---|\n| No matching class, or `count` ≤ 2 | Rung 1 |\n| `count` ≥ 3 and the recorded failure mode matches what you are about to do | **Skip Rung 1 — start at Rung 2, or Rung 3 if Rung 2 is unavailable** |\n| Class has a recorded mitigation you have not applied | Apply it first; then Rung 1 counts as one attempt |\n\n**Established about `Prompt is too long` on this dispatch — do not re-litigate (measured 2026-09-28)**: it reproduces across **both** model tiers, across **both** tool-set sizes (a `Tools: *` agent and an 8-tool agent), with a ~500-byte prompt, and after the subagent merely read one 54KB file. The binding constraint is the **subagent's own context budget** — not caller prompt length, not model tier, not tool-schema size. Two corollaries: passing a long brief by file path instead of inline does **not** help (the bytes move from the prompt into a `Read`, which the subagent still holds), and **per-file payload chunking is a closed direction** (tried and failed twice).\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Dispatch first, consult the history only after it fails | Consult first — the history selects the rung |\n| 2 | Note a recorded class as a caveat and dispatch anyway | `count` ≥ 3 with a matching mode is an instruction to skip Rung 1 |\n| 3 | Treat the checklist gate's tracker read as covering this | That gate asks \"is this issue tracked?\"; this one asks \"is the **method I am about to use** recorded as broken?\" |\n| 4 | Re-test the tier or tool-set axis to confirm | Both axes are closed above — re-testing spends a dispatch on a known result |\n\n**Self-check (before the first `Agent` dispatch here)**: did I grep for this failure class *this session*; what `count`/`status` returned; does it select Rung 1 or lower; and am I actually starting at the rung it selected?\n\n**Enforcement**: `hook-kit/resources/block-agent-redispatch-after-overflow.js` (PreToolUse:Agent) denies a second dispatch once one has already overflowed in the session. To dispatch while genuinely moving down the ladder, put `[rung-escalated]` in the prompt (a trailing reason is fine in either spelling).\n\n**Fallback procedure:**\n\n1. **Call `Skill(\"superpowers:requesting-code-review\")` (MANDATORY)** — this skill loads the review framework and includes code-reviewer agent dispatch. When the skill returns the review result, proceed to the \"Check existing review comment\" and \"Post/update review comment\" sub-steps below (still within Step 3.5).\n2. **In-session agent path unavailable → dispatch to a clawo session (do NOT abandon the review)**: if the `code-reviewer` agent path does not run in this session (Agent tool unregistered, the dispatch stalls, or repeated attempts fail), do not drop the Internal Review — dispatch the entire consolidate to a fresh **clawo session** (the `clawo` skill `launch` topic: `session-start` in the repo cwd + `session-send \"consolidate \"`), which runs consolidate autonomously with the project's `.claude/` rules. Pre-bake the verdict/medium gates in the dispatch message (autonomous sessions cannot `AskUserQuestion` — see `clawo/launch.md` Step 5a). Abandoning the review because the in-session agent stalled — and pivoting to unrelated work — is the exact drift this fallback prevents.\n3. **Dispatch succeeded but the agent reported nothing → escalate on a bound (HARD STOP)**: the failure mode that stalls this step most quietly is not an unavailable agent — it is a *successful* dispatch whose agent ends idle with no result. There is no error to catch, so a caller waiting on the report simply stops and the consolidate never reaches Step 4, with no trace of why. Treat all of these as the same condition: the dispatch returns an agent id but no completion notification arrives; the agent reaches a terminal state with an empty final message; the agent's transcript exists but carries no review body.\n\n Escalation ladder — take the next rung as soon as the current one yields no review body, and never let the sequence exit without a posted comment:\n\n | Rung | Action | Leaves this rung when |\n |------|--------|-----------------------|\n | 1 | Re-dispatch **once**, restating the worktree path and the `gh pr diff ` command in the prompt | A review body is returned |\n | 2 | Dispatch the whole consolidate to a fresh clawo session (item 2 above) | A review body is returned |\n | 3 | Self-analyse inline and post under the same title template, per Don't `#4` below | Always — this rung cannot fail |\n\n Whichever rung produces the body, **name the engine that produced it in the body's opening line** (e.g. \"the superpowers code-reviewer dispatch went idle twice without reporting, so per Don't `#4` this is a self-analysed review\"). A reader must be able to tell a subagent review from a self-analysed one; presenting rung 3 output as rung 1 output misrepresents the review's independence — the second perspective is the whole reason Step 3.5 exists.\n\n | # | Don't | Do |\n |---|-------|-----|\n | 1 | Keep waiting on a dispatched agent that has already gone idle, or re-dispatch repeatedly hoping for a different outcome | One re-dispatch, then move down the ladder. Repeated identical dispatches are the stall, not a recovery from it |\n | 2 | Read \"the agent returned nothing\" as \"there was nothing to report\" | An empty result is a failed dispatch, not a clean review. A clean review still has a body — \"no actionable findings\" plus what was verified and how |\n | 3 | Pivot to other work while the review is \"waiting on the agent\" | Rung 3 always terminates. There is no state in which this step legitimately stays open |\n | 4 | Post rung 3 output without disclosing the substitution | State the engine and the reason in the body's opening line, and record it in the Summary's reviewer matrix |\n\n**Prevention tooling never substitutes for the POST (HARD STOP)**: if a non-compliant / garbage review comment is discovered on the PR, correcting the *process* (building a guard hook, adding a lint, filing a prevention task) does NOT complete this consolidate. The compliant `## AI Review Summary — [receiving-code-review](...)` must still be posted for this PR. A prevention effort spawned from a consolidate gap is additive work, never a substitute for the object deliverable — do not treat the consolidate as done until the Summary is on the PR.\n\n| # | Don't | Do (correct alternative) |\n|---|-------|-------------------------|\n| 1 | Dispatch `Agent(subagent_type: \"code-reviewer\")` directly | Call `Skill(\"superpowers:requesting-code-review\")` → skill includes agent dispatch |\n| 2 | Classify review based on code-reviewer result alone | Apply both the requesting-code-review skill framework + receiving-code-review verify→evaluate→respond |\n| 3 | **Analyze 18 files directly from chat text and jump to Step 7** (Step 3.5.3 comment posting omitted) | **`## Internal Code Review — [requesting-code-review](...)` comment must exist on GitHub** to enter Step 4. Chat analysis is auxiliary; comment posting is the primary medium |\n| 4 | \"Trigger satisfied but superpowers skill not installed, so substitute with self-analysis\" | Internal Code Review comment posting is mandatory even without the skill — if the superpowers skill call fails, post the self-analyzed result as a comment using the same title template (skill bypass allowed, comment bypass forbidden) |\n| 5 | \"CodeRabbit findings are detailed enough — verify them myself and skip the Internal Review skill call\" | Trigger condition is satisfied **independent of CodeRabbit's quality**. The Internal Review's purpose is to add a *second independent perspective*, not to compensate for missing detail. Detail quality of an existing reviewer does not dismiss the trigger. Always invoke `Skill(\"superpowers:requesting-code-review\")` when the trigger condition matches |\n| 6 | User says \"fall back to internal-review on Copilot rate-limit\" → interpret as \"I verify CodeRabbit findings personally\" | \"Internal-review\" = the **superpowers code-reviewer skill**, not self-verification. User's args reinforce the trigger; they do not authorize self-substitution |\n\n### Self-check (always before entering Step 5 AND Step 7 — HARD STOP)\n\nTwo gates: Step 5 (User Decision ask) and Step 7 (Summary post). Both forbid entry without the Internal Review comment when the trigger matches.\n\nBefore posting **either** the Step 5 AskUserQuestion **or** the Step 7 `## AI Review Summary`, run the following self-check:\n\n1. Was the state CodeRabbit walkthrough only (line-by-line blocked — e.g., PRIVATE+Free), a reviewer error, or Copilot subscription unavailable (Step 2.4 auto-fallback)? → If Yes, Step 3.5 trigger is satisfied\n2. If trigger was satisfied, was a `## Internal Code Review` comment posted on the GitHub PR? → `gh api .../issues/{N}/comments | jq '.[] | select(.body | startswith(\"## Internal Code Review\"))'`\n3. If the comment is absent → **forbid entering Step 5 or Step 7**. Return to the Step 3.5 procedure and post the comment first\n4. Does the comment body contain dual-label findings (Type | Severity) or their equivalent?\n\n**Why Step 5 also gated**: the user's decision options must reflect both reviewer streams (CodeRabbit + Internal). Posting Step 5 ask with only CodeRabbit findings + self-verified Reject/Accept classifications leaves the user without the second independent perspective that justified the consolidate flow. Re-call Step 5 ask after the Internal Review comment exists.\n\n### Medium decision (MANDATORY — inline targets decide the posting medium)\n\nThe Internal Review's posting medium branches on whether **inline targets** exist (auto-fire policy below: line-specific 🔴 Critical + 🟠 Important findings by default; ALL line-specific findings with the `--inline` flag):\n\n| Inline targets | Medium | First post (no prior Internal Review) | Re-review (prior Internal Review exists) |\n|----------------|--------|----------------------------------------|------------------------------------------|\n| **1+ exist** | **Single reviews API POST** — `gh api POST .../pulls/{N}/reviews`: `body` = full Internal Review findings, `comments[]` = inline annotations | First `gh api POST .../reviews` — no PATCH target exists yet | **New review POST every time** (no PATCH/PUT of the prior review — each re-review is a fresh time-ordered review, like external bots) |\n| **None** | Issue comment (`gh pr comment`) | First `gh pr comment ` — no PATCH target exists yet | **PATCH the existing comment** (`gh api repos/{owner}/{repo}/issues/comments/{id} --method PATCH --input `) — forbid a parallel new comment |\n\n**Merge state does not change the medium (HARD STOP).** A merged or closed PR still takes the reviews API POST with `comments[]` inline when inline targets exist — the auto-fire policy (line-specific 🔴 Critical + 🟠 Important → review POST) applies **regardless of merge state**. The reviews API accepts inline comments on a merged PR against its head SHA. A post-merge review is still a review POST, not an issue comment. Do NOT downgrade to `gh pr comment` because the PR is merged.\n\n**Existing-artifact check before posting** (per medium):\n\n```bash\n# Issue-comment medium: find prior Internal Review comment (PATCH target)\ngh api repos/{owner}/{repo}/issues/{N}/comments --jq '.[] | select(.body | test(\"Internal Code Review\")) | \"\\(.id) \\(.updated_at)\"'\n# Review medium: prior reviews are left as-is (time-ordered records) — no check needed beyond counting for the re-review note\n```\n\n| # | Don't | Do (correct alternative) |\n|---|-------|-------------------------|\n| 1 | Post the full findings as an issue comment AND a stub-body inline review (2 artifacts, body pointing at the comment) | One reviews API POST carrying both: full findings in `body` + line annotations in `comments[]` |\n| 2 | PATCH/PUT a prior review's body on re-review | Re-review with inline targets = new review POST every time |\n| 3 | Add a parallel issue comment when a prior Internal Review comment exists (no-inline medium) | PATCH the existing comment |\n| 4 | Ask the user which medium to use at runtime | The inline-target count decides the medium deterministically |\n| 5 | Downgrade to an issue comment because the PR is merged/closed (post-merge review) | Merge state is irrelevant — reviews API POST + `comments[]` works on merged PRs (against head SHA). Apply the auto-fire policy regardless of merge state |\n\n### Post the Internal Review (MANDATORY — must complete before entering Step 4)\n\nPost the code-reviewer result via the medium decided above. **The review (or comment) must exist on the PR before proceeding to Step 4** — substitution with a text report is forbidden.\n\n#### Interactive gate (when `--interactive` is on — literal or auto-activated by args)\n\nBefore the POST step (the title-template + medium-decided POST in the rest of this Step 3.5 procedure), the caller MUST follow the **Interactive flow contract** defined in `SKILL.md`:\n\n1. Write the Internal Review body to `.tmp/internal-review-draft.md` (do not POST yet)\n2. Emit a chat summary (finding counts per Severity + verdict line + draft path)\n3. Call `AskUserQuestion` with options: `Approve as-is` / `Edit (specify in Other)` / `Reject — do not POST`\n4. Apply user edits → re-present → re-ask, until Approve or Reject\n5. On Approve, proceed to the medium-decided POST in the rest of Step 3.5. On Reject, skip the POST and record the reason in chat.\n\nIf `--interactive` is off, proceed directly to the medium-decided POST (deterministic flow). Inline annotation bodies (per \"Inline auto-fire policy\" below) are part of the draft and reviewed in the same ask — do not POST inline comments separately under interactive mode.\n\n**Title template (MANDATORY — first line of the review body / comment body)**:\n```markdown\n## Internal Code Review — [requesting-code-review](https://skills.sh/obra/superpowers/requesting-code-review)\n\n```\nDo not write `code-reviewer` as plain text; use the link format above. The `` HTML comment on the second line is an invisible machine-readable provenance marker: it renders as nothing on GitHub but lets the `block-noncompliant-review-comment` guard (client hook + server Action) confirm the comment came through consolidate even if the `requesting-code-review` link text is ever reworded.\n\n**Bot-layer content in the body drops the suffix (HARD STOP — 3rd recurrence of mixing bot-layer content into this artifact)**: the `— [requesting-code-review](...)` suffix is a provenance claim — \"this artifact is the superpowers requesting-code-review framework's own output.\" If the body includes ANY bot-layer finding (CodeRabbit CLI local substitute, or any other bot-layer engine), as its own section OR merged into the findings list with a `Source` label — the suffix is false and must be dropped. Use a plain title instead: `## Internal Code Review (CodeRabbit CLI + superpowers code-reviewer)` (name the actual engines that contributed). The `` marker still applies regardless of title wording.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Keep the `[requesting-code-review]` suffix while merging a CodeRabbit CLI (bot-layer substitute) finding into the same findings list, distinguished only by a `Source` column | Drop the suffix; title names the actual contributing engines |\n| 2 | Assume this only applies to the \"add a separate CodeRabbit CLI section\" pattern (the 2nd recurrence's exact shape) | Applies whenever bot-layer content appears anywhere in the body — a merged/unified findings list is the same violation with different formatting |\n| 3 | Leave a previously-posted review's title unfixed after discovering bot-layer content was included | Update the review body via `gh api -X PUT repos/{owner}/{repo}/pulls/{N}/reviews/{review_id}` (reviews ARE PATCH/PUT-able for body text, unlike the state) |\n\n#### Caller-supplied custom title contract (HARD STOP)\n\nWhen the consolidate caller passes a custom title for this review (e.g. args \"rename Internal Review → Code Review\" / \"title it Superpowers Review\"), the retitle applies **only to this Code Review comment's heading text** — the `— [requesting-code-review](...)` link suffix stays. The retitle does **NOT** merge this comment into the Summary, and does **NOT** change the separate AI Review Summary (Step 7) title.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Fold the retitle into a single \" Summary\" comment combining Code Review + Summary | Two separate comments always (see \"Review comment ≠ AI Review Summary\"). Retitle only this Code Review comment's heading |\n| 2 | Put \"Summary\" / \"AI Review Summary\" in this comment's title because the custom title sounds summary-like | **Forbid the token \"Summary\" in this comment's heading** — \"Summary\" belongs to the separate Step 7 comment only. Heading = `## — [requesting-code-review](...)` (e.g. `## Code Review — [requesting-code-review](...)`) |\n| 3 | Drop the `[requesting-code-review](...)` link when applying the custom title | Keep the link suffix — it pairs with the Summary's `receiving-code-review` link |\n| 4 | Apply the caller's retitle to the Step 7 Summary heading too | Summary keeps `## AI Review Summary — [receiving-code-review](...)`. The retitle is scoped to this Code Review comment |\n\n**Self-check (when a caller custom title is supplied)**: ① two comments, not one? ② this comment's heading = `## — [requesting-code-review](...)` with NO \"Summary\" token? ③ Summary heading unchanged (`## AI Review Summary — [receiving-code-review](...)`)?\n\n#### 🌐 Verify repository default language before posting (MANDATORY)\n\nSubagents (code-reviewer, etc.) tend to output in English. If different from the target repository's default language, **translate before posting**.\n\n```bash\n# 1. PUBLIC repo check (opensource.md \"PUBLIC English enforced\")\nGH_TOKEN=\"$(gh auth token --user )\" gh repo view / --json isPrivate -q '.isPrivate'\n# false → post in English only (HARD STOP if Korean detected, retry after English translation)\n# true → proceed to next step\n```\n\n```bash\n# 2. Check private repository default language (sample recent PR/issue/commit bodies)\nGH_TOKEN=\"$(gh auth token --user )\" gh pr list -R / --state all --limit 5 --json title,body | grep -P '[\\x{ac00}-\\x{d7a3}]' | head -3\n# Korean match → Korean default repository\n# No match → English default or new repository\n```\n\n**Translation procedure** (subagent English output → Korean default repository):\n- Translate body to Korean before posting (keep code blocks, identifiers, and file paths in their original form)\n- Keep dual-label labels (`🔴 Critical`, `⚠️ Potential`, `🟡 Minor`, etc.) as-is since they are standard\n- Technical terms (rename, slug, consumer_key, terraform apply, etc.) may remain in English within Korean context\n\n**Self-check** (just before posting):\n1. Which is dominant in the body, Korean or English?\n2. Does it match the repository's default language?\n3. If mismatched, translate immediately → re-run the self-check\n\n**Forbidden pattern**: Copy-pasting subagent English output directly into a Korean default repository. Do not bypass with \"technical reviews feel natural in English\" reasoning.\n\n### Inline auto-fire policy (no runtime ask)\n\nWhen inline targets exist, the single reviews API POST carries them in `comments[]` so the author sees each finding on the exact line in the GitHub UI. **This fires automatically by the policy below — do NOT ask the user at runtime.**\n\n**Auto-fire policy** (this decides the medium — see \"Medium decision\" above):\n\n| Invocation | Inline targets |\n|------------|----------------|\n| Default (no flag) | Line-specific 🔴 Critical + 🟠 Important findings only |\n| `--inline` flag on the consolidate call | ALL line-specific findings (Minor/Refactor included) |\n| No line-specific finding matches the policy | No review POST — issue-comment medium |\n\n**Fallback (diff-scope / line verification)**: a finding whose file is not in the PR diff, or whose line cannot be verified against PR head (`git show :`), is **demoted to review-body text only** — never force an inline comment for it (422 risk). No finding is dropped. If ALL inline candidates demote this way, the medium falls back to issue comment.\n\n**Mechanics**: head SHA fetch, JSON payload format, `comments[]` fields, and verification follow `post.md` \"Optional Inline Review\" procedure (event = `COMMENT`). The `body` field of the same POST carries the full Internal Review findings (title template + strengths + findings + assessment).\n\n| # | Don't | Do (correct alternative) |\n|---|-------|-------------------------|\n| 1 | Ask the user \"post inline review?\" at runtime | Apply the auto-fire policy table deterministically. The only user control is the `--inline` flag at invocation |\n| 2 | Inline-annotate every finding by default | Default = Critical + Important line-specific only. ALL requires the explicit `--inline` flag |\n| 3 | Force inline for a finding outside the PR diff | Demote to review-body text (fallback row above) |\n| 4 | Put a stub/pointer body in the review POST and the full findings elsewhere | The review POST `body` IS the Internal Review — full findings live there |\n\n### Mandatory self-check before entering Step 4 (HARD STOP — run on every invocation)\n\nStep 4 may proceed only if both conditions below are satisfied:\n\n1. **Verify posted-artifact URL**: per the medium — review medium: `gh api repos/{owner}/{repo}/pulls/{N}/reviews` contains this session's review (body starts with \"## Internal Code Review\"); comment medium: `gh api .../issues/{N}/comments` contains this session's comment.\n2. **No self-reporting**: Reporting the classification result as text does not equal posting. **The review/comment must be visible on the PR page** to count as posted.\n\nIf unmet, **immediately return to Step 3.5.3** and post via the decided medium. After posting, print the URL → proceed to Step 4.\n\n**Forbidden pattern**:\n- Outputting only a classification table of code-reviewer results as text → jumping to the user with \"scope of changes?\" (Step 5 position)\n- \"Classification is clear, so skip posting the comment\" reasoning\n- \"User will respond anyway, so post later\" reasoning\n\n### Review comment ≠ AI Review Summary (HARD STOP — 6 recurrences, latest 2026-06-26)\n\nThe Internal Review is a Copilot substitute (detailed findings); the Summary is the overall reviewer consolidation (table). **Always post as 2 separate posts** — the Internal Review medium follows the \"Medium decision\" table above (review POST when inline targets exist / issue comment otherwise), while the Summary's medium (issue comment vs Formal Review body) is decided by `post.md` Step 7. The \"single combined post\" pattern (Internal Review inlined into the Summary body) is deprecated.\n\n**Why always 2 posts**: At the Step 5 AskUserQuestion moment, the user must see the review content to decide. The \"inline integration when posting Summary\" pattern leaves no review medium present at ask time, preventing user decisions. The Internal Review is always posted first, independent of the Summary decision.\n\n| Condition | Post count | Posting order |\n|-----------|--------------|---------------|\n| External AI review exists (Copilot/CodeRabbit Pro) + Internal fallback | 2 | Internal Review → Summary |\n| **Internal fallback only (sole source)** | **2** (do not merge into 1) | Internal Review → Summary |\n| External AI only without Internal Review | 1 | Summary only |\n\n| # | Don't | Do (correct alternative) |\n|---|-------|-------------------------|\n| 1 | \"Internal fallback is the sole source, so inline-merge into the Summary\" reasoning | Post the Internal Review first → then post the Summary separately. Keep media separated |\n| 2 | At Step 5 ask time, show review content only via chat text | Post the Internal Review on the GitHub PR right before Step 5 ask — its URL may be included in the ask option description |\n| 3 | Step 4 → Step 5 direct jump (Step 3.5.3 posting omitted) | Strictly follow the order: Step 3.5.3 posting → Step 4 classification → Step 5 ask |\n| 4 | A caller \"retitle Internal Review → X\" instruction → produce one \"X Summary\" comment merging Code Review + Summary (2026-06-26 6th recurrence — collect→post topic skip; internal.md never read) | Caller retitle scopes to the Code Review comment heading ONLY (see \"Caller-supplied custom title contract\"). Still two comments. \"Summary\" token forbidden in the Code Review heading |\n| 5 | Reach post.md (Summary) without having read internal.md → never see this 2-comment rule | Follow the consolidate step order: read internal.md (Step 3.5) **before** post.md (Step 7). post.md Step 7 also hard-gates on the Code Review comment pre-existing |\n\n### Reviewer failure detection\n\nIn the reviews array, if a COMMENTED-state review's body contains text such as \"encountered an error\" or \"unable to review\", classify that reviewer as failed (e.g., bodyLen ~117 chars, \"Copilot encountered an error and was unable to review this pull request\").\n\n**Variety of normal review formats (false positive caution)**:\n\nCopilot review bodies are naturally posted in different formats depending on PR complexity. All of the following are recognized as normal reviews:\n\n- **Detailed format**: \"Pull request overview\" + \"Reviewed changes\" section + file table + inline comments\n- **Concise format**: \"Pull request overview\" + change summary + advertising link (simple PR with no actionables)\n- **Inline-comment style**: Large bodyLen + `
Comments suppressed due to low confidence` section + 1+ inline comments\n\n**Absence of `Reviewed changes` section ≠ partial failure**. Example of actual normal case (PR #110 merged): bodyLen 2040, hasReviewedChanges:false, \"Comments suppressed\" + 1 inline. Trust only explicit error keywords (\"encountered an error\", \"unable to review\") for partial failure detection.\n\nThis ensures PRs always get substantive review even when external AI tools provide limited feedback or are completely unavailable.\n\n### Procedure violation prevention\n\nStrictly enforce the order Step 3.5 → Step 4 → Step 5 → Step 7. Do not skip the review comment (Step 3.5.3) and jump to Step 5 (Summary approval). **Proceeding to post the Summary while the review comment is not yet posted on the PR = procedure violation.**\n\nInclude the posted review as the primary review source for Step 4 (`classify.md`). Reference with `code-reviewer` attribution in the AI Review Summary (Step 7, `post.md`).\n\n## Step 4.5: UI Change PR Capture Verification (HARD STOP — reviewer's duty)\n\n**The reviewer must classify a PR as an actionable item if it is a UI change PR with no capture attached.** When the author omits the capture-attachment duty, calling it out is part of the review.\n\n### UI change detection\n\n```bash\ngh pr diff -R --name-only | grep -E '\\.(tsx|jsx|svelte|vue|css|scss)$|^(app|pages|routes)/'\n```\n\nIf matched, it is a UI change PR — subject to capture-attachment verification.\n\n### Capture absence check\n\n```bash\n# Search PR body + all comments for image/capture patterns\ngh pr view --json body,comments --jq '.body, (.comments[].body)' | grep -cE '!\\[.*\\]| **Formal Review event for peer reviewer** (author ≠ me, non-requested): the Formal Review event decision (APPROVE / COMMENT / REQUEST_CHANGES) is **NOT** part of Step 8 next-action options — it is handled at Step 7 Summary POST per `post.md` \"Non-requested reviewer event policy\". Critical > 0 → REQUEST_CHANGES auto; merge gate failures → COMMENT auto; APPROVE candidate → ask. Step 8 next-action ask runs AFTER the Formal Review POST and asks the post-review follow-up (relay deferred findings to author / hold / done) — never re-asks the Formal Review event.\n\n```bash\n# Pre-check before merge-option composition\nAUTHOR=$(gh pr view -R / --json author --jq '.author.login')\n\n# The comparison target is the API identity of the gh account being used for THIS repo\n# (per ~/.agents/rules/git.md account mapping: es6kr → DrumRobot, an internal workspace org → its mapped account).\n# Do NOT use `gh auth status` \"active\" account — when multiple accounts are logged in,\n# the active one can differ from the account whose token is actually being used for the repo.\n# Do NOT use `git config user.email` — commit identity ≠ GitHub API identity.\nACCOUNT_FOR_REPO=$( # the gh user matching the repo owner per git.md mapping\n case \"\" in\n es6kr) echo DrumRobot ;;\n ) echo ;;\n *) gh auth status 2>&1 | awk '/Logged in/{print $7; exit}' ;;\n esac\n)\nME=$(GH_TOKEN=\"$(gh auth token --user \"$ACCOUNT_FOR_REPO\")\" gh api /user --jq '.login')\n# Mismatch ($AUTHOR != $ME) → no merge option\n```\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Present \"Squash merge (Recommended)\" on a PR authored by someone else | Author ≠ me → omit merge options entirely. Offer review-scoped options only (relay deferred findings to author / hold / done) |\n| 2 | \"4 merge conditions met → recommend merge\" regardless of authorship | 4-condition check is necessary but not sufficient. Authorship is a prerequisite gate for any merge option |\n| 3 | Treat APPROVE on another's PR as license to drive the merge | APPROVE satisfies the review request; the merge decision/timing belongs to the author |\n| 4 | Offer \"apply Minor then merge\" on another's branch | Code changes on another's branch are forbidden (branch ownership). Deferred findings are already in the Internal Review comment for the author |\n\n**Self-check (before composing options on a consolidate-completed PR)**:\n1. `gh pr view --json author` → capture `$AUTHOR`.\n2. Resolve `$ACCOUNT_FOR_REPO` per the owner → account mapping (`~/.agents/rules/git.md`), then `$ME = gh api /user --jq '.login'` with that account's token. **Do not** compare against `gh auth status` \"active\" account or `git config user.email`.\n3. If `$AUTHOR != $ME` → merge options forbidden. Options = \"relay deferred findings to author / hold / done (review complete)\". Report APPROVED state + that merge is the author's call.\n4. If `$AUTHOR == $ME` → proceed to the merge-condition option guide below.\n\n### Option composition guide (single PR — next skill, **own-authored PRs only**)\n\nTo pass the `block-merge-without-review.sh` guard, **the merge option description must explicitly include \"AI Review Summary posted (URL)\"**.\n\n**Merge-method precheck before labeling any option \"Squash merge\" (HARD STOP)**: before composing a \"Squash merge\" option label, run `github-flow/merge.md`'s condition-6 \"Merge-method policy pre-check\" (release-please/changesets marker detection) — do not defer this check to the later `/github-flow merge` invocation. A \"Squash merge\" label composed here reaches the user as a recommendation before that later gate runs; if the repo turns out to require merge-commit (release-please parses individual Conventional Commits), the recommendation itself was already wrong.\n\n```bash\ngh api graphql -f query='{repository(owner:\"\",name:\"\"){viewerDefaultMergeMethod mergeCommitAllowed squashMergeAllowed}}'\n# Signal: .release-please-manifest.json / release-please-config.json / .changeset/ at repo root\n```\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Compose a \"Squash merge\" option label first, run the merge-method check only inside the later `/github-flow merge` invocation | Run the release-please/changesets marker check in this step, before the option label is written — label \"Merge commit\" instead when the marker is present |\n| 2 | Treat \"the 6-condition self-check in merge.md will catch it later\" as sufficient | That check is a pre-merge gate on the already-approved recommendation, not a substitute for composing the correct recommendation in the first place |\n| 3 | Recommend \"Squash merge\" from the release-marker branch alone when the queried `squashMergeAllowed` is `false` (repo setting disables it) | Branch on the queried capabilities (`mergeCommitAllowed`/`squashMergeAllowed`, and `rebaseMergeAllowed` if rebase is a supported fallback) **before** the release-marker branch — recommend only a method the repo actually allows |\n\n**Capability branch precedes the marker branch**: the GraphQL query above returns the repo's actual allowed methods. If the release-marker branch would recommend a method the repo disables (e.g. `squashMergeAllowed: false` with no release-please/changesets marker), fall back to whichever of `mergeCommitAllowed`/`rebaseMergeAllowed` is `true` instead — matching the capability policy in `skills/github-flow/merge.md`'s condition-6 pre-check.\n\n| Merge 4-condition satisfaction | Recommended options (Recommended at top) |\n|-------------------------------|------------------------------------------|\n| 4/4 satisfied, no release-please/changesets marker, `squashMergeAllowed: true` | (1) Squash merge — AI Review Summary posted (URL) (2) Apply Minor then merge (3) Defer |\n| 4/4 satisfied, no release-please/changesets marker, `squashMergeAllowed: false` | (1) Merge commit (or Rebase merge, whichever the repo allows) — AI Review Summary posted (URL) (2) Apply Minor then merge (3) Defer |\n| 4/4 satisfied, release-please/changesets marker present | (1) Merge commit — AI Review Summary posted (URL) (2) Apply Minor then merge (3) Defer |\n| 1+ Test Plan unchecked | (1) Verify unchecked items (web-browser/curl) (2) File separate issue then merge (3) Defer |\n| 1+ CI failures | (1) Investigate CI cause (2) If failure unrelated to PR, file separate issue (3) Defer |\n| Formal Review unapproved | (1) Self-approve (2) Request reviewer (3) Defer |\n| AI Review Summary not posted | **Cannot reach this stage** — Step 7 requires posting |\n\n### Deferred Actionable tracking option (MANDATORY — when merging + Critical/Minor not applied)\n\nWhen pushing a merge while not immediately applying actionable items (Critical, Minor), the **tracking location must be explicitly stated in the option**. Vague descriptions like \"subject to separate PR\" are forbidden.\n\n**Tracking medium (checklist) branching (per workflow environment)**:\n\n| Environment detection | Tracking medium | Format |\n|----------------------|----------------|--------|\n| `{workspace}/.ralph/fix_plan.md` exists (Ralph autonomous) | fix_plan.md | `- [ ] [BLOCKED] [REVIEW_FEEDBACK] {reviewer}: {summary} — {action direction}` |\n| `{workspace}/checklist.md` exists (Ralph not in use) | checklist.md | `- [ ] [BLOCKED] {summary}` |\n| GitHub Issue collaboration workflow | Separate Issue | `gh issue create` — specify \"deferred from PR #N\" in title/body |\n| Handled by additional commit in the same PR | Separate commit | Do not use \"subject to separate PR\" — push to this PR |\n\n**`{workspace}` = the current consolidate session's own workspace, not the reviewed PR's repo (HARD STOP)**: when the PR under review lives in a different repo than the session's workspace, check the session workspace root for `checklist.md`/`fix_plan.md` — not a checkout of the PR's repo. See `post.md` Step 7.6 \"Workspace ≠ the reviewed PR's own repo\" for the Don't/Do detail.\n\n**Option description requirements**:\n\nWhen a merge option entails deferred actionable items, the description must include all of:\n1. AI Review Summary URL (passes block-merge-without-review.sh)\n2. **Tracking location of deferred items** (checklist / Issue number)\n3. **Form of deferred items** (`[BLOCKED]`, `[REVIEW_FEEDBACK]`, Issue title, etc.)\n\n**Deferred scope branching (MANDATORY — branching options required if 2+ actionable items)**:\n\nIf actionable items (Critical + Minor + Refactor) total 2 or more, do not create a single \"Critical only\" option; instead present **3-way branching options**:\n\n| Branch | Applicable case | description example |\n|--------|----------------|---------------------|\n| **Critical only deferred** | When Minor is applied immediately or decided to be ignored | \"Critical 1 item checklist [BLOCKED] + Minor ignored in this PR (No action)\" |\n| **Minor only deferred** | When Critical is applied immediately | \"Critical applied immediately + Minor in checklist [BLOCKED]\" |\n| **All deferred** | All actionable items handled in next session or separately | \"Critical + Minor all in checklist [BLOCKED]\" |\n\n**Option example (GitHub Issue environment, 1 Critical + 2 Minor)**:\n\n```typescript\n[\n {\n label: \"Merge PR + Critical only as separate Issue\",\n description: \"AI Review Summary posted (URL) | 1 Critical filed as new Issue + 2 Minor No action. squash merge\"\n },\n {\n label: \"Merge PR + all actionable as separate Issues\",\n description: \"AI Review Summary posted (URL) | Critical + Minor all filed as Issues × 3 (title: \\\"deferred from PR #N: {summary}\\\"). squash merge\"\n }\n]\n```\n\n**Don't / Do table**:\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Abstract description like \"subject to separate PR\" | Specify tracking medium (fix_plan.md/Issue/checklist) + form (`[BLOCKED]`, etc.) |\n| 2 | Push medium decision onto the user without autonomous determination | Auto-detect environment (whether `.ralph/fix_plan.md` exists) and present medium options |\n| 3 | Omit form of deferred items (`[BLOCKED]`, Issue title) | Indicate form inline in the option description |\n| 4 | Omit tracking location after \"Critical to be handled later separately\" | Bundle immediate registration in the tracking medium as a task right after merge |\n\n**Self-check (immediately before option drafting)**:\n\n1. Does the merge option entail 1+ unapplied actionable items?\n2. Has the tracking medium been determined per environment (whether `.ralph/` exists)?\n3. Does the option description include all of (a) AI Review Summary URL (b) tracking location (c) form?\n4. Is the post-merge tracking-medium registration bundled as a separate executable task?\n5. If actionable items total 2 or more, are all **3 branching options** included? (Critical only deferred / Minor only deferred / All deferred — matching the branching table above)\n6. Is \"All deferred\" always included as one of the recommended options regardless of the number of actionable items?\n7. **Reject findings axis check (HARD STOP)**: are there 1+ findings auto-classified as Reject in Step 4? → If yes, **Reject findings must appear as a user-override option** in this Step 8 ask. See \"Reject finding option mandate\" below\n8. **Risky-command self-check inside option description (HARD STOP)**: scan each option description for the following keywords. If any is present, **the keyword alone is NOT user authorization** — strip it or split into a separate AskUserQuestion explicitly asking for execution:\n - `rebase`, `git rebase`, `git pull --rebase`\n - `reset --hard`, `git reset`, `git branch -f`, `git update-ref`\n - `push --force`, `push -f`, `--force-with-lease`\n - `worktree remove`, `branch -D` (uppercase D)\n - `gh pr close`, `gh issue close`\n - any command listed in `~/.agents/rules/git.md` ask-required-commands section\n\n Rationale: option selection = \"bundle execution intent\" only. Each risky command inside the bundle needs separate explicit authorization — `git.md` \"option-description keyword is not explicit instruction\" rule. See `failed-attempts.md` \"option description rebase auto-execution\".\n9. **PR scope analysis source (HARD STOP)**: if the option references \"PR diff scope\", \"PR files\", \"what PR modified\", verify against `gh pr view --json files` (canonical). Forbidden sources for PR scope: `git diff a..b --name-only` (two-dot = bidirectional, includes files main added but PR did not absorb). Cross-check with `git log ..HEAD -- ` per finding. Mismatch between `gh pr view --json files` (PR-touched) and `git diff a..b` (bidirectional) = signal that the finding may misattribute main's change to PR — see `failed-attempts.md` \"two-dot diff PR scope misinterpretation\".\n\n### Cross-PR Epic bundling auto-suggest (offer when deferred findings accumulate across PRs)\n\nAfter registering this PR's deferred items in the tracking checklist, check whether the checklist now holds un-bundled deferred findings spanning **2+ distinct PRs**. If so, add one extra (non-merge) next-action option offering to bundle them into a single Epic tracking issue:\n\n| Condition | Extra option |\n|-----------|-------------|\n| 2+ PRs with un-bundled `[REVIEW_FEEDBACK]` deferred items in the checklist | \"Bundle deferred findings into an Epic tracking issue\" |\n\n- This is an **offer**, not an auto-run — Epic issue creation needs explicit user approval (`git.md` no-autonomous-issue-create). The caller selects whichever epic-bundling workflow is registered in the environment (vendor-agnostic — `gh issue create` with sub-issue links is the minimal path).\n- Do not add this option when only the current PR has deferred items — single-PR deferral is already covered by the section above.\n\n### Reject finding option mandate (HARD STOP)\n\n**A Reject decision must also be user-overridable.** Even if Step 4 auto-classified a finding as Reject via the `superpowers:receiving-code-review` \"Push back when wrong\" procedure, the Step 8 next-action ask must **expose that Reject decision to the user**. If Reject disappears from the options, the user cannot choose \"apply it anyway\" / \"keep it Rejected\" → Resume scope shrinks.\n\n#### Don't / Do table\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | After auto-classifying Reject in Step 4, fully exclude the Reject finding from the Step 8 ask options | Expose the Reject finding to the user as a separate option or axis. The user can decide to override Reject |\n| 2 | \"The Reject rationale (repo convention, etc.) is clear, so omitting the option is OK\" thinking | Even with a clear rationale, the user decision step is separate. Reject = AI judgment, override = user authority |\n| 3 | Assume \"Accept/Defer options alone are enough\" | Present all three to the user: Accept option / Defer option / **Reject override option** |\n| 4 | Assume \"the Push back when wrong procedure has no user-confirmation step, so auto-Reject is OK\" | superpowers is an evaluate→respond framework. The Step 8 ask is the final decision gate. Two separate domains |\n\n#### Option design pattern (when a Reject finding exists)\n\n```typescript\n[\n {\n label: \"Apply Accept findings + Reject as-is (Recommended)\",\n description: \"AI Review Summary posted (URL) | Accept N items applied + Reject M items kept (reason: )\"\n },\n {\n label: \"Apply ALL findings (override Reject)\",\n description: \"AI Review Summary posted (URL) | Accept N + Reject M (override — user decided to apply despite the pushback reason)\"\n },\n {\n label: \"Defer all findings\",\n description: \"AI Review Summary posted (URL) | fix_plan [BLOCKED] [REVIEW_FEEDBACK] for Accept N + Reject M (override option preserved)\"\n },\n {\n label: \"Hold\",\n description: \"Decision pending\"\n }\n]\n```\n\nA **Reject-only application option** is also possible (e.g., Accept defer + Reject override):\n```typescript\n{\n label: \"Override Reject only (defer Accept)\",\n description: \"AI Review Summary posted (URL) | Reject M applied (user override) + Accept N deferred to fix_plan\"\n}\n```\n\n#### Self-check (every time before option drafting)\n\n1. Are there 1+ Reject findings in the Step 4 classification?\n2. If yes, did you include a Reject override option in the Step 8 options?\n3. Did you state the Reject rationale in the option description? (gives the user info to judge \"is that rationale enough? override?\")\n4. If only \"Accept only\" / \"Defer only\" options are presented = violation (Reject override omitted)\n\n### Invocation pattern\n\n```text\nSkill(\"next\") with args:\n \"After PR consolidate — ask for PR #N handling direction\n - 4-condition status: \n - AI Review Summary URL: \n - Option candidates: ...\"\n```\n\nThe next skill performs the AskUserQuestion call + result handling. The consolidate skill is only responsible for invoking next.\n\n### Self-check (on Step 8 entry)\n\n1. Was the Step 7.5 status line output?\n2. **Is the PR authored by the current account?** (`gh pr view --json author`) → If **no**, merge options are F\n\nArchive v0.7.1: 20 files, 122758 bytes\n\nFiles: CHANGELOG.md (17895b), classify.md (16075b), collect.md (6125b), decide.md (20853b), internal.md (42582b), LICENSE (1063b), next.md (28566b), post.md (74764b), pr.md (41792b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-consolidate-verify-format-mismatch.py (10650b), resources/block-noncompliant-review-comment.sh (5426b), resources/block-summary-fabricated-claims.sh (8190b), resources/block-summary-status-vocab.py (9891b), scripts/collect.sh (3463b), scripts/verify_consolidate.py (23358b), skill-card.md (1815b), SKILL.md (8493b), _meta.json (130b)\n\nArchive v0.7.0: 20 files, 122282 bytes\n\nFiles: CHANGELOG.md (17403b), classify.md (15828b), collect.md (6125b), decide.md (20853b), internal.md (42582b), LICENSE (1063b), next.md (28566b), post.md (73965b), pr.md (41792b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-consolidate-verify-format-mismatch.py (10650b), resources/block-noncompliant-review-comment.sh (5426b), resources/block-summary-fabricated-claims.sh (8190b), resources/block-summary-status-vocab.py (9891b), scripts/collect.sh (3463b), scripts/verify_consolidate.py (23358b), skill-card.md (1906b), SKILL.md (8493b), _meta.json (130b)\n\nArchive v0.6.5: 20 files, 114841 bytes\n\nFiles: CHANGELOG.md (15996b), classify.md (15828b), collect.md (4849b), decide.md (20853b), internal.md (36876b), LICENSE (1063b), next.md (25632b), post.md (69934b), pr.md (39091b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-consolidate-verify-format-mismatch.py (10650b), resources/block-noncompliant-review-comment.sh (5426b), resources/block-summary-fabricated-claims.sh (8190b), resources/block-summary-status-vocab.py (9891b), scripts/collect.sh (3463b), scripts/verify_consolidate.py (20749b), skill-card.md (2645b), SKILL.md (8142b), _meta.json (130b)\n\nArchive v0.6.4: 19 files, 110025 bytes\n\nFiles: CHANGELOG.md (15292b), classify.md (15828b), collect.md (4849b), decide.md (20853b), internal.md (35314b), LICENSE (1063b), next.md (25632b), post.md (69934b), pr.md (39091b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-noncompliant-review-comment.sh (5426b), resources/block-summary-fabricated-claims.sh (8190b), resources/block-summary-status-vocab.py (9891b), scripts/collect.sh (3463b), scripts/verify_consolidate.py (20749b), skill-card.md (2369b), SKILL.md (8142b), _meta.json (130b)\n\nArchive v0.6.3: 19 files, 106634 bytes\n\nFiles: CHANGELOG.md (14041b), classify.md (15828b), collect.md (4849b), decide.md (20853b), internal.md (33276b), LICENSE (1063b), next.md (25632b), post.md (69934b), pr.md (37155b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-noncompliant-review-comment.sh (5426b), resources/block-summary-fabricated-claims.sh (8190b), resources/block-summary-status-vocab.py (9891b), scripts/collect.sh (3463b), scripts/verify_consolidate.py (16145b), skill-card.md (2456b), SKILL.md (8142b), _meta.json (130b)\n\nArchive v0.6.2: 18 files, 100833 bytes\n\nFiles: CHANGELOG.md (13568b), classify.md (15828b), collect.md (4849b), decide.md (20853b), internal.md (33276b), LICENSE (1063b), next.md (25632b), post.md (68323b), pr.md (37155b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-noncompliant-review-comment.sh (5426b), resources/block-summary-fabricated-claims.sh (8190b), scripts/collect.sh (3463b), scripts/verify_consolidate.py (12618b), skill-card.md (2656b), SKILL.md (8142b), _meta.json (130b)\n\nArchive v0.6.1: 18 files, 99304 bytes\n\nFiles: CHANGELOG.md (13080b), classify.md (15828b), collect.md (4849b), decide.md (20853b), internal.md (33276b), LICENSE (1063b), next.md (25632b), post.md (68323b), pr.md (37155b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-noncompliant-review-comment.sh (5426b), resources/block-summary-fabricated-claims.sh (8190b), scripts/collect.sh (3463b), scripts/verify_consolidate.py (8897b), skill-card.md (2490b), SKILL.md (8142b), _meta.json (130b)\n\nArchive v0.6.0: 17 files, 94467 bytes\n\nFiles: CHANGELOG.md (12169b), classify.md (15828b), collect.md (4849b), decide.md (20853b), internal.md (33276b), LICENSE (1063b), next.md (25632b), post.md (66079b), pr.md (37155b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-noncompliant-review-comment.sh (5426b), scripts/collect.sh (3463b), scripts/verify_consolidate.py (8897b), skill-card.md (2524b), SKILL.md (8142b), _meta.json (130b)\n\nArchive v0.5.4: 16 files, 88768 bytes\n\nFiles: CHANGELOG.md (11022b), classify.md (15828b), collect.md (4849b), decide.md (20853b), internal.md (30723b), LICENSE (1063b), next.md (23421b), post.md (64678b), pr.md (37155b), README.md (1125b), resources/block-consolidate-summary-ask.sh (2681b), resources/block-noncompliant-review-comment.sh (5426b), scripts/collect.sh (3463b), skill-card.md (2830b), SKILL.md (8142b), _meta.json (130b)","readmeExcerpt":"Skill: consolidate Owner: drumrobot Summary: Consolidate and respond to external feedback on PRs/issues. Topics — pr (workflow entrypoint + skip conditions), collect (gather AI reviews + superpowers load), internal (Internal Code Review fallback + UI capture), classify (dual-label Type|Severity + diff scope check), decide (user decision: findings + Formal Review), post (Summary + Formal Review + status + deferred), n","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"Interactive mode auto-activated by caller args (intent: ) — drafts will be reviewed before POST."},{"language":"text","snippet":"pr (entry: identify → skip → worktree checkout)\n └─→ git-repo/worktree (Step 2.7: check out PR branch into a worktree — all review runs against real files)\ncollect → internal (code-reviewer dispatch operates in the Step 2.7 worktree)"},{"language":"bash","snippet":"npx skills add es6kr/skills --skill consolidate"},{"language":"bash","snippet":"npx skills add es6kr/skills --skill git-repo --skill github-flow"},{"language":"bash","snippet":"# Option 1 — just the code-review skills\nnpx skills add obra/superpowers --skill requesting-code-review --skill receiving-code-review\n\n# Option 2 — the full superpowers plugin (covers the whole dependency tree)\nnpx skills add obra/superpowers"},{"language":"bash","snippet":"# Collect PR diff file list (run once before classification)\nGH_TOKEN=\"$(gh auth token --user )\" gh pr view -R / --json files --jq '.files[].path' | sort > /tmp/pr-${N}-files.txt"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: consolidate\ndepends-on: [git-repo, github-flow, hook-kit, superpowers]\nmetadata:\n author: es6kr\n version: \"0.8.0\" # x-release-please-version\ndescription: |\n Consolidate and respond to external feedback on PRs/issues. Topics —\n pr (workflow entrypoint + skip conditions),\n collect (gather AI reviews + superpowers load),\n internal (Internal Code Review fallback + UI capture),\n classify (dual-label Type|Severity + diff scope check),\n decide (user decision: findings + Formal Review),\n post (Summary + Formal Review + status + deferred),\n next (post-summary next-action ask).\n Use when: \"review consolidate\", \"PR review\", \"AI review\", \"CodeRabbit review\", \"Copilot review\",\n \"review check\", \"review summary\", \"merge ready\", \"internal review\", \"code-reviewer\",\n \"inline review\", \"line-level comment\", \"PR line review\".\nallowed-tools: [Agent, AskUserQuestion, Bash, Edit, Glob, Grep, Read, Write]\n---\n\n# Consolidate\n\nConsolidate and respond to external feedback on PRs and issues.\n\n## Options\n\n| Flag | Default | Behavior |\n|------|---------|----------|\n| `--interactive` | off | Before each POST (Internal Review at Step 3.5.3 / Summary at Step 7), pause and `AskUserQuestion` the drafted body to the user. User can approve, request edits, or reject. Edits applied → re-ask. Reject → abort POST for that artifact. |\n\n### Auto-activation by args keywords (HARD STOP)\n\nWhen the consolidate caller passes args containing any of the following intent classes (any language — match by meaning, not literal token), **treat `--interactive` as implicitly set** even if the flag was not literal. The keyword expresses the user's intent for review-before-post.\n\n| Intent class | Match signal |\n|--------------|--------------|\n| Explicit review request | Phrases requesting review of the draft before publishing — \"review first\", \"review before post\", \"review the draft\", localized equivalents (e.g., the Korean phrase meaning \"review needed\" / \"after review\") |\n| Interactive mode request | Words like `interactive` (any language transliteration), or phrases meaning \"conversational mode\" / \"step-by-step ask\" |\n| \"Important decision ask\" intent | Phrases stating that important decisions / important parts must be asked — e.g., \"ask important parts\", \"ask the key decisions\", localized equivalents |\n| Author-style review request | Phrases stating the user wants to see / review the artifact themselves — \"let me review\", \"let me see the draft\", \"after I check\" |\n\nWhen auto-activation fires, the caller MUST emit a one-line acknowledgement in chat before the first ask:\n\n```\nInteractive mode auto-activated by caller args (intent: ) — drafts will be reviewed before POST.\n```\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Treat args keyword as flavor text and continue deterministic POST | Match against the intent-class table above. On any match, enable `--interactive` for the entire workflow |\n| 2 | Activate interactive only for the matched step (e.g., only the Summary)"},{"path":"README.md","content":"# consolidate\n\nConsolidate and respond to external PR/issue feedback — gather AI reviews (CodeRabbit, Copilot), classify findings by type and severity, post an AI Review Summary and Formal Review, then register deferred items.\n\n## Installation\n\n```bash\nnpx skills add es6kr/skills --skill consolidate\n```\n\nBrowse on ClawHub: \n\n### Peer skills\n\n`consolidate` depends on `git-repo` and `github-flow`. Install them so all flows work:\n\n```bash\nnpx skills add es6kr/skills --skill git-repo --skill github-flow\n```\n\nIt also uses the [`superpowers`](https://github.com/obra/superpowers) plugin for its code-review primitives. Install either the specific skills or the full plugin:\n\n```bash\n# Option 1 — just the code-review skills\nnpx skills add obra/superpowers --skill requesting-code-review --skill receiving-code-review\n\n# Option 2 — the full superpowers plugin (covers the whole dependency tree)\nnpx skills add obra/superpowers\n```\n\n## Usage\n\nInvoke with `/consolidate ` (for example `/consolidate pr `). See [`SKILL.md`](./SKILL.md) for the full topic list and workflow."},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn74k8yfvftx6f062qa8fzyd8h8373jd\",\n \"slug\": \"consolidate\",\n \"version\": \"0.8.0\",\n \"publishedAt\": 1791543246573\n}"},{"path":"CHANGELOG.md","content":"# Changelog\n\n## [0.8.0](https://github.com/es6kr/skills/compare/consolidate-v0.7.1...consolidate-v0.8.0) (2026-10-06)\n\n\n### Features\n\n* **hook-kit:** declarative step-dependency enforcement engine ([9e3d188](https://github.com/es6kr/skills/commit/9e3d18898453d20a947b74b24032e61bf13bc297))\n\n## [0.7.1](https://github.com/es6kr/skills/compare/consolidate-v0.7.0...consolidate-v0.7.1) (2026-10-04)\n\n\n### Bug Fixes\n\n* **consolidate:** unify Source, Type, and Severity into a single 3-line column ([#603](https://github.com/es6kr/skills/issues/603)) ([c4ef164](https://github.com/es6kr/skills/commit/c4ef16457eaedcdac22dc7ab74fcb0d3cbf6a276))\n* **hooks:** verify executable hook registrations ([1bd613a](https://github.com/es6kr/skills/commit/1bd613aba2aa5cb2509f3dacd53acc5eab3cbf3f))\n\n## [0.7.0](https://github.com/es6kr/skills/compare/consolidate-v0.6.5...consolidate-v0.7.0) (2026-09-30)\n\n\n### Features\n\n* **fix-plan, consolidate:** consolidate task coordination, review collection, and docs ([d6162d8](https://github.com/es6kr/skills/commit/d6162d8d25bb80c85aa2c5cd475afdf0ee638535))\n\n\n### Bug Fixes\n\n* **consolidate:** accept an engine-named Code Review in the provenance gate ([dbb93fb](https://github.com/es6kr/skills/commit/dbb93fb0c329e6efaa9ea1257058ef4455c4085c))\n* **consolidate:** enhance review collection, PATCH verification, and harness check ([858adef](https://github.com/es6kr/skills/commit/858adef07f212f09e550be77c7fc89cfd229e9fe))\n* **consolidate:** make the dispatch-failure history select the starting rung ([17637c3](https://github.com/es6kr/skills/commit/17637c303d26aed4af95514af44d527e7076e422))\n* **consolidate:** reconcile the two-comment invariant across pr/internal/post ([1e17091](https://github.com/es6kr/skills/commit/1e170913e104711bc124008a632360cc59c0f05d))\n* **consolidate:** reconcile the two-comment invariant and the provenance gate ([28d2f9a](https://github.com/es6kr/skills/commit/28d2f9a399e28342ef16cc9244279c85ec75bf39))\n* **consolidate:** Step 8 finding-handling ask must reuse posted Status column ([#561](https://github.com/es6kr/skills/issues/561)) ([2d310e3](https://github.com/es6kr/skills/commit/2d310e3cc51d4b28d711973c27bc94e4abae9d2e))\n\n## [0.6.5](https://github.com/es6kr/skills/compare/consolidate-v0.6.4...consolidate-v0.6.5) (2026-09-20)\n\n\n### Bug Fixes\n\n* address code review feedback ([0c08bfb](https://github.com/es6kr/skills/commit/0c08bfbf2b5b737fdce685c8f15ead56c64290f4))\n* **consolidate:** drop requesting-code-review suffix when bot-layer content is mixed in ([#498](https://github.com/es6kr/skills/issues/498)) ([66fb1be](https://github.com/es6kr/skills/commit/66fb1bedc768544415a808b2d33d96feeee0a3ea))\n* **consolidate:** guard verify_consolidate.py format contract at POST time ([#500](https://github.com/es6kr/skills/issues/500)) ([941023a](https://github.com/es6kr/skills/commit/941023a5fb36becfdc484017b8cde128078f07a9))\n\n## [0.6.4](https://github.com/es6kr/skills/compare/consolidate-v0.6.3...consolidate-v0.6.4) (2026-09-18)\n\n"},{"path":"classify.md","content":"# Analyze and Classify\n\nClassify each finding using the verify→evaluate→respond pattern. Apply PR diff scope cross-check + option grouping + dual-label (Type | Severity).\n\nEntry: `Skill(\"consolidate\", \"classify ...\")` or `pr.md` Workflow Step 4.\n\n## Step 4: Analyze and Classify (verify before accepting)\n\nFor each feedback item, apply the **verify→evaluate→respond** pattern loaded from `superpowers:receiving-code-review`:\n\n1. **READ**: Complete feedback without reacting\n2. **VERIFY**: Check against codebase reality — `grep` for actual usage, read the implementation being criticized\n3. **EVALUATE**: Is this technically sound for THIS codebase? YAGNI check — if the suggestion adds unused functionality, classify as Rejected\n\n> **The `receiving-code-review` load is justified ONLY by producing explicit validity verdicts (Step 4-0) — including ⚪ Rejected where warranted.** If a consolidate run defaults every finding to Deferred and produces zero Reject consideration, the skill load was decorative: the framework's core verb is \"push back when wrong\", not \"defer everything\". A Summary with no Reject path exercised does not need `receiving-code-review` at all.\n\n### Step 4-0: Validity verdict (MANDATORY — operationalize receiving-code-review, runs BEFORE 4-A/Severity)\n\n**Validity (valid vs reject) and timing (now vs defer) are SEPARATE axes. Every finding must get an explicit validity verdict FIRST.** Timing (immediate fix / Deferred) applies **only to findings already judged VALID**. A wrong / inapplicable finding is ⚪ **Rejected** — it must NOT be silently carried as \"Deferred\" (Defer is a timing decision for valid findings, never a substitute for the Reject validity verdict).\n\nPer finding, record one verdict:\n\n| Verdict | When | Next |\n|---------|------|------|\n| ✅ **VALID** | Verified correct for THIS codebase | → Step 4-A scope + Severity + timing (now/defer) |\n| ⚪ **REJECTED** | One of the Reject reasons below holds | → pushback track (reason mandatory; NOT carried into apply/defer groups) |\n\n**Reject reasons (any one ⇒ ⚪ Rejected — not Deferred):**\n\n1. **YAGNI** — adds unused functionality (grep confirms no caller / no need)\n2. **Technically inappropriate** — wrong for this stack/platform/version\n3. **Contradicts the author's deliberate or documented intent** — the PR/commit/issue shows the author intentionally chose the criticized structure (e.g., a deliberately-built merge/TDD structure, an explicit architectural decision). A reviewer preference against a deliberate author choice is Rejected, not Deferred\n4. **False premise** — VERIFY failed: the finding's factual claim is wrong (e.g., \"PR introduced regression in X\" but `git log ..HEAD -- X` is empty — see Step 4-A #7)\n5. **Already handled elsewhere** — the concern is covered by existing code/middleware/tests the reviewer missed\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Default a finding to `🟡 Deferred` without a validity verdict | Assign VALID or ⚪ REJECTED first. Defer only a VALID fi"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":1806,"uniquenessScore":43,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T12:30:38.837Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T12:30:38.837Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-09T18:09:40.031Z","emptyReason":null},"items":[{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-10T18:48:31.762Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}