[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X0NV5ZP3T8RPKRYGGJ613G":3,"skill-same:01M6X0NV5ZP3T8RPKRYGGJ613G":71},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6X0NV5ZP3T8RPKRYGGJ613G","XMC Iterative Reflection",null,"Audits active session trajectory, thought history, and PR review comments to identify friction points, rule gaps, missing helper tools, and token inefficiencies. Use when requested by the user, after major implementations, or following PR review comment resolutions.","google\u002Fxmc","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M6X0MD62T1HTQNBX4VJ5AXWK",8,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fxmc\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fxmc_iterative_reflection\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"reflection","active","when","gaps","comments","helper","rule","trajectory","missing","token","review","friction","use","session","history","Tools","pr","pr review","pr review comments","2026-11-10 10:12:30",false,"---\nname: XMC Iterative Reflection\ndescription: Audits active session trajectory, thought history, and PR review comments to identify friction points, rule gaps, missing helper tools, and token inefficiencies. Use when requested by the user, after major implementations, or following PR review comment resolutions.\n---\n\n# Iterative Reflection & Meta-Learning Workflow\n\nThis skill provides a systematic retrospective workflow to evaluate an agent's recent thought history, tool execution trajectory, and PR review comments. It identifies friction, inefficiencies, rule gaps, and missing scripts, and formulates non-destructive, high-ROI improvement proposals.\n\n```mermaid\ngraph TD\n    A[Trigger Event] -->|Major Implementation \u002F PR Comment Resolution \u002F User Prompt| B[1. Inspect Trajectory Log & Review Comments]\n    A -->|Minor Typo \u002F Routine Zero-Rule Fix| Stop[Do NOT Trigger Reflection]\n    B --> C[2. Perform 4-Pillar Trajectory Audit]\n    C --> D[3. Apply Pragmatism & Anti-Hallucination Filter]\n    D -->|Smooth Trajectory \u002F One-off Friction| F[Report: No Action Needed]\n    D -->|Recurrent Friction Found| R[4. Root-Cause Routing: Select Control Rung]\n    R -->|Rungs 1, 3, 4: Stronger Control| E[Formulate High-ROI Proposals & Synthesize Scenario]\n    R -->|Rung 2 or 5: Control Needs a Boundary| V[5. Evidence-Based Boundary Derivation]\n    R -->|Rungs 6-7: Annotate \u002F Discard| F\n    V -->|Positive Set >= 2 Outside Incident, Negative Set Clear| E\n    V -->|Fewer Than 2 Positives Outside Incident| F\n    V -->|Contradictory Evidence| Esc[Escalate Question to User]\n    E & F & Esc --> G[6. Present Review Report & Await Approval]\n    G -->|Approved| H[7. Benchmark via \u002FXMC Trajectory Comparison & Open Draft PR]\n    G -->|Rejected \u002F No Action| End[Workflow Complete]\n    H --> End\n```\n\n> [!IMPORTANT]\n> **Safety & Pragmatism Guardrails**:\n> 1. **Do NOT Hallucinate Issues**: A valid and expected outcome of reflection is **\"No optimizations recommended\"**. Do not invent artificial problems for smooth or one-off tasks.\n> 2. **Proposals Before Edits**: Never apply file modifications, rule updates, or script additions automatically. Always present proposals to the user for explicit review first.\n\n---\n\n## 1. Trigger Criteria\n\nRun this skill when one of the following conditions is met:\n- **Explicit User Prompt**: The user asks for a retrospective, prompt audit, or performance reflection.\n- **PR Review Comment Resolution**: Resolving PR review comments (from human reviewers or automated review bots) via [XMC Address PR Comment](..\u002Fxmc_address_pr_comment\u002FSKILL.md), diagnosing why the initial submission lacked this quality and codifying missing rules or validation tooling.\n- **Major Task Completion**: Completion of a complex, multi-step feature or architectural refactor.\n- **High PR Comment Volume**: Resolving a Pull Request with high review comment volume (>3-5 comments or multiple review iterations), indicating friction or missing rule clarity.\n\n> [!CAUTION]\n> **Do NOT Trigger For**: Routine minor edits or trivial typo fixes where no underlying guideline or structural invariant was violated. Avoid over-eager reflection that adds token bloat for trivial tasks.\n\n---\n\n## 2. 4-Pillar Trajectory Audit\n\nEvaluate session logs (`transcript.jsonl`) across four key dimensions. These pillars **detect\nfriction only** — they do not determine the fix. Every surviving finding is assigned a destination\nin [Section 4: Root-Cause Routing](#4-root-cause-routing).\n\n### Missing Transcript Fallback Protocol\nIf `transcript.jsonl` for a conversation ID is unindexed or missing from local disk:\n1. **Audit Git History**: Run `git log --all --grep=\"\u003CCONV_ID>\" --stat -p` to inspect committed changes, review comments, and PR metadata.\n2. **Audit Workspace Worktrees & Reflog**: Inspect active agent worktree locations (`git worktree list`) and check `git reflog --all`.\n\n### Pillar 1: Tooling & Automation Gaps\n- **Signal**: Did the agent write complex shell logic, custom python one-liners, or manual regex filtering directly inside commands or chat responses?\n\n### Pillar 2: Rule & Guideline Gaps\n- **Signal**: Did review comments or agent trajectory show wrong assumptions, path wandering, or style guideline violations?\n- **PR Review Comment Tracing**: When triggered following PR comment resolutions, trace each comment back to the missing guideline, convention, or structural invariant. Diagnose why the initial implementation was not created with higher quality.\n\n### Pillar 3: Skill & Workflow Gaps\n- **Signal**: Was the overall task a recurring engineering playbook that lacked step-by-step guidance?\n\n### Pillar 4: Token & Subagent Efficiency\n- **Signal**: Did the agent read massive files unnecessarily, dump raw logs into prompt memory, or fail to delegate heavy search tasks to worker subagents?\n- **Action**: Recommend subagent delegation (e.g., `research-google` or `self`) or tool usage adjustments. This pillar is advisory by nature and does not pass through the control ladder.\n\n---\n\n## 3. Pragmatism & Anti-Hallucination Filter\n\nBefore adding any item to the proposed enhancements list, pass it through these checks:\n\n1. **Recurrence Check**: Is this friction likely to happen again in future tasks, or was it a unique, one-off edge case? (If one-off, omit it).\n2. **ROI Check**: Will the proposed rule\u002Ftool save more agent turns and token overhead than the cost of maintaining it? (If low ROI, omit it).\n3. **Zero-Friction Result**: If trajectory was smooth or friction was a one-off case, allow a pragmatic \"No Action Needed\" outcome.\n\n---\n\n## 4. Root-Cause Routing\n\nEach finding that survives the pragmatism filter MUST be assigned a destination before any fix is\ndrafted. First trace the causal chain across **both** definition and consumption sites, then apply\nthe control ladder defined in\n[Rule Authoring Standards](..\u002F..\u002Frules\u002Frule_authoring_standards.md#1-root-cause-routing-the-control-ladder):\n\n| Rung | Control | Destination |\n| :--- | :--- | :--- |\n| 1 | Eliminate | Shared API, SDK, or type-definition fix for all callers (separate PR) |\n| 2 | Automate | Lint rule or CI gate |\n| 3 | Tool | Helper script in `tools\u002F` |\n| 4 | Route | [`AGENTS.md`](..\u002F..\u002FAGENTS.md) routing matrices or rule relocation |\n| 5 | Document | New prose rule or skill |\n| 6 | Annotate | Scoped suppression with a stated reason |\n| 7 | Discard | No change |\n\n> [!IMPORTANT]\n> Apply the [Lint-First Test](..\u002F..\u002Frules\u002Frule_authoring_standards.md#3-rung-2-the-lint-first-test):\n> if the finding is a mechanically checkable invariant, it MUST become a lint rule rather than prose.\n> Fixing one call site in the active PR is ordinary review work, not rung 1 — it does not excuse\n> skipping the rung-2 gate that stops the next caller from repeating the pattern. Selecting rung 5\n> requires recording why rungs 1–4 do not apply.\n\nFindings originating from an automated review bot must pass the two-step\n[false-positive check](..\u002F..\u002Frules\u002Frule_authoring_standards.md#non-ladder-branch-external-tooling-false-positives):\nconfirm the claim is false, **and** trace why the tool was misled. If a shared surface or missing\ntypecheck\u002Flint gate under our control made the code ambiguous to static analysis, that ambiguity is a\nrung 1 or rung 2 finding in its own right; only when the chain terminates outside our control does it\ndiscard, and a bot's misunderstanding is never grounds for a prose rule or an inline comment addressed\nto the bot.\n\n---\n\n## 5. Evidence-Based Boundary Derivation\n\nRuns for any finding whose control needs a boundary — a rung-2 lint predicate as much as a rung-5 prose\nrule. Its purpose is to decide how broadly the control should apply, using enumerated files rather than\nthe file that triggered the finding. Follow\n[Evidence-Based Boundary Derivation](..\u002F..\u002Frules\u002Frule_authoring_standards.md#5-evidence-based-boundary-derivation).\n\nDelegate the two search halves to worker subagents. Their contract is to **enumerate files**, not to\nargue about wording — a critic given only rule text cannot falsify it and will tend to agree.\n\n| Subagent | Task | Must return |\n| :--- | :--- | :--- |\n| **Generalizer** | Climb from the incident toward the broadest defensible scope. Use `code_search` to find files the candidate rule would govern. | The positive set: concrete paths, at least two outside the originating incident |\n| **Falsifier** | Hunt counterexamples where the broadened rule would give wrong or harmful advice. Also scan `.agents\u002Frules\u002F` for an existing bullet that already covers this ground. | The negative set: concrete paths, plus any duplicate or conflicting rule found |\n\nExecution notes:\n\n- **Batch once per session** across all surviving findings. Do not spawn a subagent pair per finding.\n- **Delegate only when the search is large enough to pay for itself.** If the candidate population is\n  small and bounded — a handful of scoped `grep`\u002F`find` passes — run the enumeration inline. The\n  requirement that binds regardless of who runs it is the complement-aware search: both directions\n  answered explicitly. Delegation is a context-budget tactic, not the control.\n- Both are **read-only research agents**; a light model is sufficient.\n- Require the generalizer to report what its search **excluded**, not only what it matched.\n  A one-sided confirmation search will clear the two-positive bar while leaving the predicate wrong.\n\n### Arbitration\n\nAs the parent agent, combine the sets and choose the **narrowest predicate covering the whole\npositive set and excluding the whole negative set**. Then apply these gates:\n\n- **Fewer than two independent positives** → the finding is not generalizable. Demote to rung 6 if a\n  governing control exists, otherwise rung 7.\n- **Contradictory evidence** → do NOT synthesize a rule. Present the contradiction to the user as an\n  explicit question and record the finding as blocked pending their decision.\n- **A duplicate or conflicting rule already exists** → this is a rung-4 routing problem or a\n  merge-first amendment, not a new rule.\n\n---\n\n## 6. Formulate Report & Await Approval\n\nStructure findings into a clean report:\n\n### ? Retrospective Summary\n- **Primary Task**: Short summary of what was implemented or reviewed.\n- **Trigger Reason**: Major Implementation \u002F High PR Comment Volume \u002F PR Comment Resolution \u002F User Request.\n- **Trajectory Health**: Smooth \u002F Minor Friction \u002F Significant Friction.\n- **Outcome**: Actionable Enhancements Proposed OR No Action Needed (Trajectory Optimal \u002F One-off).\n\n\n### ? Proposed Enhancements (If Applicable)\n\n| Rung | Component | Current Friction \u002F Review Feedback | Proposed Fix \u002F Enhancement | Why Not a Stronger Rung | Evidence | Impact |\n| :--- | :--- | :--- | :--- | :--- | :--- | :--- |\n| **2 Automate** | `pyproject.toml` | Reviewer caught a banned call pattern | Enable the corresponding lint code with a rationale comment | n\u002Fa — strongest applicable | 42 violations \u002F 3 ignore globs | Blocks the class at commit time |\n| **3 Tool** | `tools\u002F...` | Repetitive manual parsing | Create python script `tools\u002Fparse_x.py` | Procedure, not a checkable invariant | n\u002Fa | Saves 3-5 turns |\n| **5 Document** | `.agents\u002Frules\u002F...` | Reviewer caught a convention gap | Amend the existing bullet in `.agents\u002Frules\u002F...` | Not mechanically checkable; no API fix available | +4 positive \u002F −2 negative \u002F 0 undecided | Prevents PR feedback |\n\nTwo columns are mandatory for every rung-5 row: `Why Not a Stronger Rung`, and `Evidence` stating\nthe size of the positive and negative sets. A rung-5 row with fewer than two positives outside the\noriginating incident must not appear here — it belongs at rung 6 or 7.\n\nEnd by presenting the report in markdown with clickable file links and awaiting user feedback before taking any action.\n\n---\n\n## 7. Validation Handshake & Draft PR Creation\n\nWhen the user approves candidate rule, skill, or tooling enhancements:\n\n### Step 1: Hand the Evidence Sets to the Benchmark\nSection 5 has already produced the positive and negative sets; pass them through rather than\nre-synthesizing a single prompt from the incident. The benchmark derives three scenarios from them —\norigin, held-out transfer, and negative regression — per\n[Derive the Scenario Matrix](..\u002Fxmc_trajectory_comparison\u002FSKILL.md#phase-1b-derive-the-scenario-matrix).\nName the specific file chosen for each scenario, and state each scenario's pass predicate as a\nmechanical assertion **before** launching.\n\nA finding routed to a rung that needed no boundary has no evidence sets, and so benchmarks with the\norigin scenario alone. Say so explicitly rather than presenting a one-scenario result as if it were\nthe full matrix.\n\n### Step 2: Propose Trajectory Comparison Benchmark\nPropose running [XMC Trajectory Comparison](..\u002Fxmc_trajectory_comparison\u002FSKILL.md) to empirically validate the new rule before opening a remote PR:\n- **Three-scenario matrix** (when boundary derivation ran with a non-empty negative set):\n  > *\"Candidate rule drafted on branch `docs\u002Frules-update-...`. Before opening a Draft PR, would you like to run `\u002FXMC Trajectory Comparison` over three scenarios — origin `[file]`, held-out transfer `[file]`, negative regression `[file]` — drawn from the evidence sets above?\"*\n- **Two-scenario matrix** (when boundary derivation ran but the negative set was empty):\n  > *\"Candidate rule drafted on branch `docs\u002Frules-update-...`. Before opening a Draft PR, would you like to run `\u002FXMC Trajectory Comparison` over two scenarios — origin `[file]`, held-out transfer `[file]` (no negative regression files found) — drawn from the evidence sets above?\"*\n- **Origin scenario only** (when the control needed no boundary):\n  > *\"Candidate change drafted on branch `docs\u002Frules-update-...`. Before opening a Draft PR, would you like to run `\u002FXMC Trajectory Comparison` over the origin scenario `[file]` (no boundary needed)?\"*\n\n### Step 3: Dual Subagent Benchmark & Scorecard\n- If approved, invoke [XMC Trajectory Comparison](..\u002Fxmc_trajectory_comparison\u002FSKILL.md).\n- The benchmark runs a baseline\u002Fcandidate pair on the origin scenario plus candidate-only arms for\n  transfer and negative regression, compares trajectories via `tools\u002Fbenchmark\u002Fcompare_trajectories.py`,\n  and generates the benchmark artifact `\u002Ftmp\u002Fbenchmark_report_\u003Cbranch_name>.md`.\n\n### Step 4: Draft PR Creation with Auto-Embedded Benchmark\n1. **Isolated Subagent Workspace (Preferred)**:\n   - Launch a worker subagent with `Workspace: \"branch\"`.\n   - **Clean Head Checkout**: The subagent MUST start by fetching and creating its dedicated branch directly from clean `origin\u002Fmain` (e.g., `git fetch origin && git checkout -b docs\u002Frules-update-... origin\u002Fmain`). This ensures the reflection PR contains strictly rule\u002Ftooling enhancements and never mixes scope with the parent agent's active feature branch.\n   - Follow [XMC Create PR](..\u002Fxmc_create_pr\u002FSKILL.md): `xmc_create_pr` auto-detects `\u002Ftmp\u002Fbenchmark_report_\u003Cbranch_name>.md` and embeds the empirical A\u002FB benchmark scorecard into `pr_body.md` under `? Trajectory & Outcome Benchmark Results`.\n   - Obtain user confirmation and open a Draft PR (`gh pr create --draft`).\n   - The primary agent's active worktree remains 100% untouched and safe from branch switching conflicts.\n\n2. **Single-Workspace Fallback (Safeguard)**:\n   - If subagent workspace isolation is unavailable in the execution environment, **do NOT perform local Git branch manipulations, stashing, or multi-PR switches** in the active worktree.\n   - Present the proposed changes directly in the chat or artifact summary for user review to prevent workspace corruption.\n\n","# Iterative Reflection & Meta-Learning Workflow\n\nThis skill provides a systematic retrospective workflow to evaluate an agent's recent thought history, tool execution trajectory, and PR review comments. It identifies friction, inefficiencies, rule gaps, and missing scripts, and formulates non-destructive, high-ROI improvement proposals.\n\n```mermaid\ngraph TD\n    A[Trigger Event] -->|Major Implementation \u002F PR Comment Resolution \u002F User Prompt| B[1. Inspect Trajectory Log & Review Comments]\n    A -->|Minor Typo \u002F Routine Zero-Rule Fix| Stop[Do NOT Trigger Reflection]\n    B --> C[2. Perform 4-Pillar Trajectory Audit]\n    C --> D[3. Apply Pragmatism & Anti-Hallucination Filter]\n    D -->|Smooth Trajectory \u002F One-off Friction| F[Report: No Action Needed]\n    D -->|Recurrent Friction Found| R[4. Root-Cause Routing: Select Control Rung]\n    R -->|Rungs 1, 3, 4: Stronger Control| E[Formulate High-ROI Proposals & Synthesize Scenario]\n    R -->|Rung 2 or 5: Control Needs a Boundary| V[5. Evidence-Based Boundary Derivation]\n    R -->|Rungs 6-7: Annotate \u002F Discard| F\n    V -->|Positive Set >= 2 Outside Incident, Negative Set Clear| E\n    V -->|Fewer Than 2 Positives Outside Incident| F\n    V -->|Contradictory Evidence| Esc[Escalate Question to User]\n    E & F & Esc --> G[6. Present Review Report & Await Approval]\n    G -->|Approved| H[7. Benchmark via \u002FXMC Trajectory Comparison & Open Draft PR]\n    G -->|Rejected \u002F No Action| End[Workflow Complete]\n    H --> End\n```\n\n> [!IMPORTANT]\n> **Safety & Pragmatism Guardrails**:\n> 1. **Do NOT Hallucinate Issues**: A valid and expected outcome of reflection is **\"No optimizations recommended\"**. Do not invent artificial problems for smooth or one-off tasks.\n> 2. **Proposals Before Edits**: Never apply file modifications, rule updates, or script additions automatically. Always present proposals to the user for explicit review first.\n\n---\n\n## 1. Trigger Criteria\n\nRun this skill when one of the following conditions is met:\n- **Explicit User Prompt**: The user asks for a retrospective, prompt audit, or performance reflection.\n- **PR Review Comment Resolution**: Resolving PR review comments (from human reviewers or automated review bots) via [XMC Address PR Comment](..\u002Fxmc_address_pr_comment\u002FSKILL.md), diagnosing why the initial submission lacked this quality and codifying missing rules or validation tooling.\n- **Major Task Completion**: Completion of a complex, multi-step feature or architectural refactor.\n- **High PR Comment Volume**: Resolving a Pull Request with high review comment volume (>3-5 comments or multiple review iterations), indicating friction or missing rule clarity.\n\n> [!CAUTION]\n> **Do NOT Trigger For**: Routine minor edits or trivial typo fixes where no underlying guideline or structural invariant was violated. Avoid over-eager reflection that adds token bloat for trivial tasks.\n\n---\n\n## 2. 4-Pillar Trajectory Audit\n\nEvaluate session logs (`transcript.jsonl`) across four key dimensions. These pillars **detect\nfriction only** — they do not determine the fix. Every surviving finding is assigned a destination\nin [Section 4: Root-Cause Routing](#4-root-cause-routing).\n\n### Missing Transcript Fallback Protocol\nIf `transcript.jsonl` for a conversation ID is unindexed or missing from local disk:\n1. **Audit Git History**: Run `git log --all --grep=\"\u003CCONV_ID>\" --stat -p` to inspect committed changes, review comments, and PR metadata.\n2. **Audit Workspace Worktrees & Reflog**: Inspect active agent worktree locations (`git worktree list`) and check `git reflog --all`.\n\n### Pillar 1: Tooling & Automation Gaps\n- **Signal**: Did the agent write complex shell logic, custom python one-liners, or manual regex filtering directly inside commands or chat responses?\n\n### Pillar 2: Rule & Guideline Gaps\n- **Signal**: Did review comments or agent trajectory show wrong assumptions, path wandering, or style guideline violations?\n- **PR Review Comment Tracing**: When triggered following PR comment resolutions, trace each comment back to the missing guideline, convention, or structural invariant. Diagnose why the initial implementation was not created with higher quality.\n\n### Pillar 3: Skill & Workflow Gaps\n- **Signal**: Was the overall task a recurring engineering playbook that lacked step-by-step guidance?\n\n### Pillar 4: Token & Subagent Efficiency\n- **Signal**: Did the agent read massive files unnecessarily, dump raw logs into prompt memory, or fail to delegate heavy search tasks to worker subagents?\n- **Action**: Recommend subagent delegation (e.g., `research-google` or `self`) or tool usage adjustments. This pillar is advisory by nature and does not pass through the control ladder.\n\n---\n\n## 3. Pragmatism & Anti-Hallucination Filter\n\nBefore adding any item to the proposed enhancements list, pass it through these checks:\n\n1. **Recurrence Check**: Is this friction likely to happen again in future tasks, or was it a unique, one-off edge case? (If one-off, omit it).\n2. **ROI Check**: Will the proposed rule\u002Ftool save more agent turns and token overhead than the cost of maintaining it? (If low ROI, omit it).\n3. **Zero-Friction Result**: If trajectory was smooth or friction was a one-off case, allow a pragmatic \"No Action Needed\" outcome.\n\n---\n\n## 4. Root-Cause Routing\n\nEach finding that survives the pragmatism filter MUST be assigned a destination before any fix is\ndrafted. First trace the causal chain across **both** definition and consumption sites, then apply\nthe control ladder defined in\n[Rule Authoring Standards](..\u002F..\u002Frules\u002Frule_authoring_standards.md#1-root-cause-routing-the-control-ladder):\n\n| Rung | Control | Destination |\n| :--- | :--- | :--- |\n| 1 | Eliminate | Shared API, SDK, or type-definition fix for all callers (separate PR) |\n| 2 | Automate | Lint rule or CI gate |\n| 3 | Tool | Helper script in `tools\u002F` |\n| 4 | Route | [`AGENTS.md`](..\u002F..\u002FAGENTS.md) routing matrices or rule relocation |\n| 5 | Document | New prose rule or skill |\n| 6 | Annotate | Scoped suppression with a stated reason |\n| 7 | Discard | No change |\n\n> [!IMPORTANT]\n> Apply the [Lint-First Test](..\u002F..\u002Frules\u002Frule_authoring_standards.md#3-rung-2-the-lint-first-test):\n> if the finding is a mechanically checkable invariant, it MUST become a lint rule rather than prose.\n> Fixing one call site in the active PR is ordinary review work, not rung 1 — it does not excuse\n> skipping the rung-2 gate that stops the next caller from repeating the pattern. Selecting rung 5\n> requires recording why rungs 1–4 do not apply.\n\nFindings originating from an automated review bot must pass the two-step\n[false-positive check](..\u002F..\u002Frules\u002Frule_authoring_standards.md#non-ladder-branch-external-tooling-false-positives):\nconfirm the claim is false, **and** trace why the tool was misled. If a shared surface or missing\ntypecheck\u002Flint gate under our control made the code ambiguous to static analysis, that ambiguity is a\nrung 1 or rung 2 finding in its own right; only when the chain terminates outside our control does it\ndiscard, and a bot's misunderstanding is never grounds for a prose rule or an inline comment addressed\nto the bot.\n\n---\n\n## 5. Evidence-Based Boundary Derivation\n\nRuns for any finding whose control needs a boundary — a rung-2 lint predicate as much as a rung-5 prose\nrule. Its purpose is to decide how broadly the control should apply, using enumerated files rather than\nthe file that triggered the finding. Follow\n[Evidence-Based Boundary Derivation](..\u002F..\u002Frules\u002Frule_authoring_standards.md#5-evidence-based-boundary-derivation).\n\nDelegate the two search halves to worker subagents. Their contract is to **enumerate files**, not to\nargue about wording — a critic given only rule text cannot falsify it and will tend to agree.\n\n| Subagent | Task | Must return |\n| :--- | :--- | :--- |\n| **Generalizer** | Climb from the incident toward the broadest defensible scope. Use `code_search` to find files the candidate rule would govern. | The positive set: concrete paths, at least two outside the originating incident |\n| **Falsifier** | Hunt counterexamples where the broadened rule would give wrong or harmful advice. Also scan `.agents\u002Frules\u002F` for an existing bullet that already covers this ground. | The negative set: concrete paths, plus any duplicate or conflicting rule found |\n\nExecution notes:\n\n- **Batch once per session** across all surviving findings. Do not spawn a subagent pair per finding.\n- **Delegate only when the search is large enough to pay for itself.** If the candidate population is\n  small and bounded — a handful of scoped `grep`\u002F`find` passes — run the enumeration inline. The\n  requirement that binds regardless of who runs it is the complement-aware search: both directions\n  answered explicitly. Delegation is a context-budget tactic, not the control.\n- Both are **read-only research agents**; a light model is sufficient.\n- Require the generalizer to report what its search **excluded**, not only what it matched.\n  A one-sided confirmation search will clear the two-positive bar while leaving the predicate wrong.\n\n### Arbitration\n\nAs the parent agent, combine the sets and choose the **narrowest predicate covering the whole\npositive set and excluding the whole negative set**. Then apply these gates:\n\n- **Fewer than two independent positives** → the finding is not generalizable. Demote to rung 6 if a\n  governing control exists, otherwise rung 7.\n- **Contradictory evidence** → do NOT synthesize a rule. Present the contradiction to the user as an\n  explicit question and record the finding as blocked pending their decision.\n- **A duplicate or conflicting rule already exists** → this is a rung-4 routing problem or a\n  merge-first amendment, not a new rule.\n\n---\n\n## 6. Formulate Report & Await Approval\n\nStructure findings into a clean report:\n\n### ? Retrospective Summary\n- **Primary Task**: Short summary of what was implemented or reviewed.\n- **Trigger Reason**: Major Implementation \u002F High PR Comment Volume \u002F PR Comment Resolution \u002F User Request.\n- **Trajectory Health**: Smooth \u002F Minor Friction \u002F Significant Friction.\n- **Outcome**: Actionable Enhancements Proposed OR No Action Needed (Trajectory Optimal \u002F One-off).\n\n\n### ? Proposed Enhancements (If Applicable)\n\n| Rung | Component | Current Friction \u002F Review Feedback | Proposed Fix \u002F Enhancement | Why Not a Stronger Rung | Evidence | Impact |\n| :--- | :--- | :--- | :--- | :--- | :--- | :--- |\n| **2 Automate** | `pyproject.toml` | Reviewer caught a banned call pattern | Enable the corresponding lint code with a rationale comment | n\u002Fa — strongest applicable | 42 violations \u002F 3 ignore globs | Blocks the class at commit time |\n| **3 Tool** | `tools\u002F...` | Repetitive manual parsing | Create python script `tools\u002Fparse_x.py` | Procedure, not a checkable invariant | n\u002Fa | Saves 3-5 turns |\n| **5 Document** | `.agents\u002Frules\u002F...` | Reviewer caught a convention gap | Amend the existing bullet in `.agents\u002Frules\u002F...` | Not mechanically checkable; no API fix available | +4 positive \u002F −2 negative \u002F 0 undecided | Prevents PR feedback |\n\nTwo columns are mandatory for every rung-5 row: `Why Not a Stronger Rung`, and `Evidence` stating\nthe size of the positive and negative sets. A rung-5 row with fewer than two positives outside the\noriginating incident must not appear here — it belongs at rung 6 or 7.\n\nEnd by presenting the report in markdown with clickable file links and awaiting user feedback before taking any action.\n\n---\n\n## 7. Validation Handshake & Draft PR Creation\n\nWhen the user approves candidate rule, skill, or tooling enhancements:\n\n### Step 1: Hand the Evidence Sets to the Benchmark\nSection 5 has already produced the positive and negative sets; pass them through rather than\nre-synthesizing a single prompt from the incident. The benchmark derives three scenarios from them —\norigin, held-out transfer, and negative regression — per\n[Derive the Scenario Matrix](..\u002Fxmc_trajectory_comparison\u002FSKILL.md#phase-1b-derive-the-scenario-matrix).\nName the specific file chosen for each scenario, and state each scenario's pass predicate as a\nmechanical assertion **before** launching.\n\nA finding routed to a rung that needed no boundary has no evidence sets, and so benchmarks with the\norigin scenario alone. Say so explicitly rather than presenting a one-scenario result as if it were\nthe full matrix.\n\n### Step 2: Propose Trajectory Comparison Benchmark\nPropose running [XMC Trajectory Comparison](..\u002Fxmc_trajectory_comparison\u002FSKILL.md) to empirically validate the new rule before opening a remote PR:\n- **Three-scenario matrix** (when boundary derivation ran with a non-empty negative set):\n  > *\"Candidate rule drafted on branch `docs\u002Frules-update-...`. Before opening a Draft PR, would you like to run `\u002FXMC Trajectory Comparison` over three scenarios — origin `[file]`, held-out transfer `[file]`, negative regression `[file]` — drawn from the evidence sets above?\"*\n- **Two-scenario matrix** (when boundary derivation ran but the negative set was empty):\n  > *\"Candidate rule drafted on branch `docs\u002Frules-update-...`. Before opening a Draft PR, would you like to run `\u002FXMC Trajectory Comparison` over two scenarios — origin `[file]`, held-out transfer `[file]` (no negative regression files found) — drawn from the evidence sets above?\"*\n- **Origin scenario only** (when the control needed no boundary):\n  > *\"Candidate change drafted on branch `docs\u002Frules-update-...`. Before opening a Draft PR, would you like to run `\u002FXMC Trajectory Comparison` over the origin scenario `[file]` (no boundary needed)?\"*\n\n### Step 3: Dual Subagent Benchmark & Scorecard\n- If approved, invoke [XMC Trajectory Comparison](..\u002Fxmc_trajectory_comparison\u002FSKILL.md).\n- The benchmark runs a baseline\u002Fcandidate pair on the origin scenario plus candidate-only arms for\n  transfer and negative regression, compares trajectories via `tools\u002Fbenchmark\u002Fcompare_trajectories.py`,\n  and generates the benchmark artifact `\u002Ftmp\u002Fbenchmark_report_\u003Cbranch_name>.md`.\n\n### Step 4: Draft PR Creation with Auto-Embedded Benchmark\n1. **Isolated Subagent Workspace (Preferred)**:\n   - Launch a worker subagent with `Workspace: \"branch\"`.\n   - **Clean Head Checkout**: The subagent MUST start by fetching and creating its dedicated branch directly from clean `origin\u002Fmain` (e.g., `git fetch origin && git checkout -b docs\u002Frules-update-... origin\u002Fmain`). This ensures the reflection PR contains strictly rule\u002Ftooling enhancements and never mixes scope with the parent agent's active feature branch.\n   - Follow [XMC Create PR](..\u002Fxmc_create_pr\u002FSKILL.md): `xmc_create_pr` auto-detects `\u002Ftmp\u002Fbenchmark_report_\u003Cbranch_name>.md` and embeds the empirical A\u002FB benchmark scorecard into `pr_body.md` under `? Trajectory & Outcome Benchmark Results`.\n   - Obtain user confirmation and open a Draft PR (`gh pr create --draft`).\n   - The primary agent's active worktree remains 100% untouched and safe from branch switching conflicts.\n\n2. **Single-Workspace Fallback (Safeguard)**:\n   - If subagent workspace isolation is unavailable in the execution environment, **do NOT perform local Git branch manipulations, stashing, or multi-PR switches** in the active worktree.\n   - Present the proposed changes directly in the chat or artifact summary for user review to prevent workspace corruption.\n\n",{"name":5,"description":7},"main","b1030912467228f082e7c927bc210d9d59e00fce",".agents\u002Fskills\u002Fxmc_iterative_reflection",0,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fxmc","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-14 00:40:34",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add google\u002Fxmc --skill \"XMC Iterative Reflection\"",{"tool":63,"command":64},"bunx","bunx skills add google\u002Fxmc --skill \"XMC Iterative Reflection\"",{"tool":66,"command":67},"pnpm","pnpm dlx skills add google\u002Fxmc --skill \"XMC Iterative Reflection\"","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fxmc\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fxmc_iterative_reflection\u002FSKILL.md",true,[],[72,91,112,136,160,183],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":43},"01M6X0PXHKB5KRZ6BESP7J4A3H","XMC Upgrade Environment","Upgrades an existing XManager on Cloud (XMC) environment on GKE to the latest current branch state using the deployment configuration YAML.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fxmc\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fxmc_upgrade\u002FSKILL.md",[],[79,74,80,81,82,83,84,85,86,87,88,89,90],"environment","upgrade","branch","deployment","upgrades","Existing","state","gke","yaml","latest","cloud","configuration",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":98,"publishedAt":43},"01M6X0PQ36XYVZW78KRBR8MT9E","XMC Trajectory Comparison","Validates proposed skill or rule changes by executing concurrent A\u002FB benchmark subagents on clean baseline vs candidate worktrees, comparing trajectories, and tearing down test resources.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fxmc\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fxmc_trajectory_comparison\u002FSKILL.md",[97],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[93,99,31,100,101,102,103,104,105,106,107,108,109,110,30,111],"comparison","resources","down","clean","trajectories","candidate","test","changes","worktrees","baseline","benchmark","clean baseline","subagents",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":119,"publishedAt":43},"01M6X0PFP96RZXZNJ9V4T2ZJK5","XMC Review PR","Interactive multi-agent PR review workflow enforcing code rules, open direction discussions, explicit confirmation gates, inline comment deduplication, and follow-up re-review verification.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fxmc\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fxmc_review_pr\u002FSKILL.md",[118],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[114,34,40,120,121,122,123,124,125,126,127,128,129,130,131,132,41,133,134,135],"review pr","direction","re","up","open","confirmation","deduplication","workflow","code","verification","inline","follow-up","multi-agent","Rules","interactive","gates",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":145,"publishedAt":43},"01M6X0P8K827HRQFZS32Y1KB2N","XMC Release","Orchestrates an end-to-end XMC release workflow — deploying the latest main to nightly, running and verifying e2e tests, capturing visual snapshot galleries, generating and iterating on structured release notes with the user, and publishing the release. Use when preparing, orchestrating, or publishing a formal XMC release from main.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fxmc\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fxmc_release\u002FSKILL.md",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[138,146,147,148,149,150,48,151,152,36,26,127,153,154,155,156,88,157,158,159],"release","running","end","tests","publishing","e2e","release notes","visual","with","notes","e2e tests","snapshot","user","structured",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":43},"01M6X0P20VKAAEP4R43HJQ9957","XMC PR Split Verification","Analyzes pull request diffs exceeding size thresholds (400 prod \u002F 1000 total \u002F 1000 docs) to enforce Single Responsibility Principle (SRP), evaluate vertical slice splitting feasibility, eliminate dead code, and plan gh-stack PR stacks.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fxmc\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fxmc_pr_split_verification\u002FSKILL.md",[],[40,162,167,129,168,169,170,171,172,173,174,128,175,176,177,178,179,180,181,182],"split","pull","thresholds","slice","enforce","diffs","single","gh","vertical slice","stack","plan","size","evaluate","pull request","request","dead code",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":43},"01M6X0NNRV5MK72RNAQZ8EHPMD","XMC Generate Release Notes","Generates structured, intelligent release notes segmented into out-of-the-box user-facing changes, behind-the-flag preview features, and operational\u002Fdev progress.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fxmc\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fxmc_generate_release_notes\u002FSKILL.md",[],[185,152,155,190,146,191,192,106,193,194,195,158,159],"generate","dev","preview","progress","features","box"]