brse-skill-namelisted

# BrSE Skill Name ## Overview One or two sentences describing the skill's core principle. State the principle, not the procedure. **Core principle:** [Single rule the skill enforces — the one thing the BrSE must hold onto even under pressure.] ## When To Use - Concrete triggering situation (BrSE-facing). - Symptom in stakeholder message or dev report. - Trigger from another skill (workflow-chain stage). ## When NOT To Use - Situations that look similar but require a different skill (link the right one). - Situations where this skill would add noise rather than structure. - Out-of-domain inputs. ## Inputs What the skill needs before it runs. List required vs optional inputs. If a required input is missing, the skill must surface that and stop — not fabricate. 1. **[Required input]** — what it is, where it comes from. 2. **[Optional input]** — what changes if present. ## Workflow 1. Step 1 — what to check first. 2. Step 2 — main transformation. 3. Step 3 — verification / gating step. 4. Step 4 — output decision. Keep steps short. If a step has 4+ sub-steps, move it into `references/`. ## Output Shape ```markdown ## [Section 1] ## [Section 2] ## [Decision / Verdict] ``` Use Japanese headings (`## 結論`, `## 確認内容`) when the output is customer-facing JP. Use English headings when the output is internal BrSE/dev working artifact. ## Rules - Do — concrete positive rule that resolves a specific failure mode. - Don't — concrete negative rule that closes a specific lo