Context-engineering

A seven-stage skill pipeline for Claude Code that takes a Jira ticket in a codebase you don't know yet and gets it to a pushed branch with small, reviewable commits: intake, decide, spec, slice, build, review, ship, with four human gates and one untracked notes folder per ticket. It is assembled from what Matt Pocock, Addy Osmani, GitHub Spec Kit, obra/superpowers, Dex Horthy and Anthropic actually ship and teach, then stress-tested by four research agents — controlled productivity studies (METR, Stanford, DORA, Ambig-SWE), critics of spec-driven workflows, ten more YouTube transcripts and a hands-on technical audit that ran every git command in a throwaway repo. The verdict: the core loop holds and being asked clarifying questions has the strongest evidence, but it fails if you run the full process on every ticket, so tickets are right-sized into XS/S/M/L tracks. Slices become one commit each on the branch, the platform squash-merges the PR into one commit per ticket on main, and the full kit — eight SKILL.md files, two bundled curl scripts, two hooks, settings and a setup script — is included, ready to copy into ~/.claude/.

Running Claude Code as an autonomous agent inside a GitHub-centric SDLC rests on one discipline: GitHub is the system of record, the agent's conversation is ephemeral, and everything that must survive across pull requests lives in repo files or GitHub itself. This post walks the full issue-to-merge loop — trigger modes, the Explore→Plan→Implement→Commit cycle, cross-session context persistence via CLAUDE.md, the four distinct automated-review surfaces, and the merge gates that keep an agent that literally cannot self-approve from ever merging by fiat. It is built from a fact-checked research pass (25 claims verified, 0 refuted, overwhelmingly first-party Anthropic sources) and is deliberate about separating verified mechanics from the viral stats that did not survive verification.

For two years, getting useful work out of a coding agent meant being the loop yourself — prompt, read, prompt again. As models hold a hard problem for hours, the bottleneck moves: not 'can it write good code' but 'can it keep making progress on its own without losing the thread or declaring victory early.' Loop engineering is the discipline that answers that — you design the system that prompts the agent: discover work, attempt, get a feedback signal, self-correct, verify in a separate context, persist state on disk, decide what's next. This post lays out the architecture, the five building blocks, a worked worker/verifier loop in Python, the loops worth building first, the best practices, and an honest look at the risks (the 'confident token furnace'), with every flow rendered as a diagram.

Traditional RAG is a one-shot pipeline: embed the query, fetch top-k, stuff into a prompt. Agentic RAG turns retrieval into a loop the model drives — decompose, search, read, prune, search again. The shape of that loop creates a new failure mode (context window bloat across turns) and a new cost lever (a specialist 20B subagent can match frontier LLMs on multi-hop benchmarks at up to 10x lower latency). This post walks the contrast between traditional and agentic RAG, explains why a learned `prune_chunks` tool is the missing piece, and uses Chroma's Context-1 research as the worked example showing how a LoRA-tuned gpt-oss-20b with a 16:1 recall-biased CISPO reward beats GPT-5.4, Claude Opus 4.6, and Gemini 3.1 Pro on BrowseComp-Plus and HotpotQA.