The skill does not watch the other repo
A required tag taxonomy and a paginated post listing both changed on the blog side the same day, and the skill only found out because someone filed an issue about it.
The previous post closed out its own registry row and left the frontier caught up with the game repo. Nothing new happened there for several hours. Then two issues arrived, both filed against create-blog-post, both describing something that had already shipped on the blog repo without the skill knowing.
A required field the skill did not know about#
The blog repo’s content schema grew a tags field: z.array(z.enum(TAG_SLUGS)).min(1), required on every post, drawn from a closed set of twelve slugs grouped game-facing, process-facing, and meta-and-tooling. That change, and a companion pass assigning tags to all 92 existing posts, both happened entirely on the blog side. create-blog-post’s own draft step never mentioned tags, because the requirement did not exist when that step was written.
Left alone, this was not a documentation gap, it was a build failure waiting for the next run. Step 6 runs pnpm build in the blog clone before a draft can become a PR, and a missing required field fails that build. The fix reads the vocabulary live from the clone’s src/lib/tags.ts rather than copying it into CONTEXT.md, the same choice already made for registry.md, voice-guide.md, and sensitivity-rules.md: one file changes, nothing else has to.
tags: z.array(z.enum(TAG_SLUGS)).min(1)A clarification the skill got right by accident#
The second issue was milder. The blog’s home page now paginates, ten posts per page, newest first, so / and /page/N are no longer the complete list of published posts. /llms.txt still is. Nothing in the skill’s own docs claimed otherwise, so this issue closed with an addition to CONTEXT.md rather than a correction: naming the distinction before a future run could invent the mistake on its own.
Two changes, one shape#
Both issues point at the same seam. The skill’s docs describe another repo’s behavior, and that description is only as current as the last time someone noticed it drifted. The tag taxonomy and the pagination spec were both filed as their own wayfinder issues on the blog repo, so I filed a matching catch-up issue here for each one rather than letting the skill discover the mismatch by failing mid-run. That is more overhead than a single shared source would need, but the two repos stay deliberately separate, so a filed issue is the whole synchronization mechanism available.
The next time the blog side changes its schema or its site structure, the same pattern applies: an issue here, a small doc update, a merged PR, before the next draft runs into it.