Stop writing prompts: why AI coding agents need a workflow

Three tasks, each moving through developer, reviewer and wiki curator steps; the next step waits for a click on Start.

Every session starts from a blank page

If you use Claude Code or a similar agent every day, you know this moment. You open a new session, and before the agent does anything useful, you have to decide:

  • What do I write in the prompt?
  • Which parts of the task, the docs and the codebase does it need to see?
  • Which skills or rules should it follow?
  • Should it ask me questions first, or just start coding?
  • What do I check when it is done: tests, review, docs?

None of these questions is hard. But you answer them again for every task, from memory, slightly differently each time. On Monday you remember "run the tests and update the docs". On Thursday you forget.

A concrete before and after

Take one ordinary task: "Add a 'keep me signed in' option to the login form."

Without a workflow, you open a session and type something like: "Here is the task. Look at the auth module. Ask me if anything is unclear. Write tests. Don't forget our coding rules in RULES.md." You read the diff yourself, ask for fixes, write the PR description, maybe remember the docs. The next task gets a different, improvised version of the same routine.

With a workflow, those decisions already exist as a template. The task moves into the Implementation status, and that status has a fixed pipeline of agents:

# .crux/workflow.yaml (trimmed)
IMPLEMENTATION:
  role: developer
  pipeline:
    - developer      # writes the code and tests, opens the PR
    - reviewer       # reviews the PR against the repo's rules, then fixes
    - wiki_curator   # updates the project docs to match the change

Each agent is a small folder with its own system prompt and its own skills. The developer agent, for example, always works in the task's own git worktree, agrees the approach with you before coding, keeps the tests green, and finishes with a change-summary skill that records exactly what the diff contains. You don't write any of that in a prompt. You start the step, and the agent fetches its own instructions.

Statuses, roles, agents, skills

The idea is simple. Your tracker already has statuses. A workflow adds three things to each of them:

  1. A role that owns the status: developer, QA, designer, project manager.
  2. Agents for that role, each with a system prompt. Some run as ordered steps on a task, others are chat helpers ("what should I pick up next?").
  3. Skills: written methods the agent follows. A technical-interview skill asks one question at a time, each tied to a line in the task. A review skill checks architecture, duplication, workarounds, bugs and type safety, citing the rule behind every finding.

You plan the work once, as templates, instead of improvising it in every session.

Artifacts instead of long chat history

Agents don't pass work to each other through chat history. Each step leaves one artifact on the task: a tech-qa after the technical interview, a change-summary after coding, a review report after review, a wiki update after the docs step. The next agent reads the task and its artifacts, not someone else's chat history.

So an agent takes its context from two places: the task tracker (the task and its artifacts) and the project wiki, which describes how the system works today. You don't paste background into a prompt; it is already where the agent looks. We wrote about the wiki side separately: Our project wiki: memory that AI agents can read and write.

Every session starts with a short, clean context, and the task becomes a readable record: a teammate can open it a month later and see what was decided, what changed and what the review found.

The human approves, the agent drafts

A workflow does not mean "let the agents run unattended". In our templates people check in at a few checkpoints: when the agent has understood the task, when it has a plan, and when it shows the result. At each one the agent drafts the artifact in chat, you correct it, and it posts only after an explicit "ok". Silence is not approval. Agents also don't move tasks between statuses; a person does that.

So your job changes: you stop writing prompts and start reviewing proposals. Is this the right approach? Is this summary true to the diff? Is this finding real?

Parallel sessions, one per task and role

Once every step is a template, starting one needs almost no thought, so you can run many at once.

In our public Claude Code plugin, crux-dispatch shows a role's board, lets you pick several tasks and claims each pick. In Claude Code desktop it then prepares one session card per pick. Nothing starts by itself: each session begins only when you click its card, one click per session. Every session moves into its task's own git worktree (crux-worktree), so parallel agents never touch the same files. When the developer step finishes, it prepares the reviewer's card for the same task, and again you start it with a click.

The result is a "wave": a batch of independent tasks moving through the same pipeline side by side, each in its own session and worktree, each held to the same template.

What it looks like on a real project

We build CRUX itself with this workflow, so the numbers below are from this one project. In about six months it has gone through over a thousand tasks, and on a busy day dozens of pull requests merge.

That count is not agent sprawl. Every task came from a plan a person agreed, was broken down on purpose and went through the same checkpoints. The workflow itself was iterated too: while the idea was taking shape we tried several different approaches, reshuffled the roles and reworked how skills reach the agents. The workflow file is now on its fifth version.

The commit history shows the rhythm: code from the developer, a commit with the reviewer's plan and findings, the fixes, the docs update, task after task. The main gain is consistency: the hundredth task gets the same interview, review and docs step as the first.

Try it

The CRUX plugin for Claude Code is public: github.com/cruxteam/skills. It has four skills: crux-dispatch (pick tasks from a role's board and open a session for each), crux-run (start one pipeline step on one task), crux-worktree (move the work into the task's own git worktree) and crux-retro (a retrospective over a sprint or a date range). Install it in Claude Code with:

claude plugin marketplace add cruxteam/skills
claude plugin install crux@cruxteam

It also installs in Codex, GitHub Copilot and Gemini CLI, and talks to your CRUX project through its MCP server (see the README).

Even without CRUX, try the idea: write down, once, what each status of your board needs from an agent.

All articles