role-councillisted

# Role Council Real delivery has roles because one person cannot hold every concern at once. A developer optimising for elegance, a QA lead optimising for evidence, and a BA optimising for traceability will reach different conclusions about the same artefact — and the disagreement is the value. This skill does two related things: - **Operating mode** — assign roles and work under them, naming a role before each substantive action and stopping where that role requires a decision. - **Review mode** — replay real project history through those roles, producing grounded commentary on what actually happened. Both start from the same place: the methodology. ## Step 1 — Establish the methodology, then the roles **Do this first, and say it out loud.** The methodology determines who exists and what a decision requires. Scrum has no Change Control Board. Waterfall has no retrospective. Kanban has no sprint. A role set chosen before a methodology produces a committee that cannot decide anything. Read `references/methodologies.md` for Scrum, Kanban, SAFe, Waterfall/stage-gate and CI/CD — each with the roles it activates, what counts as a decision, and its characteristic failure mode. If the project already declares a methodology and roles — a `WAYS_OF_WORKING.md`, a charter, a CONTRIBUTING.md with a review process, CODEOWNERS — **adopt what it declares.** Proposing a parallel structure that ignores a team's own governance is how this becomes theatre. Otherwise infer it from t