[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BBW6P4PMXJ97KWF86MGA1":3,"skill-same:01M69BBW6P4PMXJ97KWF86MGA1":65},{"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":28,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":46,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M69BBW6P4PMXJ97KWF86MGA1","code-review",null,"Perform a multi-perspective code review of rego-cpp changes. Use when: reviewing a release, auditing a branch diff, evaluating a PR, or performing a pre-merge code review. Launches four parallel constructive review subagents (Security, Performance, Usability, Conservative), synthesises findings, then runs a sequential adversarial gap-analysis pass. Verifies key findings, produces a unified report with severity-ranked findings and actionable remediation recommendations.","microsoft\u002Frego-cpp","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BBSWXJ1R932580DT3PX9Z",48,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frego-cpp\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcode-review\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35],"code review","review","security","performance","merge","pr","cpp","2026-11-10 10:12:30",false,"---\nname: code-review\ndescription: 'Perform a multi-perspective code review of rego-cpp changes. Use when: reviewing a release, auditing a branch diff, evaluating a PR, or performing a pre-merge code review. Launches four parallel constructive review subagents (Security, Performance, Usability, Conservative), synthesises findings, then runs a sequential adversarial gap-analysis pass. Verifies key findings, produces a unified report with severity-ranked findings and actionable remediation recommendations.'\n---\n\n# Multi-Perspective Code Review\n\nPerform a structured code review by examining changes from four independent\nconstructive perspectives, synthesising their findings, then running an\nadversarial gap-analysis pass to catch what the constructive reviewers missed.\nCross-check findings against source code and produce a unified report with\nactionable recommendations.\n\n## When to Use\n\n- Before tagging a release\n- Reviewing a large branch diff or PR\n- Auditing a new subsystem (crypto, parsing, VM changes)\n- When a single-perspective review would miss cross-cutting concerns\n\n## Background\n\nA single reviewer tends toward their own bias — a security expert over-flags\nperformance patterns, a performance expert under-flags input validation. This\nskill runs four parallel constructive reviews, synthesises their findings,\nthen passes the result to an adversarial red-team reviewer that focuses on\ngaps the constructive reviewers missed. This sequential adversarial step\nproduces higher-quality findings than running all five in parallel, because\nthe adversary knows what was already found and can focus on blind spots.\n\n## Perspectives\n\n### Constructive Reviewers (parallel)\n\n| Perspective | Lens | Agent |\n|-------------|------|-------|\n| **Security** | Defence in depth, memory safety, bounded resources, error handling, adversarial inputs, C API boundaries, fuzz coverage | `security-lens` |\n| **Performance** | Allocation minimisation, cache-friendly access, pass count, hot-path awareness, algorithmic complexity | `speed-lens` |\n| **Usability** | Correctness, clarity, naming, WF precision, error message quality, one-concept-per-pass, API ergonomics | `usability-lens` |\n| **Conservative** | Smallest diff, backwards compatibility, API stability, reuse, no speculative generality, blast radius | `conservative-lens` |\n\n### Adversarial Reviewer (sequential, after synthesis)\n\n| Perspective | Lens | Agent |\n|-------------|------|-------|\n| **Adversarial** | Red-team attacks, hidden assumptions, untested edge cases, semantic divergence from OPA, consensus blind spots, breaking inputs. **Runs after constructive reviewers and receives their synthesised findings.** | `adversarial-lens` |\n\n## Checkpointing\n\nEach step writes a checkpoint file to `.copilot\u002Freview\u002F\u003Creview-slug>\u002F` so that a review can be resumed at any point if the session is interrupted or the user wants to re-run a step.\n\n### Checkpoint format\n\nEach checkpoint is a markdown file with YAML frontmatter, named `step-\u003CN>-\u003Cname>.md`:\n\n```markdown\n---\nreview_slug: \u003Creview-slug>\nstep: \u003CN>\nstep_name: \u003Cname>\ntimestamp: \u003CISO-8601>\nstatus: completed\n---\n\n\u003Cstep content in markdown>\n```\n\n### Checkpoint files by step\n\n| Step | File | Body contents |\n|------|------|---------------|\n| 1 | `step-1-diff.md` | Commit range, file list, subsystem grouping |\n| 2 | `step-2-reviews.md` | Each constructive reviewer's output under its own `## Heading` |\n| 3 | `step-3-synthesis.md` | Deduplicated, classified, severity-ranked findings |\n| 4 | `step-4-adversarial.md` | Adversarial gap-analysis findings |\n| 5 | `step-5-verification.md` | Verification results for CRITICAL\u002FHIGH findings |\n| 6 | `step-6-report.md` | Final unified report |\n| 7 | `step-7-calibration.md` | Test coverage calibration results |\n\n### Resuming from a checkpoint\n\nWhen the user says \"resume review\" or \"restart from step N\":\n\n1. Read the checkpoint directory `.copilot\u002Freview\u002F\u003Creview-slug>\u002F`\n2. Find the highest completed step checkpoint\n3. Load its data and continue from the next step\n4. If the user specifies a step number, discard checkpoints for that step and later, then re-run from that step using earlier checkpoint data as input\n\n### Review slug\n\nDerive the slug from the review target: e.g., `v1.3.0-to-v1.4.0` for a tag range, or `feature-branch-name` for a branch review. Store the slug in every checkpoint for cross-reference.\n\n### Using checkpoints as subagent context\n\nBecause checkpoint files are plain markdown, subagents can read them directly using file tools. Instead of inlining all prior results into a subagent prompt, **point the subagent at the checkpoint files**:\n\n- Tell the subagent the checkpoint directory path (`.copilot\u002Freview\u002F\u003Creview-slug>\u002F`).\n- Instruct it to read the specific checkpoint files it needs (e.g., \"Read `step-1-diff.md` for the file list and `step-3-synthesis.md` for existing findings\").\n- This keeps prompts short, avoids token duplication, and ensures subagents always see the full untruncated content.\n\n## Procedure\n\n### Step 1: Identify the Diff\n\nDetermine the commit range or branch diff to review.\n\n```bash\n# Example: changes since last release tag\ngit diff --stat v1.2.0..HEAD\n```\n\nGroup changed files by subsystem (parser, builtins, VM, C API, build system,\nwrappers) to assign review focus areas.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-1-diff.md` with the commit range, full file list, and subsystem grouping.\n\n### Step 2: Launch Four Constructive Review Subagents\n\nSpawn four Explore subagents **in parallel**, one per constructive perspective.\n**Do NOT include the adversarial reviewer in this step** — it runs later in\nStep 4.\n\nEach subagent receives:\n\n1. The same list of changed files and feature summary\n2. The perspective-specific review lens (from the table above)\n3. Specific files to examine based on the subsystem grouping\n4. Instructions to classify findings by severity and provide file\u002Fline references\n\n**Each subagent is independent — do not allow one reviewer's output to\ninfluence another.**\n\n**Prompt template for each subagent (Security, Performance, Usability, Conservative):**\n\n> You are performing a {PERSPECTIVE}-focused code review of rego-cpp.\n> The changes add: {FEATURE_SUMMARY}.\n>\n> Your review lens: **{LENS_DESCRIPTION}**\n>\n> THOROUGHNESS: thorough\n>\n> === PHASE 1 — INVENTORY ===\n> Before writing findings, list every function, rewrite rule, pass definition,\n> match arm, and significant code block in the changed files. Number them.\n> This ensures systematic coverage.\n>\n> === PHASE 2 — ASSESS ===\n> For each inventory item, check it against your focus areas. If no issues,\n> write \"No issues.\" Do not skip items.\n>\n> Please examine these files and report findings:\n> {FILE_LIST_WITH_SPECIFIC_QUESTIONS}\n>\n> For each finding, classify severity as {SEVERITY_SCALE} and provide the\n> file path and approximate line numbers. For bugs, provide a minimal test\n> case or execution trace. If you cannot construct one, mark as UNVERIFIED.\n> Return a structured report.\n\nSeverity scales per perspective:\n- **Security**: CRITICAL \u002F HIGH \u002F MEDIUM \u002F LOW \u002F INFO\n- **Performance**: HIGH \u002F MEDIUM \u002F LOW impact\n- **Usability**: CONCERN \u002F SUGGESTION \u002F POSITIVE\n- **Conservative**: BREAKING \u002F HIGH-RISK \u002F MEDIUM-RISK \u002F LOW-RISK \u002F OK\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-2-reviews.md` with each reviewer's output under its own heading.\n\n### Step 3: Synthesise Constructive Findings\n\nAfter all four constructive reviewers return, synthesise their outputs:\n\n1. **Deduplicate** — merge issues raised by multiple reviewers into a single\n   entry, noting which perspectives flagged it.\n2. **Classify** each unique issue by type: Security, Correctness, Performance,\n   Quality.\n3. **Assign unified severity** using this scale:\n\n| Unified Severity | Mapping |\n|-----------------|---------|\n| CRITICAL \u002F HIGH | Security CRITICAL\u002FHIGH, Performance HIGH, Usability CONCERN (correctness bug), Conservative BREAKING |\n| MEDIUM | Security MEDIUM, Performance MEDIUM, Usability CONCERN (non-correctness), Conservative HIGH-RISK |\n| LOW | Security LOW, Performance LOW, Usability SUGGESTION, Conservative MEDIUM-RISK |\n\n#### Convergence\nWhere two or more perspectives agree on the same finding. High convergence\nindicates high confidence.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-3-synthesis.md` with the deduplicated, classified findings.\n\n### Step 4: Adversarial Gap-Analysis Pass\n\nAfter synthesising the four constructive reviewers' findings, spawn a **fresh**\nadversarial subagent (`adversarial-lens`). Provide it with:\n- The full list of changed files and feature summary\n- The **complete synthesised findings from Step 3** so it knows what was\n  already found\n\n**Prompt template for the Adversarial subagent:**\n\n> You are a red-team adversary performing gap-analysis on a rego-cpp code\n> review. Four other reviewers (Security, Performance, Usability, Conservative)\n> have already reviewed the changes. Their findings are listed below under\n> EXISTING FINDINGS. Your job is to find what they MISSED.\n>\n> The changes add: {FEATURE_SUMMARY}.\n>\n> Do NOT re-report existing findings. Only report NEW issues. Focus on:\n> - Code sections in NO existing finding (overlooked)\n> - Issue categories not represented\n> - Cross-component interactions no single lens would catch\n> - Shared assumptions across the other reviewers that may be wrong\n> - Untested edge cases and semantic divergence from OPA\n> - Breaking inputs (provide concrete Rego policies \u002F JSON data)\n>\n> THOROUGHNESS: thorough\n>\n> Please examine these files:\n> {FILE_LIST_WITH_SPECIFIC_QUESTIONS}\n>\n> EXISTING FINDINGS:\n> {SYNTHESISED_FINDINGS_FROM_STEP_3}\n>\n> For each attack, classify confidence as HIGH (proven with a test case),\n> MEDIUM (likely based on code analysis), or LOW (theoretical). Provide\n> concrete adversarial inputs wherever possible. Return a structured attack\n> report.\n\nSeverity scale for Adversarial:\n- **HIGH**: Concrete breaking input or proven semantic divergence from OPA\n- **MEDIUM**: Likely failure based on code analysis, no concrete input yet\n- **LOW**: Theoretical concern, conditions for failure are speculative\n\nMerge the adversarial reviewer's new findings into the synthesised list using\nthe same unified severity scale, then proceed to verification.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-4-adversarial.md` with the adversarial findings merged into the full list.\n\n### Step 5: Verify Key Findings\n\nIdentify the highest-severity findings (CRITICAL \u002F HIGH) and **spot-check\nthem against source code**. Launch a verification subagent:\n\n> For each claim below, read the relevant code and report whether the claim\n> is CONFIRMED, PARTIALLY CONFIRMED, or REFUTED. Provide exact code evidence.\n> {LIST_OF_CLAIMS_TO_VERIFY}\n\nThis step prevents false positives from propagating into the final report.\nMark each issue as:\n- **Verified** — reproduced or confirmed by code inspection\n- **Likely** — strong evidence but not yet reproduced\n- **Unverified** — plausible but needs investigation\n\nDowngrade or remove issues that cannot be substantiated after reasonable\ninvestigation.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-5-verification.md` with the verification results.\n\n### Step 6: Produce the Report\n\nProduce a unified report with these sections:\n\n#### Findings by Severity\nA single table combining all verified findings. Each finding gets: number,\ndescription, originating perspective(s), verification status, file path and\nline references.\n\n#### Positive Highlights\nThings the code does well, called out by any perspective. This provides\nbalanced feedback and reinforces good patterns.\n\n#### Recommendations\nOrdered by priority. Split into:\n- **Before release**: correctness bugs, UB, security issues\n- **After release**: performance optimisation, tech debt, hardening\n\n#### Trade-offs\nWhere perspectives conflict (e.g., security wants more validation, performance\nwants less overhead), state the conflict and the recommended resolution.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-6-report.md` with the full unified report.\n\n### Step 7: Calibrate Against Existing Test Coverage\n\nBefore finalising recommendations, check whether existing test suites\n(OPA conformance tests, regocpp.yaml, fuzzer) already cover the flagged\nscenarios. The OPA test suite is comprehensive — findings about \"missing\ntest coverage\" must be verified against:\n\n```bash\n# List OPA test suites\nls build\u002Fopa\u002Fv1\u002Ftest\u002Fcases\u002Ftestdata\u002Fv1\u002F\n\n# Check specific suite coverage\ngrep 'note:' build\u002Fopa\u002Fv1\u002Ftest\u002Fcases\u002Ftestdata\u002Fv1\u002F{suite}\u002F*.yaml\n```\n\nDrop or downgrade recommendations that duplicate existing OPA coverage.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-7-calibration.md` with the calibration results and final adjusted recommendations.\n\n## Chunking Large Targets\n\nIf the code under review exceeds ~300 lines, split it into logical segments\n(by file, pass, or function group) and run Steps 2–5 independently on each\nsegment. After all segments are reviewed, merge and deduplicate findings\nacross segments before the final report.\n\nThis ensures every section receives full attention. Do not skip this for\nlarge targets — reviewer quality degrades significantly when a single prompt\nmust cover hundreds of lines.\n\n## Guardrails\n\n- Each reviewer subagent must be a fresh instance — no context contamination\n  between reviewers.\n- The adversarial reviewer runs AFTER the constructive reviewers, not in\n  parallel. It receives the synthesised findings to avoid duplicate work and\n  focus on gaps.\n- Do not skip the verification step for CRITICAL\u002FHIGH issues. Unverified\n  critical findings must be explicitly marked as such.\n- Prefer concrete code suggestions over vague recommendations.\n\n## Output Format\n\nThe final report should be a structured markdown document (presented in chat,\nnot saved to a file unless requested) with the sections described in Step 6.\n\n## Reference\n\n- [Example remediation plan from v1.3.0 review](.\u002Freferences\u002Fv1.3.0-remediation-plan.md) —\n  a concrete example of findings and the resulting fix plan.\n","# Multi-Perspective Code Review\n\nPerform a structured code review by examining changes from four independent\nconstructive perspectives, synthesising their findings, then running an\nadversarial gap-analysis pass to catch what the constructive reviewers missed.\nCross-check findings against source code and produce a unified report with\nactionable recommendations.\n\n## When to Use\n\n- Before tagging a release\n- Reviewing a large branch diff or PR\n- Auditing a new subsystem (crypto, parsing, VM changes)\n- When a single-perspective review would miss cross-cutting concerns\n\n## Background\n\nA single reviewer tends toward their own bias — a security expert over-flags\nperformance patterns, a performance expert under-flags input validation. This\nskill runs four parallel constructive reviews, synthesises their findings,\nthen passes the result to an adversarial red-team reviewer that focuses on\ngaps the constructive reviewers missed. This sequential adversarial step\nproduces higher-quality findings than running all five in parallel, because\nthe adversary knows what was already found and can focus on blind spots.\n\n## Perspectives\n\n### Constructive Reviewers (parallel)\n\n| Perspective | Lens | Agent |\n|-------------|------|-------|\n| **Security** | Defence in depth, memory safety, bounded resources, error handling, adversarial inputs, C API boundaries, fuzz coverage | `security-lens` |\n| **Performance** | Allocation minimisation, cache-friendly access, pass count, hot-path awareness, algorithmic complexity | `speed-lens` |\n| **Usability** | Correctness, clarity, naming, WF precision, error message quality, one-concept-per-pass, API ergonomics | `usability-lens` |\n| **Conservative** | Smallest diff, backwards compatibility, API stability, reuse, no speculative generality, blast radius | `conservative-lens` |\n\n### Adversarial Reviewer (sequential, after synthesis)\n\n| Perspective | Lens | Agent |\n|-------------|------|-------|\n| **Adversarial** | Red-team attacks, hidden assumptions, untested edge cases, semantic divergence from OPA, consensus blind spots, breaking inputs. **Runs after constructive reviewers and receives their synthesised findings.** | `adversarial-lens` |\n\n## Checkpointing\n\nEach step writes a checkpoint file to `.copilot\u002Freview\u002F\u003Creview-slug>\u002F` so that a review can be resumed at any point if the session is interrupted or the user wants to re-run a step.\n\n### Checkpoint format\n\nEach checkpoint is a markdown file with YAML frontmatter, named `step-\u003CN>-\u003Cname>.md`:\n\n```markdown\n---\nreview_slug: \u003Creview-slug>\nstep: \u003CN>\nstep_name: \u003Cname>\ntimestamp: \u003CISO-8601>\nstatus: completed\n---\n\n\u003Cstep content in markdown>\n```\n\n### Checkpoint files by step\n\n| Step | File | Body contents |\n|------|------|---------------|\n| 1 | `step-1-diff.md` | Commit range, file list, subsystem grouping |\n| 2 | `step-2-reviews.md` | Each constructive reviewer's output under its own `## Heading` |\n| 3 | `step-3-synthesis.md` | Deduplicated, classified, severity-ranked findings |\n| 4 | `step-4-adversarial.md` | Adversarial gap-analysis findings |\n| 5 | `step-5-verification.md` | Verification results for CRITICAL\u002FHIGH findings |\n| 6 | `step-6-report.md` | Final unified report |\n| 7 | `step-7-calibration.md` | Test coverage calibration results |\n\n### Resuming from a checkpoint\n\nWhen the user says \"resume review\" or \"restart from step N\":\n\n1. Read the checkpoint directory `.copilot\u002Freview\u002F\u003Creview-slug>\u002F`\n2. Find the highest completed step checkpoint\n3. Load its data and continue from the next step\n4. If the user specifies a step number, discard checkpoints for that step and later, then re-run from that step using earlier checkpoint data as input\n\n### Review slug\n\nDerive the slug from the review target: e.g., `v1.3.0-to-v1.4.0` for a tag range, or `feature-branch-name` for a branch review. Store the slug in every checkpoint for cross-reference.\n\n### Using checkpoints as subagent context\n\nBecause checkpoint files are plain markdown, subagents can read them directly using file tools. Instead of inlining all prior results into a subagent prompt, **point the subagent at the checkpoint files**:\n\n- Tell the subagent the checkpoint directory path (`.copilot\u002Freview\u002F\u003Creview-slug>\u002F`).\n- Instruct it to read the specific checkpoint files it needs (e.g., \"Read `step-1-diff.md` for the file list and `step-3-synthesis.md` for existing findings\").\n- This keeps prompts short, avoids token duplication, and ensures subagents always see the full untruncated content.\n\n## Procedure\n\n### Step 1: Identify the Diff\n\nDetermine the commit range or branch diff to review.\n\n```bash\n# Example: changes since last release tag\ngit diff --stat v1.2.0..HEAD\n```\n\nGroup changed files by subsystem (parser, builtins, VM, C API, build system,\nwrappers) to assign review focus areas.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-1-diff.md` with the commit range, full file list, and subsystem grouping.\n\n### Step 2: Launch Four Constructive Review Subagents\n\nSpawn four Explore subagents **in parallel**, one per constructive perspective.\n**Do NOT include the adversarial reviewer in this step** — it runs later in\nStep 4.\n\nEach subagent receives:\n\n1. The same list of changed files and feature summary\n2. The perspective-specific review lens (from the table above)\n3. Specific files to examine based on the subsystem grouping\n4. Instructions to classify findings by severity and provide file\u002Fline references\n\n**Each subagent is independent — do not allow one reviewer's output to\ninfluence another.**\n\n**Prompt template for each subagent (Security, Performance, Usability, Conservative):**\n\n> You are performing a {PERSPECTIVE}-focused code review of rego-cpp.\n> The changes add: {FEATURE_SUMMARY}.\n>\n> Your review lens: **{LENS_DESCRIPTION}**\n>\n> THOROUGHNESS: thorough\n>\n> === PHASE 1 — INVENTORY ===\n> Before writing findings, list every function, rewrite rule, pass definition,\n> match arm, and significant code block in the changed files. Number them.\n> This ensures systematic coverage.\n>\n> === PHASE 2 — ASSESS ===\n> For each inventory item, check it against your focus areas. If no issues,\n> write \"No issues.\" Do not skip items.\n>\n> Please examine these files and report findings:\n> {FILE_LIST_WITH_SPECIFIC_QUESTIONS}\n>\n> For each finding, classify severity as {SEVERITY_SCALE} and provide the\n> file path and approximate line numbers. For bugs, provide a minimal test\n> case or execution trace. If you cannot construct one, mark as UNVERIFIED.\n> Return a structured report.\n\nSeverity scales per perspective:\n- **Security**: CRITICAL \u002F HIGH \u002F MEDIUM \u002F LOW \u002F INFO\n- **Performance**: HIGH \u002F MEDIUM \u002F LOW impact\n- **Usability**: CONCERN \u002F SUGGESTION \u002F POSITIVE\n- **Conservative**: BREAKING \u002F HIGH-RISK \u002F MEDIUM-RISK \u002F LOW-RISK \u002F OK\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-2-reviews.md` with each reviewer's output under its own heading.\n\n### Step 3: Synthesise Constructive Findings\n\nAfter all four constructive reviewers return, synthesise their outputs:\n\n1. **Deduplicate** — merge issues raised by multiple reviewers into a single\n   entry, noting which perspectives flagged it.\n2. **Classify** each unique issue by type: Security, Correctness, Performance,\n   Quality.\n3. **Assign unified severity** using this scale:\n\n| Unified Severity | Mapping |\n|-----------------|---------|\n| CRITICAL \u002F HIGH | Security CRITICAL\u002FHIGH, Performance HIGH, Usability CONCERN (correctness bug), Conservative BREAKING |\n| MEDIUM | Security MEDIUM, Performance MEDIUM, Usability CONCERN (non-correctness), Conservative HIGH-RISK |\n| LOW | Security LOW, Performance LOW, Usability SUGGESTION, Conservative MEDIUM-RISK |\n\n#### Convergence\nWhere two or more perspectives agree on the same finding. High convergence\nindicates high confidence.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-3-synthesis.md` with the deduplicated, classified findings.\n\n### Step 4: Adversarial Gap-Analysis Pass\n\nAfter synthesising the four constructive reviewers' findings, spawn a **fresh**\nadversarial subagent (`adversarial-lens`). Provide it with:\n- The full list of changed files and feature summary\n- The **complete synthesised findings from Step 3** so it knows what was\n  already found\n\n**Prompt template for the Adversarial subagent:**\n\n> You are a red-team adversary performing gap-analysis on a rego-cpp code\n> review. Four other reviewers (Security, Performance, Usability, Conservative)\n> have already reviewed the changes. Their findings are listed below under\n> EXISTING FINDINGS. Your job is to find what they MISSED.\n>\n> The changes add: {FEATURE_SUMMARY}.\n>\n> Do NOT re-report existing findings. Only report NEW issues. Focus on:\n> - Code sections in NO existing finding (overlooked)\n> - Issue categories not represented\n> - Cross-component interactions no single lens would catch\n> - Shared assumptions across the other reviewers that may be wrong\n> - Untested edge cases and semantic divergence from OPA\n> - Breaking inputs (provide concrete Rego policies \u002F JSON data)\n>\n> THOROUGHNESS: thorough\n>\n> Please examine these files:\n> {FILE_LIST_WITH_SPECIFIC_QUESTIONS}\n>\n> EXISTING FINDINGS:\n> {SYNTHESISED_FINDINGS_FROM_STEP_3}\n>\n> For each attack, classify confidence as HIGH (proven with a test case),\n> MEDIUM (likely based on code analysis), or LOW (theoretical). Provide\n> concrete adversarial inputs wherever possible. Return a structured attack\n> report.\n\nSeverity scale for Adversarial:\n- **HIGH**: Concrete breaking input or proven semantic divergence from OPA\n- **MEDIUM**: Likely failure based on code analysis, no concrete input yet\n- **LOW**: Theoretical concern, conditions for failure are speculative\n\nMerge the adversarial reviewer's new findings into the synthesised list using\nthe same unified severity scale, then proceed to verification.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-4-adversarial.md` with the adversarial findings merged into the full list.\n\n### Step 5: Verify Key Findings\n\nIdentify the highest-severity findings (CRITICAL \u002F HIGH) and **spot-check\nthem against source code**. Launch a verification subagent:\n\n> For each claim below, read the relevant code and report whether the claim\n> is CONFIRMED, PARTIALLY CONFIRMED, or REFUTED. Provide exact code evidence.\n> {LIST_OF_CLAIMS_TO_VERIFY}\n\nThis step prevents false positives from propagating into the final report.\nMark each issue as:\n- **Verified** — reproduced or confirmed by code inspection\n- **Likely** — strong evidence but not yet reproduced\n- **Unverified** — plausible but needs investigation\n\nDowngrade or remove issues that cannot be substantiated after reasonable\ninvestigation.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-5-verification.md` with the verification results.\n\n### Step 6: Produce the Report\n\nProduce a unified report with these sections:\n\n#### Findings by Severity\nA single table combining all verified findings. Each finding gets: number,\ndescription, originating perspective(s), verification status, file path and\nline references.\n\n#### Positive Highlights\nThings the code does well, called out by any perspective. This provides\nbalanced feedback and reinforces good patterns.\n\n#### Recommendations\nOrdered by priority. Split into:\n- **Before release**: correctness bugs, UB, security issues\n- **After release**: performance optimisation, tech debt, hardening\n\n#### Trade-offs\nWhere perspectives conflict (e.g., security wants more validation, performance\nwants less overhead), state the conflict and the recommended resolution.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-6-report.md` with the full unified report.\n\n### Step 7: Calibrate Against Existing Test Coverage\n\nBefore finalising recommendations, check whether existing test suites\n(OPA conformance tests, regocpp.yaml, fuzzer) already cover the flagged\nscenarios. The OPA test suite is comprehensive — findings about \"missing\ntest coverage\" must be verified against:\n\n```bash\n# List OPA test suites\nls build\u002Fopa\u002Fv1\u002Ftest\u002Fcases\u002Ftestdata\u002Fv1\u002F\n\n# Check specific suite coverage\ngrep 'note:' build\u002Fopa\u002Fv1\u002Ftest\u002Fcases\u002Ftestdata\u002Fv1\u002F{suite}\u002F*.yaml\n```\n\nDrop or downgrade recommendations that duplicate existing OPA coverage.\n\n**Checkpoint**: Write `.copilot\u002Freview\u002F\u003Creview-slug>\u002Fstep-7-calibration.md` with the calibration results and final adjusted recommendations.\n\n## Chunking Large Targets\n\nIf the code under review exceeds ~300 lines, split it into logical segments\n(by file, pass, or function group) and run Steps 2–5 independently on each\nsegment. After all segments are reviewed, merge and deduplicate findings\nacross segments before the final report.\n\nThis ensures every section receives full attention. Do not skip this for\nlarge targets — reviewer quality degrades significantly when a single prompt\nmust cover hundreds of lines.\n\n## Guardrails\n\n- Each reviewer subagent must be a fresh instance — no context contamination\n  between reviewers.\n- The adversarial reviewer runs AFTER the constructive reviewers, not in\n  parallel. It receives the synthesised findings to avoid duplicate work and\n  focus on gaps.\n- Do not skip the verification step for CRITICAL\u002FHIGH issues. Unverified\n  critical findings must be explicitly marked as such.\n- Prefer concrete code suggestions over vague recommendations.\n\n## Output Format\n\nThe final report should be a structured markdown document (presented in chat,\nnot saved to a file unless requested) with the sections described in Step 6.\n\n## Reference\n\n- [Example remediation plan from v1.3.0 review](.\u002Freferences\u002Fv1.3.0-remediation-plan.md) —\n  a concrete example of findings and the resulting fix plan.\n",{"name":5,"description":7},"main","f424aab83f0181a770940c25ab030619cde99616",".github\u002Fskills\u002Fcode-review",20,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frego-cpp","https:\u002F\u002Fmicrosoft.github.io\u002Frego-cpp\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-10-16 11:55:01",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add microsoft\u002Frego-cpp --skill code-review",{"tool":57,"command":58},"bunx","bunx skills add microsoft\u002Frego-cpp --skill code-review",{"tool":60,"command":61},"pnpm","pnpm dlx skills add microsoft\u002Frego-cpp --skill code-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frego-cpp\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcode-review\u002FSKILL.md",true,[],[66,76,93,105,116,133],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":36},"01M69BCB9YED816F7ZZJBMKBB9","trieste-dev","Plan and implement Trieste-based compiler passes and AST transformations for rego-cpp. Use when: adding new compiler passes, modifying AST structure, implementing new Rego language features, debugging pass failures, working with well-formedness definitions, or performing any multi-step implementation that touches the Trieste pass pipeline. Includes the multi-planner approach for complex features.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frego-cpp\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftrieste-dev\u002FSKILL.md",[],[73,74,35,75],"trieste dev","implement","debugging",{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":85,"publishedAt":36},"01M69BC8MGSYVC8R7722K5G0BN","regocpp-builtins","Add, update, or remove OPA Rego built-in functions in rego-cpp. Use when: implementing a new builtin, replacing a placeholder with a real implementation, adding a new OPA builtin namespace, updating builtin declarations to match a new OPA version, removing deprecated builtins, or debugging builtin dispatch\u002Fregistration. Covers the full lifecycle: declaration, implementation, dispatch registration, CMake wiring, and OPA conformance testing.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frego-cpp\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fregocpp-builtins\u002FSKILL.md",[82],{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[86,87,88,89,35,75,90,91,92],"regocpp builtins","testing","placeholder","cmake","conformance testing","update","opa",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":100,"publishedAt":36},"01M69BC603T40X4P9M21KQ4AQV","rego-fuzzer","Pass the rego-cpp Trieste fuzzer for a given pass collection. Use when: verifying that compiler passes are robust to all valid WF inputs, debugging fuzzer failures, fixing generative testing regressions, or validating pass changes against random inputs. The fuzzer generates random ASTs from the Trieste well-formedness chain and checks that each pass handles all structurally valid inputs without crashing or producing malformed output.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frego-cpp\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Frego-fuzzer\u002FSKILL.md",[99],{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},[101,102,75,87,103,35,104],"fuzzer","rego fuzzer","run","valid",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":36},"01M69BC3B665PTKXB0C2EC5AMW","opa-compat-check","Check OPA Rego version compatibility for rego-cpp. Use when: updating OPA version, checking for new OPA releases, auditing rego-cpp compatibility, planning OPA upgrade work, reviewing OPA release notes for rego-cpp impact. Fetches OPA release notes, compares with current rego-cpp support, and produces an actionable compatibility report.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frego-cpp\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fopa-compat-check\u002FSKILL.md",[],[112,92,35,113,114,115],"opa compat check","release notes","notes","support",{"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":128,"publishedAt":36},"01M69BC13CH5R7DWNJW5HGDAHY","multi-perspective-planning","Run a multi-perspective planning process for non-trivial design decisions. Use when: the shape of a solution is uncertain, planning new language features, new passes, API changes, AST restructuring, or cross-cutting concerns. Spawns four competing sub-planners, synthesises with rebuttal resolution, and stress-tests via adversarial review. Supports checkpointing so planning can be restarted at any step.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frego-cpp\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fmulti-perspective-planning\u002FSKILL.md",[122,125],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":126,"categoryName":127,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[129,103,130,131,30,132],"multi perspective planning","adversarial review","api changes","design",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":36},"01M69BBYNK9HWTBDB91DTBMX98","finalize-pr","Finalize a rego-cpp PR for release. Use when: wrapping up a branch, preparing a release, cutting a version, or when instructed to finalize a PR. Confirms review\u002Fremediation is done, determines branch changes, bumps the version across the library and all wrappers, writes a CHANGELOG entry, updates documentation, runs the editor lens over new comments, and runs format\u002Fbuild\u002Ftest gates to give CI the best chance of passing.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Frego-cpp\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffinalize-pr\u002FSKILL.md",[],[34,140,30,35,141,142,143],"finalize pr","documentation","editor","test"]