Run client tickets end to end with one skill playing PM, dev and QA

Anton Lytvynov's agency ran 1,213 Claude Code runs on 764 client tasks from May to October with one 764-line skill, while its IT team shrank from 20 people to 9.

Done withClaude Code· Nov 4, 2026

What they did

Lytvynov runs a software agency with its own task board. A small Node.js runner watches the board, and when a task is assigned to the agent's account it starts Claude Code with one command file and the task code. That file makes the agent play three roles in one run. As PM it reads the task tree and writes acceptance criteria if none exist. As Dev it branches every repo the task touches, reads all comments first, writes tests and pushes. As QA it turns each criterion into a test case, walks it in a real browser, runs backend tests and attaches three to five screenshots, sending the task back to Dev up to three times. It then moves the task to a To test column for human testers. Most runs happen overnight.

How it went

Between May and October the file drove 1,213 runs on 764 tasks, and the team went from 20 people to 9. Tasks no longer wait for a person to start each step. Testing became the main human job, with testers starting from the agent's report and screenshots, and developers working the Blocked column. Most of the file grew from failures: the agent once missed requirements written under a Russian 'Requirements' header and invented its own criteria, and moving stuck tasks back to To Do made it pick them up again in a loop.

Worth knowing

Send stuck tasks to a terminal Blocked column, never to the column the runner watches, and tell the agent plainly not to fake a result it cannot reach. The author says 764 lines is a lot of context per run and old rules pile up, and a browser test still misses what the client actually meant. The agent never marks client work as done.

Try it

With Claude Code· 6 parts to fill in

Take ticket [ticket id] in [GitHub Issues, Linear or Jira] from ready to review in one run, playing three roles in order and prefixing every comment with PM, Dev or QA. PM: if the ticket has no testable requirements in any form or language, write numbered acceptance criteria into it, then stop and wait for my OK. Dev: branch feature/[ticket id]-[short name] in every repo it touches, read all comments first, implement and test, never push to [protected branches]. QA: test every criterion in the browser and attach 3 to 5 screenshots; on a bug go back to Dev, at most 3 rounds. Start each report with 3 to 5 plain sentences for a non-technical reader. If you lack access or need a decision, do your code part, write why and a checklist for a human, move the ticket to [Blocked column] and stop.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related