v1.18.0 ·
The platform that was already half working
The question was simple: is AIDLC compatible with GitHub Copilot? The CLI seemed to answer it. Ask it to install for Copilot and it exits with code 2 and a list of platforms that does not include it. Five adapters existed, Copilot was not one, write the sixth.
Then I read Copilot's docs. It does not look in one place for skills. It searches three directories, and two of them are directories AIDLC already writes. Anyone who had installed for Claude Code or Codex was already exposing every lifecycle skill to Copilot as a slash command. Unsupported according to the tool, working according to the disk.
One of those directories gets thin pointer files: a name, a description, and a sentence saying go read another file. The other gets the full skill body inline. A pointer costs the agent a round trip, and the previous release had removed exactly that indirection for another platform because it made that platform second-class. So a Copilot user who installed for Claude Code got the worse packaging, one who installed for Codex got the better one, and nobody had chosen or been told.
What changed
Copilot is now a first-class platform. The installer writes the lifecycle skills where Copilot looks first, one directory per skill with the full body, plus a managed block in the one instruction file every Copilot surface reads. The entry point is the aidlc slash command, with a hint that free text can follow. Nothing is written under another vendor's directory, and a test asserts that, the negative as well as the positive.
The adapter is packages/cli/src/compile/adapters/copilot.ts. Everything else extended something that existed: one platform identifier, one registry entry, one packager so project-authored operational skills reach Copilot, and one capability map that sends the planning phases to Copilot's plan mode.
Why this way
Aliasing an existing platform would have been a two-line registration and a perfect demo. It would also have coupled two vendors' packaging for good and picked, by accident, whether Copilot users get bodies or pointers. The person asking said Copilot would be their primary tool, and a primary tool should not depend on a competitor's directory being installed.
For the instruction file I chose the one named after Copilot over the vendor-neutral AGENTS.md. Copilot's own support matrix says the neutral one is the narrow option: Visual Studio chat reads neither it nor the Claude equivalent, and code review accepts it but not its siblings. The Copilot-named file is the only one every surface reads, including the cloud agent that opens pull requests and the reviewer that reads them. That rests on somebody else's table, which can change, so the reason is written down.
Installing on this repository showed the aidlc slash command opening by telling Copilot to switch to plan mode, while the skill's own text says it must not. The override that suppresses plan mode had been declared for Claude Code only. Three interactive menus were hit: the entry point, the roadmap inbox and the constitution importer. I declared the override for Copilot too, then removed the fix, rebuilt, and watched the guard test fail by name before restoring it. A guard only ever seen passing is not evidence yet.
What it does not do
Copilot has no cost tracking. It publishes no session-log format, so there is nothing to parse, and I will not reverse-engineer an undocumented file as a rider on a packaging change. Per-instance cost for Copilot work shows nothing. That is known, not a defect. I also skipped prompt files, since the same matrix lists them in no client row and Copilot's docs recommend converting them to skills.
Cost for this instance reconciled at $81 at full fidelity, but only after the fact. The capture script is untracked, so it is missing from every fresh worktree, and for the third instance in a row nothing was read at the end of testing.