Methodology

Conclave assumes standard Scrum with practical accommodations real engineering teams make: a discipline-first roster (every project has Tech Lead, Frontend, Backend, QA, Designer, and DevOps work, whether or not it has a dedicated Product Manager or Scrum Master), and git as the team’s coordination substrate.

The Scrum mapping

Solo developers get their own setup path: /conclave-init asks up front whether the project is solo or a team. Solo mode forces the lean profile and renders a single-person roster covering every discipline; team mode asks who covers each of the six disciplines (name + GitHub handle, or TBD) plus who — if anyone — holds the PM/SM process roles.

The artifact tree

At the root of the team’s repo, Conclave maintains a visible conclave/ directory. Everything is markdown.

conclave/
├── README.md                         # explains the directory on GitHub
├── config.md                         # project type, stack, team_mode, team_profile
├── team/
│   ├── roster.md                     # who covers which discipline, plus optional PM/SM
│   └── ceremonies.md                 # cadence
├── product/                          # persists across sprints
│   ├── backlog.md
│   ├── architecture.md               # living ADRs
│   ├── definition-of-ready.md
│   └── definition-of-done.md
├── context/                          # frozen snapshots of inputs
└── sprints/
    └── SPRINT-NNN/
        ├── meta.md                   # name, dates, status
        ├── spec.md                   # sprint plan
        ├── stories/
        │   └── US-NNN-<slug>.md
        └── acceptance/
            └── AC-US-NNN.md

Invariants every Conclave command respects

• Markdown only. Structured fields live in YAML frontmatter. The body is human-readable prose.
• Visible directory. conclave/ is not hidden — it renders on GitHub and is discoverable.
• Append, do not clobber. A second /conclave-spec run creates SPRINT-002/ and updates product/backlog.md additively; it never overwrites previous work.
• Snapshot context. Every artifact-generating command writes a fresh snapshot under conclave/context/ so the artifact is auditable against the inputs that produced it.
• Reference, do not duplicate. Stories reference their acceptance file; sprint spec references product/definition-of-done.md rather than copying it.
• Numbering is sticky. SPRINT-NNN and US-NNN IDs increment monotonically and are never reused.
• Roster schema degrades gracefully. A roster.md written before the discipline model shipped (no Discipline column) is not rejected — commands treat every member as multi-discipline and print a one-time compatibility hint.

How slash commands invoke role subagents

Each slash command is a markdown orchestrator. Its body says, in prose: “Spawn a subagent loaded with skills/conclave/agents/<role>.md to produce X.”

Claude reads the role charter file, dispatches an Agent tool call with that content as the system-prompt prefix, and continues when the subagent returns. Independent roles run in parallel by issuing both Agent calls in a single message (PM + TL in /conclave-spec). /conclave-planning runs in two waves instead of one: PM + TL in parallel first, then SM alone — assignment needs to know the discipline the Tech Lead just assigned to each story before it can pick a valid assignee.

There is no DSL. The pattern is the same one Anthropic’s own code-review plugin uses for its parallel review agents.

How teams coordinate

Each team member runs their own local Claude Code. The shared state lives in conclave/ and is committed to git. Coordination happens through pull requests:

• PM grooms the backlog → opens a PR to conclave/product/backlog.md.
• Dev, Designer, or DevOps picks up a story (whichever matches its discipline) → branches feat/US-NNN-<slug> → implements → opens a PR.
• QA verifies → appends a verification report to the acceptance file → PR comment.
• TL approves the code (when peer_pr_review.required: true) → runs gh pr review --approve.

There is no central server, no proprietary state, no surface for vendor lock-in. The team owns the workflow because the workflow is just files in their own repo.