rollup

name

rollup

description

Generate the federation roll-up catalogue for a multi-repo product — aggregate every member repo's ADR metadata into one derived, product-wide view, run from the home repo. Use when the user says "roll up the federation", "generate the product-wide ADR view", "aggregate ADRs across the repos", "refresh the roll-up", or invokes /rollup. NOT for regenerating a single repo's own INDEX (that happens in place during authoring/ship) and NOT for linting consistency (use the audit skill).

rollup

Aggregate the ADR catalogues of every repo in a multi-repo product into one derived, read-only product-wide view. The roll-up is regenerated from source, never hand-edited — treat it exactly like a repo's own INDEX.md.

Step 0 — Preconditions

1. This skill runs in the index-holding repo of a federation — the one that carries federation-index.md (its Role is central for topology A, coordinator for B, or home for C). Confirm federation-index.md and a federation.md whose Role is central, home, or coordinator exist. If they do not, stop: either this repo is standalone (nothing to roll up) or it is a plain member — point the user at the index-holding repo.
2. Read federation.md to learn the identity scheme (default repo-prefixed slug <repo-id>/NNNN-slug); roll-up rows use it.

Step 1 — Enumerate members

Read federation-index.md. For each row, take the Repo id and the Pointer (the path/URL of that member's checkout). The member index is the only source of membership — do not auto-discover repos.

Step 2 — Collect each member's catalogue

For every member whose checkout is locally available at its pointer:

• Read that member's INDEX.md (its authoritative local catalogue).
• For each ADR row, capture the number, title, status, date, and dependencies, and attach the owning repo id and the federation identity (the scheme from Step 0 applied to the local number).

A member's own INDEX.md stays authoritative for that member; this skill only reads it.

For the aggregate status of a product-wide decision (one with owning per-repo plan items across several members), also scan each member's plan/todo/ (pending) and plan/done/ (shipped) for items naming that decision's federation identity — that per-repo state feeds the aggregate column in Step 4.

Step 3 — Handle unreachable members

A member named in the index whose checkout is not locally available is not dropped and not a failure. Record it in a clearly separated "Not aggregated this run" list with its repo id and pointer, so the gap is visible rather than silent.

Step 4 — Write the roll-up

Write the aggregate to ROLLUP.md at the configured artefact root (the same root as INDEX.md), so every re-run overwrites the same file:

• A header stating it is generated — do not hand-edit, with the run date and the set of members aggregated.
• One table across the whole product: federation identity, title, status, owning repo, date. Group or sort by owning repo for readability.
• For product-wide decisions, an aggregate status column derived from per-repo plan-item state: Implemented only when every owning per-repo plan item is in a member's plan/done/, otherwise N of M repos shipped. This column is derived — never written back into any ADR.
• The "Not aggregated this run" list from Step 3.

Do not alter any member's INDEX.md and do not write into any other repo.

Step 5 — Report

Tell the user how many members were aggregated, how many were skipped as unreachable (and which), and the total ADR count in the roll-up. Remind them the file is derived: re-run this skill to refresh it rather than editing it by hand.