---
name: panel-review
description: >-
  Use this skill when the code-review skill delegates an Atlas pull request to
  the panel, or when the user explicitly asks for a panel or multi-lens review.
  Run a cost-aware advisory panel over the relevant Atlas contract, Python CLI,
  skill/agent, and security/gitops surfaces. Publish inline findings plus one
  evidence-backed summary. Do not use it as the generic review entrypoint,
  implement the reviewed change, merge, or set formal review state.
license: Apache-2.0
---

# Atlas panel review

You are the orchestrator and sole public writer. Panelists and the synthesizer
never write to the PR.

## Hard rules

- **Single writer:** panelists and synthesizer return receipts only.
- **Inline then one summary:** publish every diff-backed finding as an inline
  comment, then exactly one Blocker/Recommended/Nits summary with expandable
  detail for every selected lens. Never post per-lens top-level comments.
- **Advisory only:** humans own formal review state and merging. Never apply
  merge-decision labels or implement the reviewed change.
- **Lazy load:** load only selected lens files. Do not send one panelist another
  lens body.
- **Honest topology:** prefer isolated children. When they are unavailable,
  disclose the sequential fallback and its reduced context isolation; never
  describe fallback receipts as independent child reviews.
- A review lens is not an Atlas compile `--path`/`--type` focus lens.

## Procedure

1. Gather the PR title, body, changed paths, and unified diff read-only.
2. Load `references/roster.md` and classify in the parent from paths and PR
   intent. Record selected lens ids and a reason for every skipped lens. This
   is not a model call. Select the minimum useful roster: normally one or two,
   never more than four.
3. Load `assets/panelist-receipt.schema.json` and probe whether isolated child
   reviewers are available.

   When available, start one isolated, low-effort child for each selected lens.
   Use the cheapest checklist-capable reviewer for `atlas-contract`. Use a full
   reviewer capable of cross-file reasoning for `python-cli`,
   `skill-agent-contract`, and `security-gitops`; these lenses reason across
   behavior or trust boundaries. Never use a planner/researcher class.

   When isolated children are unavailable, set the execution mode to
   `sequential fallback` and run one bounded lens pass at a time in roster
   order. Before each pass, re-read the compact brief, load only that lens file,
   and re-anchor on the original PR context. Do not consult findings from prior
   slots while analysing the current lens. Emit and validate its receipt before
   loading the next lens. Add `Sequential fallback: no child context isolation`
   to that receipt's limitations.

   In either mode, use this compact brief, the assigned lens file, the schema,
   and PR context. Permit read-only access to the current versions of changed
   files when omitted diff context must be resolved:

   ```text
   ROLE: <lens-id> reviewer. RESPOND JSON ONLY.
   CHECK: assigned rubric only. NO cross-lens findings. NO writes.
   TARGET: findings introduced by current PR only. Never report errors in a
   prior reviewer receipt, validation message, or panel process as PR findings.
   FACTS: do not infer absence from a partial diff; inspect the current changed
   file before claiming a required field, file, or test is missing.
   WEIGHTS: Blocker=demonstrated correctness/security/contract failure;
   Recommended=substantive follow-up; Nit=optional polish.
   RETURN: status, non-empty summary, coverage[1..3], findings[], limitations[].
   ```

4. Validate each receipt before fan-in: parse JSON; apply the panelist schema;
   require the assigned `lens_id`; require useful, concrete summary and
   coverage; fact-check each finding's evidence against the current file or
   diff; reject findings based on omitted diff context, outside the assigned
   lens, or about the review process rather than the PR; and verify any `path`
   plus `line` is a new-side diff location.
   Require `path` plus `line` when a changed line can carry the finding; omit
   them only for repository-level findings with no eligible changed line.
   Retry only a malformed slot once, providing its validation errors. If the
   retry fails, create a schema-valid `status: failed` receipt whose summary,
   coverage, and limitations explain that no review evidence was produced.
   Do not rerun valid slots.
5. After every selected slot has a valid receipt, collect up to five available
   deterministic checks relevant to the review (for example existing CI status
   or commands already run by the orchestrator). Record command/check name,
   outcome, and scope; do not run unrelated broad suites just to fill this list.
   Then load `assets/synthesizer-receipt.schema.json`. When isolated children
   are available, start one reviewer-class, low-effort synthesizer. Otherwise,
   re-anchor the orchestrator on the synthesizer brief and synthesize locally.
   In both modes, provide validated receipts plus that bounded validation
   evidence, never lens bodies:

   ```text
   ROLE: dissent-weighted panel synthesizer. RESPOND JSON ONLY.
   INPUT: validated receipts + deterministic checks only. NO new findings.
   Resolve a panelist limitation only when a supplied check directly covers it.
   Preserve lone dissent.
   RETURN: headline, synthesis, optional dissent, top_items<=3,
   ship_recommendation. Explain clean results from summaries and coverage.
   ```

   Validate its receipt against the schema, source receipts, and supplied
   checks: every top item must match an input finding, validation claims must
   match a supplied check, text must be non-empty, and bounds must hold.
   Retry malformed synthesis once. If it still fails, construct a valid
   `needs discussion` fallback that reports synthesis failure and retains no
   top items; never invent a technical finding.
6. Load `assets/recommendation-template.md`. Render normal human-readable
   Markdown. Omit optional sections rather than leaving empty placeholders.
   For `sequential fallback`, state immediately below the heading that isolated
   children were unavailable and the lenses ran sequentially with reduced
   context isolation.
7. Using the deterministic GitHub publication tools, first publish one inline
   comment for each finding with a verified new-side diff location. Prefix it
   with **Blocker**, **Recommended**, or **Nit**, then include rationale and
   follow-up. Findings without an inline-eligible location remain in the
   summary only.
8. Publish exactly one rendered summary. Include one row and one expandable
   block per selected lens. A clean lens must show its concrete coverage, not
   an empty accordion or only "No findings."

## Weights

`Blocker` | `Recommended` | `Nit`

Ship recommendation: `ship now` | `ship with follow-ups` | `needs discussion` | `needs rework`.