---
name: fallow-rs-panel-review
description: "Review a Fallow design, plan, workflow, CLI surface, documentation architecture, or user experience with representative end-user and domain-expert perspectives before implementation."
license: "MIT"
metadata:
  decimalai-skill-id: "6b62e2c6-d4bb-4166-bf4c-34c0f949a52f"
  decimalai-version-id: "1d40f761-d1a5-4d2a-a22f-bc9aa25214f9"
  decimalai-version: "4"
  decimalai-body-sha256: "e11519a832ff435e0cc0d9bbd5a5d1ff964900bfb6fb424147a77f89165adc8b"
  decimalai-name: "fallow-rs/panel-review"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "productivity"
  decimalai-source: "https://app.decimal.ai/s/fallow-rs-panel-review@4/SKILL.md"
---
<!-- Generated from .agents/skills. Do not edit. -->

# Panel review

1. Read the controlling plan or specification first.
2. Build one evidence package from current source, live behavior, and relevant
   public contracts.
3. Select representative users plus specialists for accessibility, security,
   privacy, compatibility, operations, or agent runtimes as applicable.
4. Ask reviewers for concrete blockers, concerns, follow-ups, and no-action
   decisions.
5. Verify load-bearing claims against source before accepting them.
6. Filter the findings first. Drop style preferences and "a different design
   would also work" unless the reviewer shows a concrete problem. Trace a call
   site before you accept a bug claim. Put each dropped finding under No
   action with one reason.
7. Synthesize consensus under:
   - Fix before change
   - Fix now
   - Follow-up
   - No action
8. Record approved decisions in the active `.plans/<task>.md`.

Do not expose private source text or internal review labels in public output.
Panel feedback is evidence, not authority over tested contracts.