How the template evolved

We started with a manual workflow and gradually automated the steps that proved useful and repeatable.

The ideas behind the workflow are not new. The template combines established software engineering practices with AI coding tools and fits them into a development process on GitHub.

  1. Initial workflow
  2. Structured planning
  3. Independent verification
  4. Improved reliability
  5. Unattended execution
  6. Learning from runs

  1. Initial workflow

    The first version was mostly documents: instructions for agents, a few policies, a setup guide, and a rhythm of plan, act, and evaluate. A feature was planned in a GitHub issue, built in its own worktree, and read by a second agent. Developers had to move between the steps themselves.

    The first scripts took over what was the same every time: creating the issue of a feature, starting the work, and starting the review. Soon after, each review finding got an explicit decision, and the implementer fixed only what had been decided.

  2. Structured planning

    Until then the template assumed that you already knew what to build. A planning process was added before the first feature: from an idea to clear requirements, an architecture, and a roadmap.

  3. Independent verification

    Practical use revealed that some checks relied too heavily on the agent's own reports: that the tests had passed, that a review covered the current code, that a finding had been dealt with.

    These were replaced by records a script can check. The project's checks got one command. Reviews and decisions about findings became structured records, each linked to the version it was written for. Reviewers lost the ability to edit files. The plan got its own independent review and an approval linked to the approved version of the documents.

  4. Improved reliability

    Building real features brought practical problems to the surface, and each got an answer:

    • A session can end unexpectedly, so a feature can resume from a handoff note.
    • Verification ran more often than needed, so a successful run is reused for unchanged content.
    • A plan sometimes has to change after its approval, so there is a change process for it.
    • A second review only needs to read what changed.
    • A project created from a template does not receive later improvements, so a script brings them over.

  5. Unattended execution

    Once every step was a script, the steps could run in a row. One command now takes a feature from its issue to an open pull request without stopping for routine input. It ends at the pull request: it does not merge.

    Unattended work needed clearer rules. A script, not an agent, decides whether a step succeeded, and it retries a temporary failure. "Blocked" means only that a person has to decide. Reviews must stay up to date when the code or the base branch changes. And whether a change needs the owner's approval is no longer left to the agent that made the change.

  6. Learning from runs

    An unattended run that ends at a pull request also hides what it took. A session that ended was not always a finished feature, so the scripts now commit and close an issue only when the implementer's own record says the work is complete, with evidence for every criterion.

    Then the runs themselves became something to learn from. Every run records how long its steps took and how many tokens its agents used, kept on the developer's machine. A report shows what a feature cost and how many rounds it needed, and says when a figure is unknown rather than counting it as zero. Each run also keeps what happened in it, with a reference to the evidence: the review findings, the stops, the repairs. An analysis by a read-only agent compares several features and proposes improvements, each with the place it belongs; the developer decides what to do with them.

What the order shows

The template is still evolving. See Possible improvements for the ideas under consideration.