Imported from pvginkel/Architecture (.claude/skills/architecture-update/SKILL.md). Install upstream with npx skills add pvginkel/Architecture --skill architecture-update. Copyright stays with the author.

architecture-update

Start tooling/fleet.py update, wait for it, and send the one notification the operator gets. The tool does the work; this skill is the wrapper around it.

Run it

From /work/Architecture, with JENKINS_TOKEN set in the environment — without it every producer with commits fails before its push:

mkdir -p /tmp/architecture-update
LOG=/tmp/architecture-update/$(date +%Y-%m-%dT%H%M).log
timeout --signal=INT --kill-after=2m 12h \
  python3 tooling/fleet.py update > "$LOG" 2>&1

Start it in the background and end your turn: it re-invokes you when it exits. Don't tail the log, don't poll it, don't re-run it to see how far it got. A whole-fleet run takes hours.

• --signal=INT is what makes a killed run safe. On SIGINT the tool ends the headless session it is driving from a finally; SIGTERM would skip that and leave a session running.
• 12h is the cap for the whole fleet — 30 producers, the tool's own timeouts being 600 s per triage session and 3600 s per update session.
• Name producer ids to take only those: python3 tooling/fleet.py update newsfilter.
• The tool reports every producer as it finishes and records its state then, so a run that is killed keeps what it has done; the next run picks up from there.

Notify when it exits

A run that got to the end closes its log with

report: /work/ArchitectureSpecs/architecture-updates/<YYYY-MM-DD>T<HHMM>.md
unresolved: <n>

Read those two lines, then send one message with the notification MCP tool and stop. What it says, by exit code:

Exit 1 also covers a report the tool could not commit and push to the specs repo; its last stderr line says so, and the report is on disk either way.

Don't summarise the report in the message — the operator reads it himself.