[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CYH9RDZ2X962MWD7JAPATJ":3,"skill-same:01M6CYH9RDZ2X962MWD7JAPATJ":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":6,"updatedAt":59,"install":60,"resources":72},"01M6CYH9RDZ2X962MWD7JAPATJ","received-review-sdlc",null,"Use this skill when responding to code review feedback on a pull request or inline reviewer comments. Covers reading, verifying, evaluating, and responding to reviewer comments with a dual self-critique gate — prevents performative agreement and ensures technical rigor. Can be launched manually or automatically after \u002Freview-sdlc. Triggers on: process review feedback, respond to review, handle review comments, address PR feedback, fix review findings, received-review.","rnagrodzki\u002Fsdlc-marketplace","rnagrodzki","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F303481?v=4","01M6CYFWQK3A8WR9W324Z5Q5DR","Rafal Nagrodzki","01M6CYFWVKS23ECZCP9R7DTQVN",0,"MIT","https:\u002F\u002Fgithub.com\u002Frnagrodzki\u002Fsdlc-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fsdlc-utilities\u002Fskills\u002Freceived-review-sdlc\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"review","received review sdlc","sdlc","code review feedback","code review","self","fix review","address pr feedback","auto","use","pr","fix","pull request","technical","reviewer","feedback","pr feedback","critique","pull","code","2026-11-10 10:12:30",false,"---\nname: received-review-sdlc\ndescription: \"Use this skill when responding to code review feedback on a pull request or inline reviewer comments. Covers reading, verifying, evaluating, and responding to reviewer comments with a dual self-critique gate — prevents performative agreement and ensures technical rigor. Can be launched manually or automatically after \u002Freview-sdlc. Triggers on: process review feedback, respond to review, handle review comments, address PR feedback, fix review findings, received-review.\"\nuser-invocable: true\nargument-hint: \"[--pr \u003Cnumber>] [--auto]\"\nmodel: opus\n---\n\n# Responding to Code Review Feedback\n\nProcess reviewer comments with technical rigor. Each item is verified against the full\ncodebase context — not just the change diff — before any response is drafted. Internal\nself-critique gates ensure quality. No changes are made until the user explicitly approves\nthe proposed action plan.\n\n**Announce at start:** \"I'm using received-review-sdlc (sdlc v{sdlc_version}).\" — extract the version from the `sdlc:` line in the session-start system-reminder. If no version is in context, omit the parenthetical.\n\n---\n\n## Configuration\n\n### `receivedReview.alwaysFixSeverities` (issue #233, R18\u002FR19)\n\nPer-user, per-project allowlist of finding severities whose **\"agree, will fix\"** verdicts bypass\nthe per-finding consent gate in Step 10 (PRESENT) and Step 12 (REPLY & RESOLVE).\n\n- **Location:** `.sdlc\u002Flocal.json` under `receivedReview.alwaysFixSeverities` (gitignored, per-user).\n  This field is **local-only** — it MUST NEVER be set in `.sdlc\u002Fconfig.json`. The prepare script\n  emits a stderr warning and ignores the value if it appears in project config (R19).\n- **Type:** `string[]` — array of severities; allowed values: `low | medium | high | critical`.\n- **Default:** `[]` — preserves the original consent-on-every-finding behavior.\n- **Resolution site:** the prepare script `skill\u002Freceived-review.js` resolves the field once and\n  emits it as `flags.alwaysFixSeverities` in the manifest. All decision sites in this SKILL.md\n  cite `flags.alwaysFixSeverities` only — never re-read configuration.\n\n**Example (`.sdlc\u002Flocal.json`):**\n\n```json\n{\n  \"receivedReview\": {\n    \"alwaysFixSeverities\": [\"critical\", \"high\"]\n  }\n}\n```\n\n**Auto-apply rule (R18):** A finding is auto-applied (no consent prompt) when **all three** hold:\n\n1. The verdict is `agree, will fix`\n2. The finding's parsed severity is non-null\n3. The severity ∈ `flags.alwaysFixSeverities`\n\nA finding with `severity: null` (severity could not be parsed from the comment body) **NEVER**\nbypasses the consent gate, regardless of `flags.alwaysFixSeverities`.\n\n**`--auto` interaction (R10\u002FR16):** When `flags.alwaysFixSeverities` is non-empty, `--auto`\nis further restricted by R18: only \"will fix\" findings whose severity is in the list are\nimplemented in Step 11; remaining \"will fix\" findings (severity not in the list, or\n`severity: null`) are collected into a **follow-up summary** appended to the response output.\nIn Step 12, only \"agree, will fix\" threads matching R18 are resolved; other threads are replied\nto but left open.\n\nWhen `flags.alwaysFixSeverities` is empty (the default — `alwaysFixSeverities` unset in\n`.sdlc\u002Flocal.json`), `--auto` falls back to the original behavior: **all** \"will fix\" findings\nare auto-applied in Step 11 and all \"agree, will fix\" threads are resolved in Step 12, regardless\nof severity (including `severity: null`). This preserves backward compatibility for users who\nhave not configured the field.\n\nTo configure interactively, run `\u002Fsetup-sdlc --only received-review`.\n\n### `receivedReview.alwaysHardenFromReview` (issue #429, R24)\n\nPer-user flag that controls whether Step 11.6 (META-ANALYZE) automatically dispatches\n`Skill(harden-sdlc)` per cluster without asking for consent.\n\n- **Location:** `.sdlc\u002Flocal.json` under `receivedReview.alwaysHardenFromReview` (gitignored, per-user).\n  This field is **local-only** — it MUST NEVER be set in `.sdlc\u002Fconfig.json`. The prepare script\n  emits a stderr warning and ignores the value if it appears in project config (R24).\n- **Type:** `boolean` — default `false`.\n- **Scope:** applies uniformly to all Step 11.6 cluster dispatches in every run.\n\n**Auto-mode matrix (R25 — all four cells authoritative):**\n\n| `flags.auto` | `flags.alwaysHardenFromReview` | Step 11.6 behavior |\n|---|---|---|\n| `false` | `false` | Present consent gate per cluster → dispatch approved clusters only. |\n| `false` | `true`  | Skip consent gate → dispatch every cluster (capped at `hardenClusterCap`). |\n| `true`  | `false` | Skip consent gate AND skip dispatch entirely → append deferred-action entry to `.sdlc\u002Flearnings\u002Flog.md` (R26 format). |\n| `true`  | `true`  | Skip consent gate → dispatch every cluster (capped), propagating `--auto` to every dispatch. |\n\n**Single resolution site:** `skill\u002Freceived-review.js` (prepare script). SKILL.md cites\n`flags.alwaysHardenFromReview` only — never raw `$ARGUMENTS` or `.sdlc\u002Flocal.json` directly.\n\n**Example `.sdlc\u002Flocal.json`:**\n```json\n{\n  \"receivedReview\": {\n    \"alwaysHardenFromReview\": true,\n    \"hardenClusterCap\": 5\n  }\n}\n```\n\n### `receivedReview.hardenClusterCap` (issue #429, P15)\n\nMaximum number of harden-sdlc clusters dispatched per Step 11.6 run.\n\n- **Location:** `.sdlc\u002Flocal.json` under `receivedReview.hardenClusterCap`.\n- **Type:** `integer` — default `5`, clamped to `[1, 50]`.\n- Excess clusters beyond the cap are suppressed and logged as `suppressed: N additional clusters`\n  in the deferred-action entry or the learning-log dispatch record.\n\n---\n\n## Step 0 — Plan Mode Check\n\nIf the system context contains \"Plan mode is active\":\n\n1. Announce: \"This skill requires write operations (file edits, gh api calls). Exit plan mode first, then re-invoke `\u002Freceived-review-sdlc`.\"\n2. Stop. Do not proceed to subsequent steps.\n\n---\n\n## Step 1 — READ: Gather Review Feedback\n\n### Step 1a — Run skill\u002Freceived-review.js (when PR number available)\n\nWhen a PR number or URL is provided (via arguments or user input), run the prepare script to pre-compute review thread state:\n\n```bash\n# Substitute \u003CPLUGIN_ROOT> from the `sdlc plugin root:` context line.\nMANIFEST_FILE=$(node \"\u003CPLUGIN_ROOT>\u002Fscripts\u002Fskill\u002Freceived-review.js\" --output-file $ARGUMENTS --pr \u003CPR_NUMBER>)\nEXIT_CODE=$?\necho \"MANIFEST_FILE=$MANIFEST_FILE\"\necho \"EXIT_CODE=$EXIT_CODE\"\n# Single canonical cleanup: trap fires unconditionally on EXIT\u002FINT\u002FTERM.\ntrap 'rm -f \"$MANIFEST_FILE\"' EXIT INT TERM\n```\n\n**On exit code 0:** Read the manifest JSON. Extract `flags.auto` from the manifest and store it as a boolean (defaults to `false` if absent). If `--auto` was passed in `$ARGUMENTS` but not in the manifest, treat it as `true`. Display the incremental summary:\n\n```\nFound N outstanding comments (M resolved, K already replied, J stale — skipped).\nProcessing only the N outstanding comments.\n```\n\nUse only threads with `status: \"outstanding\"` for Steps 2–11. Store the full manifest (including resolved\u002Fself-replied\u002Fstale threads) for use in Step 12 (PR Reply & Resolve).\n\n**On exit code 1:** No PR found or missing arguments. Fall back to Step 1b.\n\n**On exit code 2:** Script error. Invoke `error-report-sdlc` with:\n- **Skill:** received-review-sdlc\n- **Step:** Step 1 — READ\n- **Operation:** skill\u002Freceived-review.js execution\n- **Error:** stderr output from the script\n\n### Step 1b — Manual feedback gathering (fallback)\n\nWhen no PR number is available, the prepare script is not found, or Step 1a fails:\n\nLocate the review feedback from one of:\n- Findings already in conversation context (e.g. passed in from `\u002Freview-sdlc`)\n- User paste\n- PR URL — fetch with:\n  ```bash\n  gh pr view \u003Cnumber> --comments\n  gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Freviews\n  ```\n\nParse each comment into a structured list:\n\n```\n| # | File | Line | Reviewer | Comment | Type |\n```\n\nType classification: `bug`, `style`, `architecture`, `feature-request`, `question`, `unclear`.\n\n---\n\n## Step 2 — UNDERSTAND: Categorize and Flag\n\nFor each item:\n- Assign a type from the classification above\n- Flag items that are **unclear** (ambiguous intent, missing context, could be interpreted multiple ways)\n\n**CRITICAL:** If ANY item is unclear:\n```\nSTOP — do not implement anything yet.\nAsk for clarification on ALL unclear items at once.\nWHY: Items may be related. Partial understanding = wrong implementation.\n```\n\nOnly proceed to Step 3 after all items are understood.\n\n---\n\n## Step 3 — VERIFY: Check Against Full Codebase Context\n\nFor each feedback item, gather context beyond the immediate change diff:\n\n1. **Read the referenced code** — understand what the code actually does\n2. **Trace callers and dependents** — use LSP references or grep to find who calls the changed code, what imports it, and what would be affected by the suggested change\n3. **Check architectural context** — read related modules, interfaces, and tests to understand the design intent behind the current implementation\n4. **Evaluate ripple effects** — determine whether the suggested change would break or improve behavior beyond the immediate diff\n\nDetermine the verification status:\n- **confirmed** — reviewer's claim is correct, and the suggestion works in full context\n- **confirmed, but suggestion is incomplete** — the issue is real but the proposed fix has side effects or misses related code that also needs updating\n- **incorrect** — reviewer is wrong about what the code does\n- **partially correct** — some aspects correct, some not\n- **cannot verify** — would need runtime data or external context\n\nFor \"cannot verify\" items: state the limitation explicitly, ask the user for direction.\n\n---\n\n## Step 4 — EVALUATE: Assess Each Item\n\nUsing verification results, determine for each item:\n\n- **agree, will fix** — technically correct, should be changed\n- **agree, won't fix** — correct but out of scope or lower priority (state reason)\n- **disagree** — technically incorrect for this codebase (provide reasoning)\n- **needs discussion** — architectural impact, requires owner input\n\n**YAGNI check for feature requests:**\n```\ngrep codebase for actual usage\nIF unused: \"This isn't called anywhere. Remove it (YAGNI)? Or is there usage I'm missing?\"\nIF used: Then evaluate the suggestion on merit\n```\n\n**Source trust:**\n- Trusted partner feedback: implement after understanding, skip performative agreement\n- External\u002Fautomated reviewer: verify technically, apply YAGNI, push back if wrong\n\n---\n\n## Step 5 — CRITIQUE #1: Self-Critique the Evaluation\n\n> **INTERNAL** — Do not display gate results, pass\u002Ffail status, or any output from this step to the user. Process silently and proceed to the next step.\n\nBefore drafting responses, review the evaluation against these gates:\n\n| Gate | Check | Pass Criteria |\n|------|-------|--------------|\n| Verification completeness | Every item verified against actual code | No item evaluated without reading relevant source |\n| No blind agreement | Disagreements exist where technically warranted | Not everything marked \"agree\" unless genuinely correct |\n| YAGNI applied | Feature suggestions checked for real vs hypothetical need | No \"sounds good, will add\" for speculative features |\n| Unclear items resolved | All unclear items clarified before proceeding | Not implementing partial feedback |\n| Technical grounding | Every agree\u002Fdisagree decision cites code or behavior | No decisions based on \"seems right\" without evidence |\n\nNote every failing gate.\n\n---\n\n## Step 6 — IMPROVE #1: Revise Evaluation\n\n> **INTERNAL** — Do not display output from this step to the user. Process silently.\n\nFix each issue found in Step 5:\n- Re-read code for items where verification was incomplete\n- Strengthen technical reasoning where it was vague\n- Reclassify items where the initial assessment was unsupported\n\nContinue until all gates pass (max 2 iterations per gate).\n\n---\n\n## Step 7 — RESPOND (DO): Draft Responses\n\nDraft a response for each item. Response structure per item:\n\n1. Factual acknowledgment of what was said (no performative openers)\n2. What will be done OR technical reason for disagreement\n3. If implementing: brief description of approach\n\n**Forbidden openers — NEVER use:**\n- \"You're absolutely right!\"\n- \"Great point!\" \u002F \"Excellent feedback!\"\n- \"Thanks for catching that!\" \u002F Any gratitude expression\n- \"Let me implement that now\" (before verification)\n\n**Instead, start with the substance:**\n- Restate the technical issue\n- State the decision (fix \u002F won't fix \u002F disagree)\n- Provide reasoning\n\n**Pushback format:**\n```\nChecked [specific code location]. [What it actually does]. [Consequence of the suggested change].\nDecision: [keeping as-is \u002F discussing with owner \u002F needs more context].\n```\n\n**GitHub thread replies:** Reply in-thread using the comment ID, not as a top-level PR comment:\n```bash\ngh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n  -f body=\"\u003Cresponse text>\"\n```\n\n**Version footer:** Append `manifest.reply_footer` verbatim to the end of every reply body before posting. Do not modify the footer string. Do not insert it elsewhere. The footer is a single string with a leading blank-line separator already included — append it directly to the reply body with no additional separator.\n\n---\n\n## Step 8 — CRITIQUE #2: Self-Critique the Responses\n\n> **INTERNAL** — Do not display gate results, pass\u002Ffail status, or any output from this step to the user. Process silently and proceed to the next step.\n\nReview drafted responses against these gates:\n\n| Gate | Check | Pass Criteria |\n|------|-------|--------------|\n| No performative language | Zero forbidden openers or gratuitous praise | Responses start with substance, not social filler |\n| Technically grounded | Every response references specific code, behavior, or constraint | No hand-waving (\"this should be fine\") |\n| Pushback is technical | Disagreements cite code, performance data, or design constraints | No \"I prefer\" or \"I think\" without backing evidence |\n| Thread-level replies | Each response targets its specific comment thread | No top-level dump of all responses |\n| Implementation plan clear | For accepted items, response states what will change | Reviewer knows what to expect in next push |\n| No blind agreement | Factual errors corrected, not accommodated | Incorrect reviewer claims are challenged |\n| Proportional effort | Simple fixes get short responses; complex items get detailed ones | No walls of text for typo fixes |\n\nNote every failing gate.\n\n---\n\n## Step 9 — IMPROVE #2: Revise Responses\n\n> **INTERNAL** — Do not display output from this step to the user. Process silently.\n\nFix each issue found in Step 8:\n- Delete performative openers, replace with substance\n- Add specific code references where missing\n- Shorten over-explained simple fixes\n\nContinue until all gates pass (max 2 iterations per gate).\n\n---\n\n## Step 10 — PRESENT: Show Findings and Proposed Plan\n\nThis is the first user-visible output after the analysis phase. Present the complete analysis\nand proposed actions to the user. **No changes have been made yet.**\n\n**1. Analysis summary table:**\n\n```\n| # | File | Line | Type | Verdict | Reasoning |\n```\n\nShow every item with its type (bug, style, architecture, etc.) and verdict (agree will fix \u002F\nagree won't fix \u002F disagree \u002F needs discussion) with a one-line reasoning summary.\n\n**2. Proposed action plan:**\n\nGroup items by action:\n- **Will fix:** list items with brief description of the change\n- **Will push back:** list items with the core technical reason\n- **Needs discussion:** list items with what's unresolved\n\n**3. Drafted PR responses:**\n\nShow the full text of each drafted response, labeled by item number.\n\n**4. Consent gate:**\n\n**Per-finding bypass rule (R18):** Skip the consent gate for finding F when\n`flags.alwaysFixSeverities` includes `F.severity` AND `F.verdict === \"agree, will fix\"` AND\n`F.severity !== null`. Such findings are auto-applied with a one-line `fixed: \u003Cdescription>`\nlog entry and require no user prompt. All other findings (any other verdict, severity not in\nthe list, or `severity: null`) follow the modes below.\n\n**Auto mode:** When `flags.auto` is true (from manifest or arguments):\n- If `flags.alwaysFixSeverities` is **non-empty**: apply only \"agree, will fix\" findings whose\n  severity ∈ `flags.alwaysFixSeverities` (per the R18 bypass rule above). Remaining \"agree, will\n  fix\" findings — severity NOT in the list, or `severity: null` — are collected into a\n  **follow-up summary** appended to the response output (not auto-applied).\n- If `flags.alwaysFixSeverities` is **empty** (default): apply **all** \"agree, will fix\" findings\n  regardless of severity (including `severity: null`). This is the original `--auto` behavior and\n  is the default for users who have not configured `alwaysFixSeverities`.\n\nItems with \"disagree\", \"needs discussion\", or \"won't fix\" verdicts are displayed but NEVER\nauto-actioned in either case. Still display the full analysis table and action plan above for\nvisibility, then proceed directly to Step 11.\n\n**Manual mode (default):** When `flags.auto` is false or absent, use AskUserQuestion to ask:\n> No changes have been made yet. How to proceed?\n\nOptions:\n- **implement** — post responses to PR and apply code changes\n- **edit** — modify the plan before proceeding\n- **skip** — discard, make no changes\n\nIf the user chooses **edit**, ask what to change, revise, and present again.\nLoop until explicit **implement** or **skip**.\n\n**Do NOT proceed to Step 11 without explicit `implement` from the user via AskUserQuestion**, EXCEPT\nfor findings that satisfy the R18 bypass rule above — those are auto-applied without prompting and\nemit a `fixed: ...` log line. Findings outside the R18 bypass set still require explicit\n`implement` consent.\n\n**Without `--auto`, pipeline context does NOT override this gate** (except for findings satisfying\nthe R18 bypass rule). Even when invoked from `\u002Fship-sdlc`, if `--auto` was not explicitly passed\nas a flag, this consent gate is mandatory for findings outside the R18 bypass set. Do not infer\nfrom surrounding context that automatic execution is expected.\n\n---\n\n## Step 11 — IMPLEMENT: Execute Changes\n\n**Only execute after explicit `implement` from Step 10, OR when `flags.auto` is true (auto-proceed for \"will fix\" items only), OR when the finding satisfies the R18 bypass rule from Step 10 (severity ∈ `flags.alwaysFixSeverities` AND verdict is \"agree, will fix\" AND `severity !== null`).** Findings auto-applied via R18 emit a one-line `fixed: \u003Cdescription>` log entry instead of a consent prompt.\n\nPost responses to PR threads, then implement accepted code changes.\n\n**Implementation order:**\n1. Blocking issues (breaks functionality, security)\n2. Simple fixes (typos, imports, naming)\n3. Complex fixes (refactoring, logic changes)\n\nFor each change: make the edit, verify it compiles\u002Fpasses tests, then move to the next.\nDo NOT batch changes across items.\n\n**Items marked \"disagree\" or \"needs discussion\":** Do NOT implement — await reviewer or\nowner input.\n\n**Gracefully correcting wrong pushback:**\nIf you pushed back and were wrong:\n```\nCorrect: \"You were right — I checked [X] and it does [Y]. Implementing now.\"\nWrong:   Long apology, defensive explanation, over-explaining\n```\nState the correction factually and move on.\n\n---\n\n## Step 11.6 — META-ANALYZE: Cluster Findings and Dispatch harden-sdlc (R21–R26)\n\n**Best-effort step.** Failure here MUST NOT abort Step 11.7 or Step 12.\n\n### 11.6.1 — Cluster findings (R22, C18)\n\nOnly cluster findings whose verdict is one of the four R6 outcomes\n(`agree-will-fix | agree-won't-fix | disagree | needs-discussion`). Pre-Step-4 threads\n(`cannot-verify`, ungraded) MUST NOT enter clusters (C18).\n\nCluster key = `(hardenSurfaceHint, hardenTargetFileHint)` from each thread's manifest fields (P12\u002FP13).\n\nRules:\n- `disagree` findings require ≥2 findings with the same `hardenTargetFileHint` before forming a cluster (singleton `disagree` silently skipped).\n- Apply cap `flags.hardenClusterCap` (default 5): prune by top-highest-severity-in-cluster → ties by finding count → alphabetic on `(surface, targetFile)`.\n- Track `suppressed = totalClusters - cap` for the log entry.\n\nEmit step-emitter: `meta-analyze-findings` — started:\n```\nStep 11.6 — meta-analyze-findings: started | clusterCount=\u003CN> surfaces=[\u003Clist>]\n```\n\n### 11.6.2 — Re-run guard (KD7)\n\nScan the last 100 lines of `.sdlc\u002Flearnings\u002Flog.md` for prior `received-review-sdlc:` deferred-cluster entries whose `surface=` and `targetFile=` match the current PR's clusters. Suppress matching clusters with a `suppressed: re-run dedup` log line.\n\n### 11.6.3 — Branch on R25 auto-mode matrix\n\nGate on `flags.auto` and `flags.alwaysHardenFromReview` (resolved fields from manifest — never re-read `$ARGUMENTS` or config directly; C17).\n\n**Cell 1 — `flags.auto === false` AND `flags.alwaysHardenFromReview === false` (interactive, default):**\n\nFor each cluster, present consent gate:\n\n> **Step 11.6 — Harden proposal** — cluster: surface=`\u003ChardenSurfaceHint>`, targetFile=`\u003ChardenTargetFileHint>`, findings=`\u003Ccount>`\n>\n> Synthesized failure text: _`\u003Cfirst 200 chars of cluster body>`_\n>\n> Dispatch `harden-sdlc` for this cluster?\n\n```\nAskUserQuestion: dispatch | skip\n```\n\nEmit per cluster: `present-harden-clusters` — `consent-granted | consent-skipped`.\n\n**Cell 2 — `flags.auto === false` AND `flags.alwaysHardenFromReview === true` (interactive, always-harden):**\n\nSkip consent gate. Emit `consent-skipped` for every cluster. Proceed directly to dispatch (11.6.4).\n\n**Cell 3 — `flags.auto === true` AND `flags.alwaysHardenFromReview === false` (auto, defer):**\n\nNEVER call `AskUserQuestion` (C17). Skip consent gate. Skip dispatch entirely.\n\nAppend deferred-action entry to `.sdlc\u002Flearnings\u002Flog.md` in R26 format:\n```\n## YYYY-MM-DD — received-review-sdlc: deferred meta-analysis clusters\nPR: \u003Cpr.number>\nClusters (\u003Ccount>):\n- surface=\u003ChardenSurfaceHint> targetFile=\u003ChardenTargetFileHint> findings=\u003Ccount> verdict-mix=\u003Ccsv> failure-text-preview=\"\u003Cfirst 100 chars>\"\n- ...\nSuppressed: \u003CN> additional clusters beyond cap=\u003Ccap>\n```\n\nEmit: `dispatch-harden` — `skipped`.\n\n**Cell 4 — `flags.auto === true` AND `flags.alwaysHardenFromReview === true` (auto, always-harden):**\n\nNEVER call `AskUserQuestion` (C17). Skip consent gate. Dispatch every cluster (capped), propagating `--auto` to every `Skill(harden-sdlc)` invocation.\n\n### 11.6.4 — Dispatch per approved cluster (R23)\n\nFor each approved cluster (cells 1, 2, or 4 above):\n\n1. Synthesize `--failure-text`: concatenate cluster-member comment bodies + verification status + verdict, trimmed to 4096 chars.\n2. Dispatch:\n   ```\n   Skill(\"harden-sdlc\",\n     \"--failure-text \\\"\u003Csynthesized cluster text>\\\"\n      --skill received-review-sdlc\n      --step \\\"Step 11.6 — meta-analysis\\\"\n      --operation \\\"review-feedback-driven hardening\\\"\n      [--auto when cell 4]\"\n   )\n   ```\n3. On dispatch failure (exit ≠ 0): log one line to `.sdlc\u002Flearnings\u002Flog.md`:\n   ```\n   error: harden dispatch exit \u003Ccode> — surface=\u003Csurface> targetFile=\u003CtargetFile>\n   ```\n   Then continue to next cluster. Do NOT abort Step 11.7 or Step 12 (R25 hard rule c).\n4. Emit: `dispatch-harden` — `{ surface, targetFile, hardenExitCode }`.\n\nEmit step-emitter: `meta-analyze-findings` — completed:\n```\nStep 11.6 — meta-analyze-findings: completed | dispatched=\u003CN> deferred=\u003CN> suppressed=\u003CN>\n```\n\n---\n\n## Step 11.7 — LINK VERIFICATION (R17, issue #198) — HARD GATE\n\nBefore any `gh api` reply is posted, validate every URL embedded in every drafted reply body via the shared link validator. Concatenate all reply bodies (one per line) and feed them to the validator on stdin. The script auto-derives `expectedRepo` from `parseRemoteOwner(cwd)` and `jiraSite` from `~\u002F.sdlc-cache\u002Fjira\u002F` — the skill MUST NOT construct ctx JSON.\n\n```bash\n# Substitute \u003CPLUGIN_ROOT> from the `sdlc plugin root:` context line.\nprintf '%s\\n' \"$reply_bodies_concatenated\" | node \"\u003CPLUGIN_ROOT>\u002Fscripts\u002Flib\u002Flinks.js\" --json\nLINK_EXIT=$?\n```\n\nOn non-zero exit (`LINK_EXIT != 0`):\n- The script has already printed the violation list to stderr.\n- Do NOT post any replies. Do NOT proceed to Step 12.\n- Surface the violation list verbatim to the user.\n- Stop. Do not retry. Do not edit URLs without user input. Do not bypass.\n\nOn zero exit, proceed to Step 12. `SDLC_LINKS_OFFLINE=1` skips network reachability while keeping context-aware checks (GitHub identity match, Atlassian host match) — use in sandboxed CI.\n\n## Step 12 — REPLY & RESOLVE: Post PR Thread Replies\n\n**Mandatory step — always presented after Step 11 completes.**\n\n1. **Summarize** what was done:\n\n```\nReview feedback processing complete:\n- N comments addressed (code changes implemented)\n- M comments pushed back (with technical reasoning)\n- K comments intentionally skipped (agree, won't fix)\n```\n\n2. **Consent gate:**\n\n**Per-finding bypass rule (R18):** Skip the consent gate for finding F when\n`flags.alwaysFixSeverities` includes `F.severity` AND `F.verdict === \"agree, will fix\"` AND\n`F.severity !== null`. Such findings have their replies posted and threads resolved without a\nuser prompt; the action is logged as `fixed: \u003Cdescription>`. All other findings follow the modes\nbelow.\n\n**Auto mode:** When `flags.auto` is true (from manifest or arguments), skip the AskUserQuestion\nconsent gate. Still display the summary block above for visibility, then proceed directly to\nstep 3 below as if the user selected `yes`: post in-thread replies for every action-plan item.\n\nThread resolution behavior depends on `flags.alwaysFixSeverities`:\n- **Non-empty list:** Resolve only \"agree, will fix\" threads whose severity ∈\n  `flags.alwaysFixSeverities` (R18). \"agree, will fix\" threads with severity NOT in the list (or\n  `severity: null`) are replied to but NOT resolved — they are appended to the follow-up summary.\n- **Empty list (default):** Resolve ALL \"agree, will fix\" threads regardless of severity\n  (including `severity: null`). This is the original `--auto` behavior for users who have not\n  configured `alwaysFixSeverities`.\n\nPushback and \"won't fix\" threads are replied to but left open for the reviewer in both cases.\nPipeline context does NOT override this behavior — only the explicit `flags.auto` signal skips\nthe gate.\n\n**Manual mode (default):** When `flags.auto` is false or absent, use AskUserQuestion:\n\n> Should I reply to all addressed review comments on the PR and resolve the threads?\n\nOptions:\n- **yes** — post replies and resolve threads\n- **skip** — do not post replies (user will handle manually)\n- **selective** — let me choose which threads to reply to\n\n3. **If yes, selective, or auto mode:** For each comment in the action plan:\n\n   **Footer rule (applies to all reply types below):** Append `manifest.reply_footer` verbatim to the end of every reply body before posting. Do not modify the footer string. Do not insert it elsewhere. The footer already contains a leading blank-line separator.\n\n   **For addressed comments (agree, will fix):**\n   - Post a reply describing what was changed:\n     ```bash\n     gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n       -f body=\"Fixed — \u003Cbrief description of what was changed>\"\n     ```\n   - Resolve the thread via GraphQL mutation:\n     ```bash\n     gh api graphql -f query='mutation($threadId: ID!) { resolveReviewThread(input: {threadId: $threadId}) { thread { isResolved } } }' -F threadId=\"\u003Cthread_id>\"\n     ```\n   - In **manual `implement`\u002F`selective` modes**, always resolve all \"agree, will fix\" threads — the user has explicitly approved the action plan.\n   - In **auto mode**, resolution follows the rule in the Auto mode block above: all \"agree, will fix\" threads are resolved when `flags.alwaysFixSeverities` is empty; only severity-matching threads are resolved when the list is non-empty.\n\n   **For pushback comments (disagree):**\n   - Post the drafted pushback response (from Step 7):\n     ```bash\n     gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n       -f body=\"\u003Cpushback response>\"\n     ```\n   - Do NOT resolve the thread — leave for reviewer to evaluate\n\n   **For intentionally skipped comments (agree, won't fix):**\n   - Post a reply explaining why it was skipped:\n     ```bash\n     gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n       -f body=\"Acknowledged — not fixing in this PR because: \u003Creason>\"\n     ```\n   - Do NOT resolve — let the reviewer decide\n\n4. **Report results:**\n\n```\nReplied to N threads:\n- K resolved (fixed)\n- M replied with pushback (left open for reviewer)\n- J replied with skip reason (left open for reviewer)\n```\n\n---\n\n## Best Practices\n\n1. Read ALL feedback before responding to any of it — items may be related\n2. Verify every claim — reviewers can be wrong about what code does\n3. Group unclear items and ask once, not piecemeal\n4. Pushback is professional; blind agreement is not\n5. Implementation order matters: blocking first, cosmetic last\n6. When the reviewer is wrong, say so clearly with evidence\n7. Actions speak — a clean implementation is better than a verbose acknowledgment\n\n---\n\n## DO NOT\n\n- Use performative openers (\"Great catch!\", \"You're right!\", \"Thanks!\")\n- Agree with factually incorrect claims to avoid conflict\n- Implement unclear feedback — clarify all unclear items first\n- Implement feature requests without a YAGNI check\n- Reply top-level when the comment is in a review thread\n- Skip the self-critique steps even when evaluation seems obvious\n- Batch implement without testing each change individually\n- Express gratitude — let the code changes speak\n- Display output from internal critique steps (Steps 5-6, 8-9) to the user\n- Skip the Step 10 consent gate without an explicit `--auto` flag — pipeline context, conversation history, or inference about \"auto mode\" is not a substitute for the flag being passed\n- Use `AskUserQuestion` in Step 11.6 when `flags.auto` is true — the R25 \u002F C17 matrix governs all Step 11.6 decision sites; cite `flags.auto` and `flags.alwaysHardenFromReview` (resolved manifest fields) exclusively, never raw `$ARGUMENTS`\n\n---\n\n## Error Recovery\n\n> **Flow**: detect → diagnose → auto-recover (retry once if transient) → invoke `error-report-sdlc` for persistent actionable failures.\n\n| Error | Recovery | Invoke error-report-sdlc? |\n|-------|----------|---------------------------|\n| `gh pr view` or `gh api` fails to fetch PR comments | Check `gh auth status`; show error; ask user to supply feedback directly | No — auth or permissions issue |\n| Comment references file\u002Fline that no longer exists | Note the discrepancy; verify against current HEAD diff | No — expected with rebased PRs |\n| Cannot verify reviewer's claim (no runtime data\u002Fexternal context) | State limitation explicitly; ask user for direction | No — expected limitation |\n| `gh api` 5xx or unexpected server error when posting reply | Retry once; if still failing, show the drafted response for manual posting | Yes if second attempt also fails |\n| `skill\u002Freceived-review.js` exit 2 (script crash) | Show stderr output, invoke error-report-sdlc | Yes |\n| GraphQL resolve mutation fails | Retry once; if still failing, list which threads were not resolved | Yes if second attempt fails |\n| Thread ID not found during resolve | Skip that thread, warn user | No — expected with race conditions |\n\nWhen invoking `error-report-sdlc`, provide:\n- **Skill**: received-review-sdlc\n- **Step**: Step 11 — IMPLEMENT (posting GitHub thread replies, only after user consent in Step 10)\n- **Operation**: `gh api` call to post comment reply\n- **Error**: HTTP status + error message from above\n- **Suggested investigation**: Check `gh auth status`; verify PR number is correct and accessible; confirm repo permissions\n\n---\n\n## Gotchas\n\n- **Contradictory comments across threads:** When reviewer leaves contradictory feedback in\n  different threads, flag the contradiction and ask for clarification rather than guessing\n  which one they meant.\n- **Comments on deleted lines:** May reference code that no longer exists in the current\n  revision. Verify against current HEAD, not the diff context shown in the review.\n- **Automated review tools:** Findings from `\u002Freview-sdlc` or similar automated tools should\n  be treated as external reviewer feedback — verify each finding against actual code before\n  accepting it.\n- **Re-running after partial reply:** If the skill previously posted replies but didn't\n  resolve threads (or vice versa), re-running with the prepare script will detect\n  self-replied threads and skip them, preventing duplicate replies.\n- **GraphQL thread IDs vs REST comment IDs:** The reply endpoint uses REST `databaseId`\n  (from `comment.databaseId`), while the resolve mutation uses the GraphQL thread `id`\n  (from `thread.id`). The prepare script provides both in its manifest output.\n- **Auto mode scope:** `--auto` only auto-implements \"will fix\" items. \"Disagree\", \"needs\n  discussion\", and \"won't fix\" items are always displayed and never auto-actioned. This\n  prevents automated tools from silently suppressing pushback.\n\n---\n\n## Learning Capture\n\nAfter processing review feedback, append discoveries to `.sdlc\u002Flearnings\u002Flog.md`. Record\nentries for: reviewer patterns worth knowing (e.g., they always flag X style), pushback\noutcomes (accepted or rejected — to calibrate future responses), unclear feedback patterns\nthat revealed communication gaps, YAGNI findings that removed unnecessary work, or codebase\nfacts uncovered during verification.\n\n---\n\n## What's Next\n\nAfter replying to review threads, common follow-ups include:\n- `\u002Fcommit-sdlc` — commit the fixes\n\n## See Also\n\n- [`\u002Freview-sdlc`](..\u002Freview-sdlc\u002FSKILL.md) — source of findings this skill responds to\n- [`\u002Fcommit-sdlc`](..\u002Fcommit-sdlc\u002FSKILL.md) — commit the fixes after review\n- [`\u002Fpr-sdlc`](..\u002Fpr-sdlc\u002FSKILL.md) — the PR being reviewed\n","# Responding to Code Review Feedback\n\nProcess reviewer comments with technical rigor. Each item is verified against the full\ncodebase context — not just the change diff — before any response is drafted. Internal\nself-critique gates ensure quality. No changes are made until the user explicitly approves\nthe proposed action plan.\n\n**Announce at start:** \"I'm using received-review-sdlc (sdlc v{sdlc_version}).\" — extract the version from the `sdlc:` line in the session-start system-reminder. If no version is in context, omit the parenthetical.\n\n---\n\n## Configuration\n\n### `receivedReview.alwaysFixSeverities` (issue #233, R18\u002FR19)\n\nPer-user, per-project allowlist of finding severities whose **\"agree, will fix\"** verdicts bypass\nthe per-finding consent gate in Step 10 (PRESENT) and Step 12 (REPLY & RESOLVE).\n\n- **Location:** `.sdlc\u002Flocal.json` under `receivedReview.alwaysFixSeverities` (gitignored, per-user).\n  This field is **local-only** — it MUST NEVER be set in `.sdlc\u002Fconfig.json`. The prepare script\n  emits a stderr warning and ignores the value if it appears in project config (R19).\n- **Type:** `string[]` — array of severities; allowed values: `low | medium | high | critical`.\n- **Default:** `[]` — preserves the original consent-on-every-finding behavior.\n- **Resolution site:** the prepare script `skill\u002Freceived-review.js` resolves the field once and\n  emits it as `flags.alwaysFixSeverities` in the manifest. All decision sites in this SKILL.md\n  cite `flags.alwaysFixSeverities` only — never re-read configuration.\n\n**Example (`.sdlc\u002Flocal.json`):**\n\n```json\n{\n  \"receivedReview\": {\n    \"alwaysFixSeverities\": [\"critical\", \"high\"]\n  }\n}\n```\n\n**Auto-apply rule (R18):** A finding is auto-applied (no consent prompt) when **all three** hold:\n\n1. The verdict is `agree, will fix`\n2. The finding's parsed severity is non-null\n3. The severity ∈ `flags.alwaysFixSeverities`\n\nA finding with `severity: null` (severity could not be parsed from the comment body) **NEVER**\nbypasses the consent gate, regardless of `flags.alwaysFixSeverities`.\n\n**`--auto` interaction (R10\u002FR16):** When `flags.alwaysFixSeverities` is non-empty, `--auto`\nis further restricted by R18: only \"will fix\" findings whose severity is in the list are\nimplemented in Step 11; remaining \"will fix\" findings (severity not in the list, or\n`severity: null`) are collected into a **follow-up summary** appended to the response output.\nIn Step 12, only \"agree, will fix\" threads matching R18 are resolved; other threads are replied\nto but left open.\n\nWhen `flags.alwaysFixSeverities` is empty (the default — `alwaysFixSeverities` unset in\n`.sdlc\u002Flocal.json`), `--auto` falls back to the original behavior: **all** \"will fix\" findings\nare auto-applied in Step 11 and all \"agree, will fix\" threads are resolved in Step 12, regardless\nof severity (including `severity: null`). This preserves backward compatibility for users who\nhave not configured the field.\n\nTo configure interactively, run `\u002Fsetup-sdlc --only received-review`.\n\n### `receivedReview.alwaysHardenFromReview` (issue #429, R24)\n\nPer-user flag that controls whether Step 11.6 (META-ANALYZE) automatically dispatches\n`Skill(harden-sdlc)` per cluster without asking for consent.\n\n- **Location:** `.sdlc\u002Flocal.json` under `receivedReview.alwaysHardenFromReview` (gitignored, per-user).\n  This field is **local-only** — it MUST NEVER be set in `.sdlc\u002Fconfig.json`. The prepare script\n  emits a stderr warning and ignores the value if it appears in project config (R24).\n- **Type:** `boolean` — default `false`.\n- **Scope:** applies uniformly to all Step 11.6 cluster dispatches in every run.\n\n**Auto-mode matrix (R25 — all four cells authoritative):**\n\n| `flags.auto` | `flags.alwaysHardenFromReview` | Step 11.6 behavior |\n|---|---|---|\n| `false` | `false` | Present consent gate per cluster → dispatch approved clusters only. |\n| `false` | `true`  | Skip consent gate → dispatch every cluster (capped at `hardenClusterCap`). |\n| `true`  | `false` | Skip consent gate AND skip dispatch entirely → append deferred-action entry to `.sdlc\u002Flearnings\u002Flog.md` (R26 format). |\n| `true`  | `true`  | Skip consent gate → dispatch every cluster (capped), propagating `--auto` to every dispatch. |\n\n**Single resolution site:** `skill\u002Freceived-review.js` (prepare script). SKILL.md cites\n`flags.alwaysHardenFromReview` only — never raw `$ARGUMENTS` or `.sdlc\u002Flocal.json` directly.\n\n**Example `.sdlc\u002Flocal.json`:**\n```json\n{\n  \"receivedReview\": {\n    \"alwaysHardenFromReview\": true,\n    \"hardenClusterCap\": 5\n  }\n}\n```\n\n### `receivedReview.hardenClusterCap` (issue #429, P15)\n\nMaximum number of harden-sdlc clusters dispatched per Step 11.6 run.\n\n- **Location:** `.sdlc\u002Flocal.json` under `receivedReview.hardenClusterCap`.\n- **Type:** `integer` — default `5`, clamped to `[1, 50]`.\n- Excess clusters beyond the cap are suppressed and logged as `suppressed: N additional clusters`\n  in the deferred-action entry or the learning-log dispatch record.\n\n---\n\n## Step 0 — Plan Mode Check\n\nIf the system context contains \"Plan mode is active\":\n\n1. Announce: \"This skill requires write operations (file edits, gh api calls). Exit plan mode first, then re-invoke `\u002Freceived-review-sdlc`.\"\n2. Stop. Do not proceed to subsequent steps.\n\n---\n\n## Step 1 — READ: Gather Review Feedback\n\n### Step 1a — Run skill\u002Freceived-review.js (when PR number available)\n\nWhen a PR number or URL is provided (via arguments or user input), run the prepare script to pre-compute review thread state:\n\n```bash\n# Substitute \u003CPLUGIN_ROOT> from the `sdlc plugin root:` context line.\nMANIFEST_FILE=$(node \"\u003CPLUGIN_ROOT>\u002Fscripts\u002Fskill\u002Freceived-review.js\" --output-file $ARGUMENTS --pr \u003CPR_NUMBER>)\nEXIT_CODE=$?\necho \"MANIFEST_FILE=$MANIFEST_FILE\"\necho \"EXIT_CODE=$EXIT_CODE\"\n# Single canonical cleanup: trap fires unconditionally on EXIT\u002FINT\u002FTERM.\ntrap 'rm -f \"$MANIFEST_FILE\"' EXIT INT TERM\n```\n\n**On exit code 0:** Read the manifest JSON. Extract `flags.auto` from the manifest and store it as a boolean (defaults to `false` if absent). If `--auto` was passed in `$ARGUMENTS` but not in the manifest, treat it as `true`. Display the incremental summary:\n\n```\nFound N outstanding comments (M resolved, K already replied, J stale — skipped).\nProcessing only the N outstanding comments.\n```\n\nUse only threads with `status: \"outstanding\"` for Steps 2–11. Store the full manifest (including resolved\u002Fself-replied\u002Fstale threads) for use in Step 12 (PR Reply & Resolve).\n\n**On exit code 1:** No PR found or missing arguments. Fall back to Step 1b.\n\n**On exit code 2:** Script error. Invoke `error-report-sdlc` with:\n- **Skill:** received-review-sdlc\n- **Step:** Step 1 — READ\n- **Operation:** skill\u002Freceived-review.js execution\n- **Error:** stderr output from the script\n\n### Step 1b — Manual feedback gathering (fallback)\n\nWhen no PR number is available, the prepare script is not found, or Step 1a fails:\n\nLocate the review feedback from one of:\n- Findings already in conversation context (e.g. passed in from `\u002Freview-sdlc`)\n- User paste\n- PR URL — fetch with:\n  ```bash\n  gh pr view \u003Cnumber> --comments\n  gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Freviews\n  ```\n\nParse each comment into a structured list:\n\n```\n| # | File | Line | Reviewer | Comment | Type |\n```\n\nType classification: `bug`, `style`, `architecture`, `feature-request`, `question`, `unclear`.\n\n---\n\n## Step 2 — UNDERSTAND: Categorize and Flag\n\nFor each item:\n- Assign a type from the classification above\n- Flag items that are **unclear** (ambiguous intent, missing context, could be interpreted multiple ways)\n\n**CRITICAL:** If ANY item is unclear:\n```\nSTOP — do not implement anything yet.\nAsk for clarification on ALL unclear items at once.\nWHY: Items may be related. Partial understanding = wrong implementation.\n```\n\nOnly proceed to Step 3 after all items are understood.\n\n---\n\n## Step 3 — VERIFY: Check Against Full Codebase Context\n\nFor each feedback item, gather context beyond the immediate change diff:\n\n1. **Read the referenced code** — understand what the code actually does\n2. **Trace callers and dependents** — use LSP references or grep to find who calls the changed code, what imports it, and what would be affected by the suggested change\n3. **Check architectural context** — read related modules, interfaces, and tests to understand the design intent behind the current implementation\n4. **Evaluate ripple effects** — determine whether the suggested change would break or improve behavior beyond the immediate diff\n\nDetermine the verification status:\n- **confirmed** — reviewer's claim is correct, and the suggestion works in full context\n- **confirmed, but suggestion is incomplete** — the issue is real but the proposed fix has side effects or misses related code that also needs updating\n- **incorrect** — reviewer is wrong about what the code does\n- **partially correct** — some aspects correct, some not\n- **cannot verify** — would need runtime data or external context\n\nFor \"cannot verify\" items: state the limitation explicitly, ask the user for direction.\n\n---\n\n## Step 4 — EVALUATE: Assess Each Item\n\nUsing verification results, determine for each item:\n\n- **agree, will fix** — technically correct, should be changed\n- **agree, won't fix** — correct but out of scope or lower priority (state reason)\n- **disagree** — technically incorrect for this codebase (provide reasoning)\n- **needs discussion** — architectural impact, requires owner input\n\n**YAGNI check for feature requests:**\n```\ngrep codebase for actual usage\nIF unused: \"This isn't called anywhere. Remove it (YAGNI)? Or is there usage I'm missing?\"\nIF used: Then evaluate the suggestion on merit\n```\n\n**Source trust:**\n- Trusted partner feedback: implement after understanding, skip performative agreement\n- External\u002Fautomated reviewer: verify technically, apply YAGNI, push back if wrong\n\n---\n\n## Step 5 — CRITIQUE #1: Self-Critique the Evaluation\n\n> **INTERNAL** — Do not display gate results, pass\u002Ffail status, or any output from this step to the user. Process silently and proceed to the next step.\n\nBefore drafting responses, review the evaluation against these gates:\n\n| Gate | Check | Pass Criteria |\n|------|-------|--------------|\n| Verification completeness | Every item verified against actual code | No item evaluated without reading relevant source |\n| No blind agreement | Disagreements exist where technically warranted | Not everything marked \"agree\" unless genuinely correct |\n| YAGNI applied | Feature suggestions checked for real vs hypothetical need | No \"sounds good, will add\" for speculative features |\n| Unclear items resolved | All unclear items clarified before proceeding | Not implementing partial feedback |\n| Technical grounding | Every agree\u002Fdisagree decision cites code or behavior | No decisions based on \"seems right\" without evidence |\n\nNote every failing gate.\n\n---\n\n## Step 6 — IMPROVE #1: Revise Evaluation\n\n> **INTERNAL** — Do not display output from this step to the user. Process silently.\n\nFix each issue found in Step 5:\n- Re-read code for items where verification was incomplete\n- Strengthen technical reasoning where it was vague\n- Reclassify items where the initial assessment was unsupported\n\nContinue until all gates pass (max 2 iterations per gate).\n\n---\n\n## Step 7 — RESPOND (DO): Draft Responses\n\nDraft a response for each item. Response structure per item:\n\n1. Factual acknowledgment of what was said (no performative openers)\n2. What will be done OR technical reason for disagreement\n3. If implementing: brief description of approach\n\n**Forbidden openers — NEVER use:**\n- \"You're absolutely right!\"\n- \"Great point!\" \u002F \"Excellent feedback!\"\n- \"Thanks for catching that!\" \u002F Any gratitude expression\n- \"Let me implement that now\" (before verification)\n\n**Instead, start with the substance:**\n- Restate the technical issue\n- State the decision (fix \u002F won't fix \u002F disagree)\n- Provide reasoning\n\n**Pushback format:**\n```\nChecked [specific code location]. [What it actually does]. [Consequence of the suggested change].\nDecision: [keeping as-is \u002F discussing with owner \u002F needs more context].\n```\n\n**GitHub thread replies:** Reply in-thread using the comment ID, not as a top-level PR comment:\n```bash\ngh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n  -f body=\"\u003Cresponse text>\"\n```\n\n**Version footer:** Append `manifest.reply_footer` verbatim to the end of every reply body before posting. Do not modify the footer string. Do not insert it elsewhere. The footer is a single string with a leading blank-line separator already included — append it directly to the reply body with no additional separator.\n\n---\n\n## Step 8 — CRITIQUE #2: Self-Critique the Responses\n\n> **INTERNAL** — Do not display gate results, pass\u002Ffail status, or any output from this step to the user. Process silently and proceed to the next step.\n\nReview drafted responses against these gates:\n\n| Gate | Check | Pass Criteria |\n|------|-------|--------------|\n| No performative language | Zero forbidden openers or gratuitous praise | Responses start with substance, not social filler |\n| Technically grounded | Every response references specific code, behavior, or constraint | No hand-waving (\"this should be fine\") |\n| Pushback is technical | Disagreements cite code, performance data, or design constraints | No \"I prefer\" or \"I think\" without backing evidence |\n| Thread-level replies | Each response targets its specific comment thread | No top-level dump of all responses |\n| Implementation plan clear | For accepted items, response states what will change | Reviewer knows what to expect in next push |\n| No blind agreement | Factual errors corrected, not accommodated | Incorrect reviewer claims are challenged |\n| Proportional effort | Simple fixes get short responses; complex items get detailed ones | No walls of text for typo fixes |\n\nNote every failing gate.\n\n---\n\n## Step 9 — IMPROVE #2: Revise Responses\n\n> **INTERNAL** — Do not display output from this step to the user. Process silently.\n\nFix each issue found in Step 8:\n- Delete performative openers, replace with substance\n- Add specific code references where missing\n- Shorten over-explained simple fixes\n\nContinue until all gates pass (max 2 iterations per gate).\n\n---\n\n## Step 10 — PRESENT: Show Findings and Proposed Plan\n\nThis is the first user-visible output after the analysis phase. Present the complete analysis\nand proposed actions to the user. **No changes have been made yet.**\n\n**1. Analysis summary table:**\n\n```\n| # | File | Line | Type | Verdict | Reasoning |\n```\n\nShow every item with its type (bug, style, architecture, etc.) and verdict (agree will fix \u002F\nagree won't fix \u002F disagree \u002F needs discussion) with a one-line reasoning summary.\n\n**2. Proposed action plan:**\n\nGroup items by action:\n- **Will fix:** list items with brief description of the change\n- **Will push back:** list items with the core technical reason\n- **Needs discussion:** list items with what's unresolved\n\n**3. Drafted PR responses:**\n\nShow the full text of each drafted response, labeled by item number.\n\n**4. Consent gate:**\n\n**Per-finding bypass rule (R18):** Skip the consent gate for finding F when\n`flags.alwaysFixSeverities` includes `F.severity` AND `F.verdict === \"agree, will fix\"` AND\n`F.severity !== null`. Such findings are auto-applied with a one-line `fixed: \u003Cdescription>`\nlog entry and require no user prompt. All other findings (any other verdict, severity not in\nthe list, or `severity: null`) follow the modes below.\n\n**Auto mode:** When `flags.auto` is true (from manifest or arguments):\n- If `flags.alwaysFixSeverities` is **non-empty**: apply only \"agree, will fix\" findings whose\n  severity ∈ `flags.alwaysFixSeverities` (per the R18 bypass rule above). Remaining \"agree, will\n  fix\" findings — severity NOT in the list, or `severity: null` — are collected into a\n  **follow-up summary** appended to the response output (not auto-applied).\n- If `flags.alwaysFixSeverities` is **empty** (default): apply **all** \"agree, will fix\" findings\n  regardless of severity (including `severity: null`). This is the original `--auto` behavior and\n  is the default for users who have not configured `alwaysFixSeverities`.\n\nItems with \"disagree\", \"needs discussion\", or \"won't fix\" verdicts are displayed but NEVER\nauto-actioned in either case. Still display the full analysis table and action plan above for\nvisibility, then proceed directly to Step 11.\n\n**Manual mode (default):** When `flags.auto` is false or absent, use AskUserQuestion to ask:\n> No changes have been made yet. How to proceed?\n\nOptions:\n- **implement** — post responses to PR and apply code changes\n- **edit** — modify the plan before proceeding\n- **skip** — discard, make no changes\n\nIf the user chooses **edit**, ask what to change, revise, and present again.\nLoop until explicit **implement** or **skip**.\n\n**Do NOT proceed to Step 11 without explicit `implement` from the user via AskUserQuestion**, EXCEPT\nfor findings that satisfy the R18 bypass rule above — those are auto-applied without prompting and\nemit a `fixed: ...` log line. Findings outside the R18 bypass set still require explicit\n`implement` consent.\n\n**Without `--auto`, pipeline context does NOT override this gate** (except for findings satisfying\nthe R18 bypass rule). Even when invoked from `\u002Fship-sdlc`, if `--auto` was not explicitly passed\nas a flag, this consent gate is mandatory for findings outside the R18 bypass set. Do not infer\nfrom surrounding context that automatic execution is expected.\n\n---\n\n## Step 11 — IMPLEMENT: Execute Changes\n\n**Only execute after explicit `implement` from Step 10, OR when `flags.auto` is true (auto-proceed for \"will fix\" items only), OR when the finding satisfies the R18 bypass rule from Step 10 (severity ∈ `flags.alwaysFixSeverities` AND verdict is \"agree, will fix\" AND `severity !== null`).** Findings auto-applied via R18 emit a one-line `fixed: \u003Cdescription>` log entry instead of a consent prompt.\n\nPost responses to PR threads, then implement accepted code changes.\n\n**Implementation order:**\n1. Blocking issues (breaks functionality, security)\n2. Simple fixes (typos, imports, naming)\n3. Complex fixes (refactoring, logic changes)\n\nFor each change: make the edit, verify it compiles\u002Fpasses tests, then move to the next.\nDo NOT batch changes across items.\n\n**Items marked \"disagree\" or \"needs discussion\":** Do NOT implement — await reviewer or\nowner input.\n\n**Gracefully correcting wrong pushback:**\nIf you pushed back and were wrong:\n```\nCorrect: \"You were right — I checked [X] and it does [Y]. Implementing now.\"\nWrong:   Long apology, defensive explanation, over-explaining\n```\nState the correction factually and move on.\n\n---\n\n## Step 11.6 — META-ANALYZE: Cluster Findings and Dispatch harden-sdlc (R21–R26)\n\n**Best-effort step.** Failure here MUST NOT abort Step 11.7 or Step 12.\n\n### 11.6.1 — Cluster findings (R22, C18)\n\nOnly cluster findings whose verdict is one of the four R6 outcomes\n(`agree-will-fix | agree-won't-fix | disagree | needs-discussion`). Pre-Step-4 threads\n(`cannot-verify`, ungraded) MUST NOT enter clusters (C18).\n\nCluster key = `(hardenSurfaceHint, hardenTargetFileHint)` from each thread's manifest fields (P12\u002FP13).\n\nRules:\n- `disagree` findings require ≥2 findings with the same `hardenTargetFileHint` before forming a cluster (singleton `disagree` silently skipped).\n- Apply cap `flags.hardenClusterCap` (default 5): prune by top-highest-severity-in-cluster → ties by finding count → alphabetic on `(surface, targetFile)`.\n- Track `suppressed = totalClusters - cap` for the log entry.\n\nEmit step-emitter: `meta-analyze-findings` — started:\n```\nStep 11.6 — meta-analyze-findings: started | clusterCount=\u003CN> surfaces=[\u003Clist>]\n```\n\n### 11.6.2 — Re-run guard (KD7)\n\nScan the last 100 lines of `.sdlc\u002Flearnings\u002Flog.md` for prior `received-review-sdlc:` deferred-cluster entries whose `surface=` and `targetFile=` match the current PR's clusters. Suppress matching clusters with a `suppressed: re-run dedup` log line.\n\n### 11.6.3 — Branch on R25 auto-mode matrix\n\nGate on `flags.auto` and `flags.alwaysHardenFromReview` (resolved fields from manifest — never re-read `$ARGUMENTS` or config directly; C17).\n\n**Cell 1 — `flags.auto === false` AND `flags.alwaysHardenFromReview === false` (interactive, default):**\n\nFor each cluster, present consent gate:\n\n> **Step 11.6 — Harden proposal** — cluster: surface=`\u003ChardenSurfaceHint>`, targetFile=`\u003ChardenTargetFileHint>`, findings=`\u003Ccount>`\n>\n> Synthesized failure text: _`\u003Cfirst 200 chars of cluster body>`_\n>\n> Dispatch `harden-sdlc` for this cluster?\n\n```\nAskUserQuestion: dispatch | skip\n```\n\nEmit per cluster: `present-harden-clusters` — `consent-granted | consent-skipped`.\n\n**Cell 2 — `flags.auto === false` AND `flags.alwaysHardenFromReview === true` (interactive, always-harden):**\n\nSkip consent gate. Emit `consent-skipped` for every cluster. Proceed directly to dispatch (11.6.4).\n\n**Cell 3 — `flags.auto === true` AND `flags.alwaysHardenFromReview === false` (auto, defer):**\n\nNEVER call `AskUserQuestion` (C17). Skip consent gate. Skip dispatch entirely.\n\nAppend deferred-action entry to `.sdlc\u002Flearnings\u002Flog.md` in R26 format:\n```\n## YYYY-MM-DD — received-review-sdlc: deferred meta-analysis clusters\nPR: \u003Cpr.number>\nClusters (\u003Ccount>):\n- surface=\u003ChardenSurfaceHint> targetFile=\u003ChardenTargetFileHint> findings=\u003Ccount> verdict-mix=\u003Ccsv> failure-text-preview=\"\u003Cfirst 100 chars>\"\n- ...\nSuppressed: \u003CN> additional clusters beyond cap=\u003Ccap>\n```\n\nEmit: `dispatch-harden` — `skipped`.\n\n**Cell 4 — `flags.auto === true` AND `flags.alwaysHardenFromReview === true` (auto, always-harden):**\n\nNEVER call `AskUserQuestion` (C17). Skip consent gate. Dispatch every cluster (capped), propagating `--auto` to every `Skill(harden-sdlc)` invocation.\n\n### 11.6.4 — Dispatch per approved cluster (R23)\n\nFor each approved cluster (cells 1, 2, or 4 above):\n\n1. Synthesize `--failure-text`: concatenate cluster-member comment bodies + verification status + verdict, trimmed to 4096 chars.\n2. Dispatch:\n   ```\n   Skill(\"harden-sdlc\",\n     \"--failure-text \\\"\u003Csynthesized cluster text>\\\"\n      --skill received-review-sdlc\n      --step \\\"Step 11.6 — meta-analysis\\\"\n      --operation \\\"review-feedback-driven hardening\\\"\n      [--auto when cell 4]\"\n   )\n   ```\n3. On dispatch failure (exit ≠ 0): log one line to `.sdlc\u002Flearnings\u002Flog.md`:\n   ```\n   error: harden dispatch exit \u003Ccode> — surface=\u003Csurface> targetFile=\u003CtargetFile>\n   ```\n   Then continue to next cluster. Do NOT abort Step 11.7 or Step 12 (R25 hard rule c).\n4. Emit: `dispatch-harden` — `{ surface, targetFile, hardenExitCode }`.\n\nEmit step-emitter: `meta-analyze-findings` — completed:\n```\nStep 11.6 — meta-analyze-findings: completed | dispatched=\u003CN> deferred=\u003CN> suppressed=\u003CN>\n```\n\n---\n\n## Step 11.7 — LINK VERIFICATION (R17, issue #198) — HARD GATE\n\nBefore any `gh api` reply is posted, validate every URL embedded in every drafted reply body via the shared link validator. Concatenate all reply bodies (one per line) and feed them to the validator on stdin. The script auto-derives `expectedRepo` from `parseRemoteOwner(cwd)` and `jiraSite` from `~\u002F.sdlc-cache\u002Fjira\u002F` — the skill MUST NOT construct ctx JSON.\n\n```bash\n# Substitute \u003CPLUGIN_ROOT> from the `sdlc plugin root:` context line.\nprintf '%s\\n' \"$reply_bodies_concatenated\" | node \"\u003CPLUGIN_ROOT>\u002Fscripts\u002Flib\u002Flinks.js\" --json\nLINK_EXIT=$?\n```\n\nOn non-zero exit (`LINK_EXIT != 0`):\n- The script has already printed the violation list to stderr.\n- Do NOT post any replies. Do NOT proceed to Step 12.\n- Surface the violation list verbatim to the user.\n- Stop. Do not retry. Do not edit URLs without user input. Do not bypass.\n\nOn zero exit, proceed to Step 12. `SDLC_LINKS_OFFLINE=1` skips network reachability while keeping context-aware checks (GitHub identity match, Atlassian host match) — use in sandboxed CI.\n\n## Step 12 — REPLY & RESOLVE: Post PR Thread Replies\n\n**Mandatory step — always presented after Step 11 completes.**\n\n1. **Summarize** what was done:\n\n```\nReview feedback processing complete:\n- N comments addressed (code changes implemented)\n- M comments pushed back (with technical reasoning)\n- K comments intentionally skipped (agree, won't fix)\n```\n\n2. **Consent gate:**\n\n**Per-finding bypass rule (R18):** Skip the consent gate for finding F when\n`flags.alwaysFixSeverities` includes `F.severity` AND `F.verdict === \"agree, will fix\"` AND\n`F.severity !== null`. Such findings have their replies posted and threads resolved without a\nuser prompt; the action is logged as `fixed: \u003Cdescription>`. All other findings follow the modes\nbelow.\n\n**Auto mode:** When `flags.auto` is true (from manifest or arguments), skip the AskUserQuestion\nconsent gate. Still display the summary block above for visibility, then proceed directly to\nstep 3 below as if the user selected `yes`: post in-thread replies for every action-plan item.\n\nThread resolution behavior depends on `flags.alwaysFixSeverities`:\n- **Non-empty list:** Resolve only \"agree, will fix\" threads whose severity ∈\n  `flags.alwaysFixSeverities` (R18). \"agree, will fix\" threads with severity NOT in the list (or\n  `severity: null`) are replied to but NOT resolved — they are appended to the follow-up summary.\n- **Empty list (default):** Resolve ALL \"agree, will fix\" threads regardless of severity\n  (including `severity: null`). This is the original `--auto` behavior for users who have not\n  configured `alwaysFixSeverities`.\n\nPushback and \"won't fix\" threads are replied to but left open for the reviewer in both cases.\nPipeline context does NOT override this behavior — only the explicit `flags.auto` signal skips\nthe gate.\n\n**Manual mode (default):** When `flags.auto` is false or absent, use AskUserQuestion:\n\n> Should I reply to all addressed review comments on the PR and resolve the threads?\n\nOptions:\n- **yes** — post replies and resolve threads\n- **skip** — do not post replies (user will handle manually)\n- **selective** — let me choose which threads to reply to\n\n3. **If yes, selective, or auto mode:** For each comment in the action plan:\n\n   **Footer rule (applies to all reply types below):** Append `manifest.reply_footer` verbatim to the end of every reply body before posting. Do not modify the footer string. Do not insert it elsewhere. The footer already contains a leading blank-line separator.\n\n   **For addressed comments (agree, will fix):**\n   - Post a reply describing what was changed:\n     ```bash\n     gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n       -f body=\"Fixed — \u003Cbrief description of what was changed>\"\n     ```\n   - Resolve the thread via GraphQL mutation:\n     ```bash\n     gh api graphql -f query='mutation($threadId: ID!) { resolveReviewThread(input: {threadId: $threadId}) { thread { isResolved } } }' -F threadId=\"\u003Cthread_id>\"\n     ```\n   - In **manual `implement`\u002F`selective` modes**, always resolve all \"agree, will fix\" threads — the user has explicitly approved the action plan.\n   - In **auto mode**, resolution follows the rule in the Auto mode block above: all \"agree, will fix\" threads are resolved when `flags.alwaysFixSeverities` is empty; only severity-matching threads are resolved when the list is non-empty.\n\n   **For pushback comments (disagree):**\n   - Post the drafted pushback response (from Step 7):\n     ```bash\n     gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n       -f body=\"\u003Cpushback response>\"\n     ```\n   - Do NOT resolve the thread — leave for reviewer to evaluate\n\n   **For intentionally skipped comments (agree, won't fix):**\n   - Post a reply explaining why it was skipped:\n     ```bash\n     gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{pr}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n       -f body=\"Acknowledged — not fixing in this PR because: \u003Creason>\"\n     ```\n   - Do NOT resolve — let the reviewer decide\n\n4. **Report results:**\n\n```\nReplied to N threads:\n- K resolved (fixed)\n- M replied with pushback (left open for reviewer)\n- J replied with skip reason (left open for reviewer)\n```\n\n---\n\n## Best Practices\n\n1. Read ALL feedback before responding to any of it — items may be related\n2. Verify every claim — reviewers can be wrong about what code does\n3. Group unclear items and ask once, not piecemeal\n4. Pushback is professional; blind agreement is not\n5. Implementation order matters: blocking first, cosmetic last\n6. When the reviewer is wrong, say so clearly with evidence\n7. Actions speak — a clean implementation is better than a verbose acknowledgment\n\n---\n\n## DO NOT\n\n- Use performative openers (\"Great catch!\", \"You're right!\", \"Thanks!\")\n- Agree with factually incorrect claims to avoid conflict\n- Implement unclear feedback — clarify all unclear items first\n- Implement feature requests without a YAGNI check\n- Reply top-level when the comment is in a review thread\n- Skip the self-critique steps even when evaluation seems obvious\n- Batch implement without testing each change individually\n- Express gratitude — let the code changes speak\n- Display output from internal critique steps (Steps 5-6, 8-9) to the user\n- Skip the Step 10 consent gate without an explicit `--auto` flag — pipeline context, conversation history, or inference about \"auto mode\" is not a substitute for the flag being passed\n- Use `AskUserQuestion` in Step 11.6 when `flags.auto` is true — the R25 \u002F C17 matrix governs all Step 11.6 decision sites; cite `flags.auto` and `flags.alwaysHardenFromReview` (resolved manifest fields) exclusively, never raw `$ARGUMENTS`\n\n---\n\n## Error Recovery\n\n> **Flow**: detect → diagnose → auto-recover (retry once if transient) → invoke `error-report-sdlc` for persistent actionable failures.\n\n| Error | Recovery | Invoke error-report-sdlc? |\n|-------|----------|---------------------------|\n| `gh pr view` or `gh api` fails to fetch PR comments | Check `gh auth status`; show error; ask user to supply feedback directly | No — auth or permissions issue |\n| Comment references file\u002Fline that no longer exists | Note the discrepancy; verify against current HEAD diff | No — expected with rebased PRs |\n| Cannot verify reviewer's claim (no runtime data\u002Fexternal context) | State limitation explicitly; ask user for direction | No — expected limitation |\n| `gh api` 5xx or unexpected server error when posting reply | Retry once; if still failing, show the drafted response for manual posting | Yes if second attempt also fails |\n| `skill\u002Freceived-review.js` exit 2 (script crash) | Show stderr output, invoke error-report-sdlc | Yes |\n| GraphQL resolve mutation fails | Retry once; if still failing, list which threads were not resolved | Yes if second attempt fails |\n| Thread ID not found during resolve | Skip that thread, warn user | No — expected with race conditions |\n\nWhen invoking `error-report-sdlc`, provide:\n- **Skill**: received-review-sdlc\n- **Step**: Step 11 — IMPLEMENT (posting GitHub thread replies, only after user consent in Step 10)\n- **Operation**: `gh api` call to post comment reply\n- **Error**: HTTP status + error message from above\n- **Suggested investigation**: Check `gh auth status`; verify PR number is correct and accessible; confirm repo permissions\n\n---\n\n## Gotchas\n\n- **Contradictory comments across threads:** When reviewer leaves contradictory feedback in\n  different threads, flag the contradiction and ask for clarification rather than guessing\n  which one they meant.\n- **Comments on deleted lines:** May reference code that no longer exists in the current\n  revision. Verify against current HEAD, not the diff context shown in the review.\n- **Automated review tools:** Findings from `\u002Freview-sdlc` or similar automated tools should\n  be treated as external reviewer feedback — verify each finding against actual code before\n  accepting it.\n- **Re-running after partial reply:** If the skill previously posted replies but didn't\n  resolve threads (or vice versa), re-running with the prepare script will detect\n  self-replied threads and skip them, preventing duplicate replies.\n- **GraphQL thread IDs vs REST comment IDs:** The reply endpoint uses REST `databaseId`\n  (from `comment.databaseId`), while the resolve mutation uses the GraphQL thread `id`\n  (from `thread.id`). The prepare script provides both in its manifest output.\n- **Auto mode scope:** `--auto` only auto-implements \"will fix\" items. \"Disagree\", \"needs\n  discussion\", and \"won't fix\" items are always displayed and never auto-actioned. This\n  prevents automated tools from silently suppressing pushback.\n\n---\n\n## Learning Capture\n\nAfter processing review feedback, append discoveries to `.sdlc\u002Flearnings\u002Flog.md`. Record\nentries for: reviewer patterns worth knowing (e.g., they always flag X style), pushback\noutcomes (accepted or rejected — to calibrate future responses), unclear feedback patterns\nthat revealed communication gaps, YAGNI findings that removed unnecessary work, or codebase\nfacts uncovered during verification.\n\n---\n\n## What's Next\n\nAfter replying to review threads, common follow-ups include:\n- `\u002Fcommit-sdlc` — commit the fixes\n\n## See Also\n\n- [`\u002Freview-sdlc`](..\u002Freview-sdlc\u002FSKILL.md) — source of findings this skill responds to\n- [`\u002Fcommit-sdlc`](..\u002Fcommit-sdlc\u002FSKILL.md) — commit the fixes after review\n- [`\u002Fpr-sdlc`](..\u002Fpr-sdlc\u002FSKILL.md) — the PR being reviewed\n",{"name":5,"model":49,"description":7,"argument-hint":50,"user-invocable":51},"opus","[--pr \u003Cnumber>] [--auto]",true,"main","3480d74fa3b8cb64fff5c365fbeb6e00d2708e53","plugins\u002Fsdlc-utilities\u002Fskills\u002Freceived-review-sdlc",6,"https:\u002F\u002Fgithub.com\u002Frnagrodzki\u002Fsdlc-marketplace","https:\u002F\u002Fgithub.com\u002Frnagrodzki","http:\u002F\u002Fnagrodzki.net","2026-09-05 21:47:31",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":51},[62,65,68],{"tool":63,"command":64},"npx","npx skills add rnagrodzki\u002Fsdlc-marketplace --skill received-review-sdlc",{"tool":66,"command":67},"bunx","bunx skills add rnagrodzki\u002Fsdlc-marketplace --skill received-review-sdlc",{"tool":69,"command":70},"pnpm","pnpm dlx skills add rnagrodzki\u002Fsdlc-marketplace --skill received-review-sdlc","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frnagrodzki\u002Fsdlc-marketplace\u002Fblob\u002Fmain\u002Fplugins\u002Fsdlc-utilities\u002Fskills\u002Freceived-review-sdlc\u002FSKILL.md",[],[74,90,97,107,116,127],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":83,"publishedAt":44},"01M6CYJDSW8MAAJAM62G7ZPRVB","example-skill","Test fixture — passing case for script-resolution-version rule.","https:\u002F\u002Fgithub.com\u002Frnagrodzki\u002Fsdlc-marketplace\u002Fblob\u002Fmain\u002Ftests\u002Fpromptfoo\u002Ffixtures-fs\u002Fresolution-validator-cases\u002Fgood-project\u002Fplugins\u002Fsdlc-utilities\u002Fskills\u002Fexample-skill\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[84,85,86,87,88,89],"example skill","example","fixture","test","version","resolution",{"skillNo":91,"name":76,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":96,"publishedAt":44},"01M6CYJCBDNB7S40VZ1B0TEFE1","Test fixture — failing case for script-resolution-version rule.","https:\u002F\u002Fgithub.com\u002Frnagrodzki\u002Fsdlc-marketplace\u002Fblob\u002Fmain\u002Ftests\u002Fpromptfoo\u002Ffixtures-fs\u002Fresolution-validator-cases\u002Fbad-project\u002Fplugins\u002Fsdlc-utilities\u002Fskills\u002Fexample-skill\u002FSKILL.md",[95],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},[85,84,87,88,86,89],{"skillNo":98,"name":76,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":103,"publishedAt":44},"01M6CYJARTK87CH0T6EJ7ZQCZV","Test fixture — passing case for the orchestrator-await-barrier rule (#487). Marks a fan-out dispatch as await-barrier-required and states the guard.","https:\u002F\u002Fgithub.com\u002Frnagrodzki\u002Fsdlc-marketplace\u002Fblob\u002Fmain\u002Ftests\u002Fpromptfoo\u002Ffixtures-fs\u002Forchestrator-await-barrier-cases\u002Fgood-project\u002Fplugins\u002Fsdlc-utilities\u002Fskills\u002Fexample-skill\u002FSKILL.md",[102],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},[84,85,104,105,106,86,87],"guard","orchestrator","dispatch",{"skillNo":108,"name":76,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":44},"01M6CYJ8T4G8CQDWGZKGW1THNZ","Test fixture — failing case for the orchestrator-await-barrier rule (#487). Marks a fan-out dispatch as await-barrier-required but never states the guard.","https:\u002F\u002Fgithub.com\u002Frnagrodzki\u002Fsdlc-marketplace\u002Fblob\u002Fmain\u002Ftests\u002Fpromptfoo\u002Ffixtures-fs\u002Forchestrator-await-barrier-cases\u002Fbad-project\u002Fplugins\u002Fsdlc-utilities\u002Fskills\u002Fexample-skill\u002FSKILL.md",[112],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},[85,84,87,104,105,114,106,115,86],"never","but",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":44},"01M6CYJ78NG35A6BGVDG3DTDV8","pr-sdlc","Creates or updates GitHub pull requests with auto-generated 8-section descriptions.","https:\u002F\u002Fgithub.com\u002Frnagrodzki\u002Fsdlc-marketplace\u002Fblob\u002Fmain\u002Ftests\u002Fpromptfoo\u002Ffixtures-fs\u002Fhealthy-marketplace\u002Fplugins\u002Fsdlc-utilities\u002Fskills\u002Fpr-sdlc\u002FSKILL.md",[],[123,26,34,32,124,125,42,126],"pr sdlc","github","pull requests","generated",{"skillNo":128,"name":76,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":44},"01M6CYJ5W0AYJTBNDN0W4K6AJZ","Fixture skill for validate-cost-tiers drift tests.","https:\u002F\u002Fgithub.com\u002Frnagrodzki\u002Fsdlc-marketplace\u002Fblob\u002Fmain\u002Ftests\u002Fpromptfoo\u002Ffixtures-fs\u002Fcost-tiers-drift\u002Fskills\u002Fexample-skill\u002FSKILL.md",[132],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},[84,85,134,135,136,137,86],"validate","cost","fixture skill","drift"]