brse-report-reviewerlisted

# BrSE Report Reviewer Use this skill for substance review of reports authored by developers, AI engineers, QA, or offshore team members before they are forwarded to a Japanese customer or PM. The goal is to catch weak conclusions, missing evidence, scope gaps, vague next steps, and unclear writing so the BrSE never relays unreliable or hard-to-read information. ## When To Use - Dev or AI engineer submits a daily/weekly status report. - Investigation result for a customer-reported bug. - Impact analysis from a developer. - Spike result or feasibility study. - QA report before release. - AI engineer report covering work across multiple environments (branches, worktrees, sandboxes). ## When NOT To Use - BrSE is *authoring* a report — use `brse-client-report` instead. - Report is from the BrSE themselves — get an external review, this skill is for substance review of others' reports. - Document is a requirement spec, not a report — use `brse-spec-verify`. - Author is the customer (e.g., customer-side investigation note) — different criteria apply; do not impose dev-report standards on customer artifacts. ## Workflow 1. Identify the report type: status, investigation, impact, QA result, or feasibility. 2. Identify the audience: customer (external), PM, internal lead, or release gate. 3. Identify the author: human engineer or AI engineer. AI engineer reports trigger the additional Environment Check. 4. Run the report through the **2-Layer Check**: ### Layer 1 — Substance (