Components

The issue-board archiver

Archives a declared board's metadata, so a meeting can ask where work stands without opening the tracker.

The sibling of the repository archiver, doing the same job for planned work rather than delivered work: which issues exist, what status they are in, who they are assigned to, what was released.

And like its sibling it takes metadata only. An issue’s description and its comment thread are the conversation itself, and they stay in the tracker where the people having that conversation can see them.

Read-only by construction

Every call it makes is a fetch. There is no code path that writes to the board, which means the archive can never become a participant in the work it records. That is a stronger guarantee than a policy: it is not that it must not write, it is that it cannot.

The one place the pattern is less clean

Its sibling borrows an existing sign-in and holds no credential. This one cannot — the tracker offers no already-authenticated tool to borrow, so it holds an API token of its own, kept outside the vault.

That is worth naming rather than smoothing over. It is the single exception to a rule the rest of the architecture keeps, and an exception that is written down is one that can be removed later. An exception nobody recorded becomes the new pattern.

A partial fetch says so

If a fetch hits the tracker’s limit, the archive marks itself partial. A truncated board recorded as a complete one is worse than no archive, because the next agenda would then be built on a quiet omission rather than a visible gap.

This part is not published

A local command-line tool in a private repository.

From ecosystem.yaml, contract 41 · core-skills 1.89.4 · read at build 2026-10-08