How This Post Was Made

Prompt: “we just did a bunch of work moving from a markdown-based planning system into a github issues/projects system. it’s still new, but check the web repo mainly, but also ios and android to see what we did in recent commits/prs, and draft a post about our learnings from the markdown system (pros and cons) and why we decided to move, how we did it, and how it’s all set up. an interesting thing imo is that we combined our skills+scripts work (from an earlier post) with the bin/next setup, which is kinda neat.”

Generated by Claude Fable 5.1 using the blog-post-generator skill. Sources were the web repository’s migration tracking issue and its day-two simplification issue, the merged PRs that added bin/next, the digest and rot-check workflows, and the reconciler, the plans-to-issues migration PRs in all three repositories, the mirror-policy PRs in iOS and Android, the current planning and gh-issues skills, and the pre-migration index and skills read from git history at the last commit before the move. The commit counts in the first table were recomputed with git rev-list --count --since=2026-03-01 --before=2026-09-02 and git log -- plans PLANS.md over the same window; they match the figures in the tracking issue. The board counts and open-issue counts were read live from GitHub on 2026-09-03.

Judgment calls: the owner and the designer are unnamed, per the blog’s anonymization rule, and the issue template’s “Standing” line shows “owner-requested” in place of the owner’s name. Vendor names, costs, and the ranking thesis in the planning index were left out. The group excerpt is trimmed from the real function to the branching that carries the rules and keeps the real names; the wrapper script is the iOS one, shortened by one comment line. The acceptance target of under 20 percent of commits touching planning files is stated as not yet measured, because the migration is one day old. Line counts for the old and new skills are from wc -l on the two commits.

Fact check (2026-09-04): The owner asked, “see [internal PR URL redacted] and consider updating our latest post if we’re including code examples that might stress api rate limits, also make a note about this as a gotcha – agents building these tools should beware gh api rate limits especially with the graphql endpoint” GPT-5 checked the post against the source change, its live-output comparison, and GitHub’s GraphQL rate-limit documentation. The existing grouping excerpt was kept because it makes no network calls. The surrounding description now records the original query’s broad Project fields and nested issue histories, the measured drop from about 1,472 GraphQL points to 9, and the bounded replacement. It also tells agents to measure query cost, avoid unused nested connections, and apply scope before fetching. The Guardrails and Results sections now record that the follow-up retires the reconciler and two scheduled workflows in favor of recurring queue items. The last lesson was replaced with the rate-limit rule because the day-two redesign is already covered in the preceding section. The internal source URL was redacted from the published prompt and omitted from the post.