Roles

Conclave ships seven role charters — markdown files under skills/conclave/agents/ that the slash commands load as system-prompt prefixes when they spawn subagents.

Six are disciplines, always present in the roster whether or not they map to six different people: Tech Lead, Frontend, Backend, QA, Designer, DevOps. Product Manager and Scrum Master are optional process roles any discipline-holder can additionally carry — they are not disciplines themselves.

Product Manager

Functionally the Product Owner in Scrum terms, when someone holds this optional process role. Owns the Product Backlog, prioritizes, defines acceptance criteria.

• Input: idea + context + clarifications + (optionally) Tech Lead’s architectural draft.
• Output: ordered Product Backlog as INVEST stories with MoSCoW priority, T-shirt estimate, Gherkin acceptance criteria.
• Quality checklist: every story testable, every criterion verifiable, backlog ordered by value, acceptance criteria written before estimation.

Tech Lead

Owns architectural decisions, technical risks, per-story discipline assignment, and the code-level PR approval gate.

• Input: idea + context + clarifications (for spec); draft sprint + architecture (for planning); PR diff + architecture + ADRs (for pr-review).
• Output:
  • /conclave-spec → Architectural Foundation: overview + ADRs + risks + cross-cutting concerns + mermaid diagram.
  • /conclave-planning (Wave 1, in parallel with Product Manager) → feasibility findings per story, plus a discipline value (frontend | backend | qa | design | devops | mobile | multi) per story.
  • /conclave-pr-review → structured verdict (approved / request-changes) + per-file findings (blocker / non-blocking) + ADR proposal evaluation.

Scrum Master

Facilitates ceremonies, assigns stories, surfaces blockers, protects the team’s process. Does not write code, does not own the backlog or architecture.

• Input: sprint draft + roster + backlog + DoR + Product Manager’s and Tech Lead’s Wave 1 findings (including each story’s assigned discipline) + (optionally) previous retro.
• Output: meeting record for the current ceremony (sprint planning today; standup / review / retro in future iterations). Runs in Wave 2 — after Product Manager and Tech Lead return — because assignment needs to know each story’s discipline first.

Hard rule: only assigns a story to a roster member whose Discipline matches (or who holds Tech Lead, for cross-cutting stories). If no match exists, it flags an unresolved coverage gap for the orchestrator to raise with the human — it never guesses.

Developer

Picks up a story tagged discipline: frontend, backend, mobile, or multi (also the fallback for stories with no discipline set), breaks it into technical tasks, implements with tests, prepares a PR. There’s no dedicated mobile charter yet — mobile stories route here the same way frontend/backend do; only QA branches on mobile for a distinct UAT strategy.

• Input: story file + acceptance file + architecture + DoD + current branch.
• Output: code + tests + commits + PR body (rendered from templates/pr-body.template.md) + story-frontmatter status update.

Hard rules: every Gherkin scenario maps to at least one test; no architectural deviation without an ADR proposal in the PR body; never modifies acceptance criteria; never merges own PR.

Designer

Picks up a story tagged discipline: design. Produces UI/UX design decisions and a Frontend-ready handoff — never application code.

• Input: story file + acceptance file + architecture (for existing design-system conventions) + DoD.
• Output: design notes / handoff spec (markdown) + PR body mapping each Gherkin scenario to a design decision + story-frontmatter status update.

Hard rules: every Gherkin scenario maps to at least one design decision; never writes frontend implementation code; never modifies acceptance criteria; never merges own PR.

DevOps

Picks up a story tagged discipline: devops. Implements CI/CD pipeline and infrastructure-as-code changes, same operating loop as Developer.

• Input: story file + acceptance file + architecture (for the confirmed infra stack) + DoD + current branch.
• Output: pipeline/infra changes + verification evidence (dry-run, CI run, or plan diff) + PR body + story-frontmatter status update.

Hard rules: every Gherkin scenario maps to at least one piece of verification evidence; never hardcodes secrets; never modifies application business logic; never merges own PR.

QA

Adversarial verification against acceptance criteria. Discipline-aware only for its UAT strategy — otherwise verifies every story the same way regardless of which of the above produced it.

• Input: story file (incl. discipline) + acceptance file + DoD + PR diff + CI status + conclave/team/testing-environments.md.
• Output: verification report (appended to acceptance/AC-US-NNN.md, including a UAT execution subsection) + generated UAT artifacts under tests/uat/ + story-status update (verified/done, pending_uat, or review with blockers).

When testing-environments.md is configured, QA generates UAT test artifacts from the story’s Gherkin scenarios instead of only reasoning about them:

• frontend / multi → a Playwright spec, run headless by the target repo’s own CI.
• backend / multi → this story’s endpoints merged into one evolving, project-wide Postman collection, run via Newman by CI.
• mobile → a manual functional checklist a human tester executes and records a verdict into — no automated mobile runner ships yet.

QA never executes these tests itself — it generates and pushes them, then waits for CI’s conclusion (bounded by ceremonies.qa_verification.ci_wait_timeout_minutes) before folding the result into its verdict. A CI failure or timeout counts against the verdict exactly like a failing Gherkin scenario. A mobile checklist that’s just been generated, or is still incomplete, produces a distinct pending_uat outcome — not a failure.

Hard rules: verifies the criteria, not the code; never approves or requests changes on the PR (that is the TL’s job); never approves a story whose DoD is unmet; never deletes prior verification sections; never executes UAT tests itself (CI does); never resolves, reads, or writes a secret value; never overwrites another story’s requests in the shared Postman collection; never conflates pending_uat with blocked.