Agent workflow & loops

Splits oversized epics into agent-sized stories and produces a parallel-safe dispatch plan with dependency order.

Reads an epic + linked stories, posts a detailed development plan, and attaches a PDF design doc for architectural decisions.

Turns a functional story into engineer-ready technical sub-tasks — screens, APIs, data model, edge cases, non-goals.

Mines past work from the RAG, grounds in the repo, and posts a self-contained plan the code-creator implements without re-exploring. Reads linked Figma designs where the story references them.

Clears the open questions parked in Jira checklists. Walks a story or epic and everything under it, and for each question hunts the answer in the story tree, the comments, the repo, and Confluence. Answers it can evidence get ticked with the answer in green and the source it came from; the rest stay unticked with a red note saying what's missing, what was checked, and what would unblock it — tagging the follow-up owner and commenting on the issue so the request is actually seen. It never ticks a box it inferred rather than found, and leaves plain to-dos and business decisions alone.

Reads the story (and any code-planner plan), calibrates against past work, and posts a planning-poker estimate — points, day range, risks; per-sub-story on parents.

Runs jira-estimator on every open story under an epic — one run and one estimate comment per story; already-estimated stories are skipped, so a re-run only fills the gaps.

Explores a client repo and generates context.md / tooling.md so agents start with full project context.

Adopts the plan, implements the changes across the repo, and opens a PR ready for review.

Reads a story's bug sub-tasks — issue type Bug, or "bug" in the title — and fixes every one of them on a single shared branch, one commit per bug, then opens one PR covering the whole set. Each commit carries its own bug's Jira key, so the history reads as one fix per ticket.

The regression-risk pass between creator and reviewer, answering one question: will this diff break or silently change behaviour existing code depends on? Checks out the PR branch, traces callers and dependents of every changed signature, return shape, export, default, or schema contract, and optionally runs a type-check or test to prove a break. Posts a 🔎 CODE ANALYZER comment with a machine-readable risk level that the reviewer then factors into its verdict.

Checks the diff against the story's acceptance criteria, reads the code-analyser comment, and posts a structured approve / request-changes decision.

Reads the requested changes, checks out the branch, applies fixes, pushes, and resolves the review threads — then it goes back for re-review. Also accepts free-text guidance (e.g. an acceptance criterion the plan missed) and treats it as must-fix work, even with no open review — the way to patch a PR after the pipeline has already run.

Extends an already-open, in-review PR with a new feature described in free text — grounds itself in the repo and the PR's branch, writes a short plan, implements it, and pushes to that same branch with a summary comment. For new functionality; use pr-reworker for review feedback.

Posts the handover comment on the story once the PR exists — what changed and why, the technical decisions and their reasoning, the modules and components affected, API and database changes, the limitations and technical debt deliberately taken on, and links to the PR and any documentation, Figma, or ADR the story or repo actually references. Runs after any rework — so it describes the PR as it ends up — and before the testing notes, in both pipelines.

Posts a machine-executable plan for an automated tester and a manual QA checklist for a human tester — the pipeline's last stage, run after any rework and regardless of the review verdict.

Generates frontend end-to-end tests for the changes in a PR, stands the app up, and actually runs them with @playwright/test in a dedicated ECS task with Chromium. Specs are generated and run ephemerally — never committed — and the result comes back as a pass/fail comment on the PR. Standalone for now, not wired into the main pipeline by default.

Runs smoke tests against a deployed environment — health, auth, core journeys, integrations — and reports pass/fail.

Regression review of a whole release branch against main before it ships — conflicts between stories on the same release, contracts broken across story boundaries, work the release is missing from main, and undocumented deploy steps. Raises one Jira story, titled with the release name, listing the changes required before ship; creates nothing when the release is clean.

Fixes versions, assigns merged PRs to issues, transitions them to ready-for-release, and drafts grouped release notes.

Generates or updates Confluence docs from a PR, story, or full codebase scan.

The reviewer's verdict decides the branch. Approved → merge, release & docs. Changes requested → pr-reworker applies the fixes and hands the PR back to the reviewer. The cycle repeats until the PR is approved. A pending verdict pauses the run for a human decision.

Every stage can emit learnings and client-context updates that are written back to agent-brain and the client's context file. The next run's planner and creator retrieve that history through the context RAG — so the platform gets sharper with each story it ships.

For when a PR is already open (or merged) and something was missed — e.g. the code-planner plan skipped an acceptance criterion — re-invoke pr-reworker directly against the PR with free-text guidance. It treats the guidance as must-fix work on its own, no CHANGES_REQUESTED review required. From the CLI: run-pipeline.py --start-from rework --pr-number N --guidance "…" skips straight to this stage.