Skip to main content

Running the Agentic Development Workflow

Introduction​

With the instructions, skills and agents from the previous three chapters in place, the account dashboard project is ready to be built. From here on, your job shifts from writing code to directing agents: choosing which requirement to tackle, switching to the right chat mode, and answering the occasional question an agent asks you (which branch to use, whether to merge).

Requirements live as plain-English files under development/requirements/. You tackle them one at a time, driving each one through the same five-stage pipeline: analyse, develop, review, test, release.

GitHub Copilot tip: If an agent produces an unexpected result, don't fight it in the same chat mode — switch to Review Code and ask it to check the output against the spec. Keeping each agent focused on its own responsibility is more reliable than asking one agent to also critique its own work.

Concepts​

The requirement-to-release pipeline​

  1. Req-Analyst reads a requirement and writes a technical spec plus a tracker entry.
  2. Develop Code reads the spec, branches, implements, tests, and builds.
  3. Review Code checks the result against the spec and coding standards.
  4. Test Code runs the full suite and fills any coverage gaps.
  5. Release packages the app and, on your confirmation, merges back.

Where things live​

  • development/requirements/ — input: one plain-English requirement per file.
  • development/spec-<name>.md — output of Req-Analyst: the technical spec for one requirement.
  • development/spec-tracker.md — a running log of every spec's status (Drafted, Implemented, Reviewed, Released).
  • development/review-<name>.md — output of Review Code, only created if there are findings.

Human checkpoints​

Even in a fully agent-driven workflow, two decisions always come back to you:

  • Which branch to create the new work from, and what to name it (Develop Code asks).
  • Whether to actually merge back to the source branch (Release asks).

Examples​

A typical run for a requirement called add-transaction-history.md:

# Step 1 — switch to Req-Analyst chat mode
"Execute the requirement add-transaction-history.md"
# → writes development/spec-add-transaction-history.md
# → adds a row to development/spec-tracker.md

# Step 2 — switch to Develop Code chat mode
"Execute the tech spec spec-add-transaction-history.md"
# → agent lists local branches, asks: source branch? new branch name?
"main" / "feature/transaction-history"
# → implements, generates tests, runs them, builds

# Step 3 — switch to Review Code chat mode
"Review the code"
# → checks against the spec and coding standards

# Step 4 — switch to Test Code chat mode
"Test the application"
# → runs the full suite, adds any missing coverage

# Step 5 — switch to Release chat mode
"Package and merge the code"
# → builds/packages, then asks for confirmation before merging

Challenges​

1. Create a requirement and run the analyst​

  • Create development/requirements/add-transaction-history.md describing a small feature (e.g. "show the last 5 transactions on the account dashboard").
  • Switch to the Req-Analyst chat mode and prompt: "Execute the requirement add-transaction-history.md".

Ask Copilot: What should the Req-Analyst do if I don't tell it which requirement file to use?

💡 Show Answer

Per its chat mode instructions, it should ask you to name the requirement file rather than guessing — this was deliberately written into req-analyst.chatmode.md in Chapter 3 to avoid the agent silently picking the wrong requirement.

2. Develop the change​

  • Switch to the Develop Code chat mode and prompt: "Execute the tech spec spec-add-transaction-history.md".
  • Answer its questions about the source branch and new branch name.

Ask Copilot: Why does the Develop Code agent ask for a source branch instead of always branching from main?

💡 Show Answer

Not every change necessarily branches from main — a fix might need to branch from an existing release or feature branch. Asking keeps the agent from making a decision that has real consequences (where the change's history starts) without your input.

3. Review, test and release​

  • Switch to Review Code and prompt: "Review the code".
  • Address any findings, then switch to Test Code and prompt: "Test the application".
  • Finally, switch to Release and prompt: "Package and merge the code", confirming the merge when asked.

Ask Copilot: What's the risk of skipping straight from Develop Code to Release, without the Review and Test stages?

💡 Show Answer

The Develop Code agent only tests the specific change it just made. Skipping Review means nothing checks the result against the spec and coding standards from an independent perspective, and skipping Test means regressions elsewhere in the suite could go unnoticed until after release.

4. Run a second requirement end-to-end​

  • Add a second file under development/requirements/.
  • Drive it through all five stages unassisted, checking development/spec-tracker.md after each stage to confirm its status updates as expected.
💡 Show Answer

By the end, spec-tracker.md should show the second requirement progressing through Drafted → Implemented → Reviewed → Released, mirroring the first — this is the check that the pipeline generalises beyond the one worked example, rather than only working for the requirement it was demonstrated on.