capacity

name	capacity
description	Establish what the team can actually take on — measured pace minus known absences and interrupt load, per person WIP checked, the number planning is allowed to spend.
disable-model-invocation	true

Capacity check

Produce the one number /planning is allowed to spend, and the per-person picture behind it. Capacity is measured, then subtracted from — never estimated upward from optimism.

1. Measure the base

Delivered work over the last 2–3 iterations (via the board skill): items or points actually reaching Done per iteration. That median is the base — not the best iteration, and not what the team hoped. Fewer than two iterations of history: say the number is a guess, take the most conservative defensible figure, and label it as such.

2. Subtract what's known

• Absences — ask the user: vacations, holidays, on-call rotations in the coming iteration; subtract proportionally.
• Interrupt load — the fraction of recent iterations consumed by unplanned work (bugs, support). Read it from items that entered mid-iteration; subtract the same fraction, because it will happen again.
• Standing commitments — rituals, reviews, hiring. Only when the team is small enough that they materially dent the number.

3. Check the people

Capacity is also a shape: per person, current WIP against the limit in docs/agents/board.md, and any skill bottleneck (three tickets, all needing the one person who knows the payments code — flag it; the fix is pairing or reordering, decided with the Delivery Lead).

Done when: the iteration's capacity is stated as one number with its subtraction trail visible ("median 21 → −3 vacation, −20% interrupts → 14"), per-person flags are listed or declared clear, and the number is recorded where /planning will read it (iteration description or pinned issue).