Agentic Automation — A Pytest Framework with Claude Code

In this section you learn to create your own Claude Code subagents and orchestrate them into a real engineering loop: one agent builds a production-grade Jira API client, another reviews it, and the review findings feed back into improving the agents themselves. You practice this against a live Jira instance and under enforced git guardrails.

Create the first agent of the framework as part of the building blocks,

A bash and Python automation engineer with Bash, Edit, Read, and Write — the agent that actually produces and fixes code.

The real work is building jira_client.py — one deliverable that dogfoods both agents, in sequence.

For more detail, check the SECTION.md file.

In this section you turn the agents from the previous section into a self-driving delivery pipeline. You package repeatable actions as Claude Code skills — committing, opening pull requests, driving a browser — and wire them into the agents so that one agent builds and commits its own work, another reviews it, and the reviewer itself opens the pull request once the change is approved. You practice this under the same enforced git guardrails, and you learn the hard way why a title is best written by whoever just read the diff.

At its core, a skill is a folder containing a SKILL.md file — instructions, metadata, and optionally a script or two — that Claude loads automatically the moment a task matches its description.

How the Magic Works ? One Agent, Two Playwright Stacks

A skill that stages, writes a conventional-commit message, and pushes — through an allow-listed script, within the git guardrails.

Opens a GitHub PR for the current branch — branch protection, base detection, push & duplicate checks, and an auto-generated summary body.

Creating a jira client script will be our dogfooding test for this section.

Turning the “only the reviewer opens the PR” convention into something the harness actually enforces — and proving it's safe before the whole team gets it.

For more detail, check the SECTION.md file.

Why plan mode is the smarter default: thinking before touching code is far cheaper than fixing wrong turns after the fact. A plan is a few thousand tokens you can read, correct, and approve before anything changes; skipping it means paying for mistakes in the expensive currency — failed edits, extra review rounds, churned commits, and rework. Plan mode makes the cheap step (deciding what and how) happen first, and keeps it strictly read-only so the repo can't be mutated until the approach is agreed.

You could reach for a built-in general-purpose or Explore agent to plan — neither is a planner agent,  seeing why is the whole argument for a purpose-built one.

Create the new plan-mode agent

Running the new plan-mode agent for the first time and checking the diff with the same plan that was made by the main agent.

This is the last video of dogfooding the Jira skill plan after filtering all the issues from all 3 plans

This is the creation of the Jira skill and running the code reviewer on the new skill

Using the ticket AG-1 we will check that both agents: the builder and the code reviewer can update the ticket status by using the new Jira skill.

For more detail, check the SECTION.md file.

Why a dedicated automation agent: "write some tests" is deceptively open-ended. Done well it means parsing every discrete assertion out of a user story, discovering real locators on a live page, avoiding flaky patterns, matching the existing suite's conventions, and actually running the result. Baking that expertise into a single, reusable agent — with the right skills wired in — means every future "turn this AC into tests" request follows the same disciplined path instead of being improvised in the main loop.

Automation: A Purpose-Built Test-Writing Agent

For more detail, check the SECTION.md file.

Why a planning step before authoring: "write the tests for this story" hides two different jobs — deciding what suites to build and how to split them for parallel work, then actually writing each one. Fusing them produces duplicated coverage, suites that collide on the same files, and no visible plan to correct before the expensive authoring starts. Splitting planning from authoring makes the cheap step (strategy) happen first, as reviewable Jira work items, so the fan-out is dispatch-ready and the board shows exactly where every story sits.

Grounds a plan in the live app, applies a graduated build ability gate per acceptance criterion, and hands back a dispatch-ready set of Jira sub-tasks.

Dogfooding: AG-3, Guest Shopping

For more detail, check the SECTION.md file.

This section adds the last agent and, with it, draws the line the whole framework rests on: where agentic work ends and mechanical work begins. The agent is the test-runner — a run-and-report specialist that executes each reviewed suite and reports the verdict. Its mechanical counterpart is prepare_worktree.sh, a deterministic script that gives each suite its own isolated, venv-warm worktree — kept deliberately out of an agent's hands, because provisioning is rote, repeatable work a model would only run slower and at the cost of its own context

The Problem: Running multiple Claude instances in a single directory leads to "context pollution" where agents overwrite each other's uncommitted changes

Build the mechanical foundation once and the entire agent roster stands on it — every specialist the framework adds inherits the same clean, warmed environment for free.

Checks the env, runs once, interprets the result correctly, and reports a sanitized verdict — nothing more.

Dogfooding: The Full Six-Step Run : Not just three new files — the whole parallel pipeline, run end to end against AG-3 with its two suites.

Provisioning & Report Routing: Same worktree, same test file, two agents — and nothing collided. That's what AGENT_TYPE routing actually buys you, not just in theory.Each agent runs a different scope of the same suite, so the reports genuinely differ, not just their filenames.

For more detail, check the SECTION.md file.

This section handles what happens when it doesn't. A test can fail for two very different reasons — the test is wrong (a bad selector, a missing wait, stale data) or the app is wrong (a genuine product defect the test correctly caught) — and those demand opposite responses

A disciplined diagnose → fix → re-run loop, autonomous within a hard ceiling — the fix attempt itself is the classifier.

Every automation-writer was dispatched blind — no hint which suites were defect-bait. Clean-vs-surfaced had to emerge from each writer's own protocol.

Every section added one piece — authoring subagents, sanctioned skills, planning before doing, writing and fanning out tests, drawing the line between agentic and mechanical work — and this part closed the loop: telling a real defect from a flaky test, automatically. The agentic framework is complete.

For more detail, check the SECTION.md file.