v1.6.0: one plugin, two cooperating suites

Released 2026-07-23. The largest single change in the kit’s history, and the release where it stopped being a migration pipeline and became the thing this repository is now.

What we were trying to fix

The kit migrated legacy applications. It did that well enough by this point that four of them were live in production, which had been the whole announcement of v1.4.1 at the start of the same day. But a migration does not end when the application ships. It ends with a list: owner decisions, deferred tasks, things noticed and not done. The release immediately before this one, v1.5.0, had built the skill that consolidates those follow-ups and updates them at their source.

Which exposed the next gap immediately. A follow-up that genuinely deserves a ticket has to become one, and there was no way to do that without leaving the kit entirely and hand writing a GitHub issue. The pipeline could tell you what was outstanding and then had nowhere to put it.

Separately, and more mundanely, the prerequisites were listed in three places: the preflight script carried its own hard coded list, the README carried a second copy, and phase 0 of the migration skill carried a third. Three copies of one list is two copies too many, and they had already begun to disagree.

And a review filed that morning against the Anthropic skills guide had found six things wrong with how the kit’s six skills were packaged: descriptions over the standard’s length limit, missing frontmatter, no licence file, no trigger lists, and recipes duplicated between each skill’s SKILL.md and its own references.

What we decided

Import the missing half rather than write it. Four generic issue and pull request skills came in from another project: create-issue (an issue seeded with a brainstorm, a spec and a tickable plan), implement-issue (plan to draft pull request to ready, one commit per task), merge-pr (wait for CI, correct until mergeable, squash merge, triage follow-ups) and get-repo-profile, plus the shared skills/_shared/ directory they lean on.

The work was not the import, it was the de-specification. The skills arrived carrying their origin repository’s descriptions, CI issue numbers, ADR links, label taxonomy and temporary file paths. All of that came out, and every repository specific fact moved into one committed file, .claude/skills/repo-profile.md, which is what the skills read instead of knowing anything themselves. That is the abstraction those skills had always claimed; this is the release where it was made true, by porting them somewhere they had never run.

Five things in the import were deliberately not retained, and the release commit names all five: auto-dev, the fleet orchestrator; run-studio-web, an IDE launcher; socratic-prompts; the origin repository’s own profile; and a settings.json full of hooks that did not exist here. The CHANGELOG entry for this release lists only four of them, dropping socratic-prompts and describing run-studio-web by function rather than by name, so the commit message is the better record. Leaving the orchestrator behind is the one worth noting, since the kit later grew its own auto-dev from scratch; taking this one as it stood would have meant inheriting assumptions about a repository nobody here was working in.

The bridge is the point of the whole release. A migration follow-up that earns a ticket now becomes a GitHub issue through the kit’s own skill, and the entry in report.json keeps the issue URL. Never a parallel list. That rule is why the two suites are one plugin rather than two: the migration pipeline produces work, the lifecycle skills consume it, and neither maintains its own copy of the other’s state.

requirements.json became the single source of prerequisites, covering tools, required and recommended MCP servers and session skills, including the lifecycle skills’ own dependencies. The preflight reads it instead of embedding a list, and the README and phase 0 point at it instead of repeating it. Three lists became one, with a golden test that fails when a required entry is genuinely missing.

The skills-guide findings were all resolved in the same release: six descriptions inside the 1024 character limit with bilingual triggers, frontmatter completed across all six skills, an MIT LICENSE, per-skill trigger lists gated in CI, deduplication of each SKILL.md against its own references so the gh and jq recipes live in exactly one place, and Troubleshooting tables.

ARCHITECTURE.md was written last and is the artifact that made the rest legible: a call graph of the skills, a graph of the external dependencies, a per-skill dependency matrix, and a table of which concern has its single source where.

What got cut

A description optimisation attempt for the follow-ups skill was run on the bench, came back inconclusive, and the original description was kept. That is recorded in the commit immediately before this release. It is a small thing to have written down, and it is the right thing to have written down: an experiment that changed nothing still tells the next person not to repeat it.

One correction for anyone tracing this release back through its review. The skills-guide report header names that same preceding commit as the tree it was run against, and that cannot be true: at that commit the kit had two skills, while the report audits six and cites file paths under skills/implement-issue/, skills/merge-pr/ and skills/get-repo-profile/ that do not exist until this release’s own commit. The review was run against work in progress, and its header recorded the last commit rather than the tree in front of it. The findings are sound; the provenance line is not.

The parts of the import that were dropped were dropped without a follow-up ticket. They were not deferred work, they were another repository’s furniture.

What bit us

Importing skills from another project means importing its assumptions, and assumptions do not announce themselves. The ones that were easy to find were the literal strings: an issue number, a label name, a path. The ones that took the actual work were structural, where a skill was written as though a fact about its origin repository were a fact about repositories. Every one of those had to become a field in the profile, and the profile is now the file that answers the question “what do these skills need to know that they cannot know themselves”.

The trigger lists are the honest debt of this release. They shipped with a CI gate, which is excellent, and the gate checks that the files exist and are well formed. It does not run them. The release after this one had to add a line to each file saying so, because a green check next to a list of trigger phrases reads, to anybody who did not write the gate, as a claim that the triggers were tested.

This is the third of six releases that all went out on 2026-07-23, and it is the one that caused the two immediately after it. It shipped because the skills-guide review had to land with the import rather than after it, and the moment it did, the tree it produced was reviewed twice more under two different lenses before the afternoon was out. v1.7.0 and v1.8.0 are both answers to this release, published minutes apart, which is what it looks like when a change lands large enough that nobody trusts it yet.