The premise here is correct, and getting the premise right is most of the battle. Almost nobody's problem with AI coding assistants is that the models cannot write code. They write code fine. The problem is that you asked for something in one sentence, the model filled in forty unstated decisions with its own defaults, and you got a confident, clean, well-structured implementation of something adjacent to what you wanted.
You then spend longer reading and correcting it than you would have spent writing it. This toolkit is built on the observation that the missing artefact is a specification, and that if you make the agent write one and make you approve it, the failure gets caught while it is cheap. The workflow runs in phases. You establish project principles that persist across work.
You describe what you want built and get a specification back. You review and clarify it, and this is the step that does the real work. You get a technical plan. That becomes a task breakdown, and only then does implementation happen.
Each phase produces a file that lives in the repository. What makes this more than a prompting convention is the clarification step. The agent is instructed to identify ambiguity in your request and ask about it rather than resolving it silently. In practice this surfaces the questions you did not know you were leaving open.
How should this behave when the input is empty. Does this need to be idempotent. Is this user-facing or internal. Should errors be retried.
Answering five of those before any code exists is enormously cheaper than discovering them in review, and it is the part of this workflow I would keep even if I abandoned everything else. The agent-agnostic design is the right call and unusual coming from GitHub, who have an obvious commercial interest in one particular assistant. The commands work across several tools and the specifications are plain markdown that any model can read. That means the artefacts survive you changing your mind about which assistant to use, which given how fast that market moves is not a small consideration.
Putting specifications in the repository has a second benefit that gets less attention than it should. Reviewing AI-generated code is genuinely difficult, because a pull request of four hundred plausible lines gives a reviewer no way to tell what was intended. Having the specification and plan in the same change lets a reviewer check the intent first and the implementation second, which is a much better use of their attention. Teams doing serious volumes of agent-assisted work need something like this.
Now the honest criticisms. The ceremony is real and the documentation is not straight with you about when it is disproportionate. Running a full specification, clarification, planning and task breakdown cycle to change a validation rule or fix an off-by-one is absurd, and you will feel the absurdity while doing it. The methodology has an obvious sweet spot, roughly a feature that would take a competent developer a day or more, and it should say so plainly.
Instead the framing suggests this is how you should work, and people apply it uniformly, and then abandon it because it felt like bureaucracy on the tasks where it was bureaucracy. Specification bloat is the other practical failure. Models are verbose. Ask one for a specification and you get several pages, much of it restating the obvious in structured headings.
Multiply that by every feature and you have a growing directory of documents that were accurate on the day they were generated and drift out of date immediately, because nobody updates a specification after the code changes. Stale specifications are worse than no specifications, and there is no real guidance here on curation, on what to keep, or on when to delete. The maturity question is straightforward. This is young, it moves quickly, commands and file layouts have changed between releases, and the community conventions are still forming.
That is not a criticism of the idea, it is a caution about building team process on top of something whose shape is not settled. And it works considerably better on new work than on old. Given a fresh feature in a reasonably clean codebase, the specification and plan phases produce something useful. Pointed at a change threading through a decade of accumulated code with implicit contracts and undocumented assumptions, the plan phase produces something confident and wrong, because the agent cannot see the constraints that live in people's heads.
Most professional work is the second kind and the documentation is quiet about that gap. My three point six is for correctly diagnosing the actual problem with AI-assisted development, for a clarification step that earns its place immediately, for staying vendor-neutral, and for making agent work reviewable. Marked down for not admitting how much of the time the process is too heavy, for producing documents that will rot, and for being early enough that adopting it means moving with it. Use it on the big things.
Do not use it on the small ones.