Skills, Hooks, and Subagents: Assembling Your First Agent Loop in Claude Code

The most powerful features in Claude Code are the three most people never turn on. Hooks, skills, and subagents have been sitting in the docs for months, and the builders who wired them together are running agent loops that ship real work while the rest of us are still typing prompts one at a time.

That gap is the story of loop engineering, the term that took over the AI building conversation this summer after Boris Cherny, who leads Claude Code at Anthropic, told an audience he does not prompt Claude anymore: "I have loops running that prompt Claude and figuring out what to do." The idea landed because it is true. The way to get more out of a coding agent is not a better prompt. It is a better loop. And the raw material for that loop, if you are working in Claude Code, is exactly these three primitives. The hypothesis for this post is simple: hooks, skills, and subagents are the parts you assemble into a reliable agent loop, and learning what each one does is the fastest way to stop babysitting your agent. But all three control how the loop runs, and none of them define what done means, which is the one input the loop cannot generate for itself.

#Hooks: the rules that fire whether or not the agent remembers

Start with hooks, because they are the most underused and the easiest to misunderstand.

A hook is a shell command, HTTP endpoint, or prompt that Claude Code runs automatically at a specific point in its lifecycle: before it edits a file, after it finishes a task, right before it runs a shell command. You configure it once, and it fires every time that moment arrives, no matter what the agent is "thinking." That last part is the whole point. If you put "run the formatter after every edit" in your instructions, the agent will do it most of the time and forget it some of the time, because instructions are suggestions a model weighs against everything else in its context. A hook is not a suggestion. It is a guarantee.

The community figured this out fast. One of the most-shared explainers on the topic called hooks "the permission system for AI agents", and that framing is exactly right. The reason you reach for a hook instead of a line in your CLAUDE.md is determinism. You want the linter to run every single time, the secret-scanner to block a commit every single time, the test suite to fire before the agent declares victory every single time. Model behavior is probabilistic. A hook is not.

Here is the concrete difference. Tell the agent in prose to "always run pnpm test before finishing," and on a long, messy task it will sometimes skip it, announce the feature is done, and hand you a broken build. Wire a Stop hook that runs the tests and blocks completion on failure, and it cannot skip it, because the skip is no longer the model's decision. Same agent, same model. The only variable is whether the check was a request or a rule.

#Skills: the expertise the agent loads only when it needs it

Skills solve the opposite problem. Hooks are always-on guarantees. Skills are on-demand knowledge.

A skill is a folder with a Markdown file that teaches the agent how to do one specific thing: how your team writes migrations, how to generate a PDF invoice, how to review a component against your design system. It sits dormant until the agent hits a situation the skill describes, and only then does it load into context. This is the fix for the failure mode we wrote about in context rot: the more you stuff into the agent's context up front, the worse it performs on the task in front of it. Skills let you keep deep, specialized expertise available without paying for it on every turn. The knowledge is there when the job needs it and out of the way when it does not.

The trade-off is real, and worth naming. A skill only fires if the agent recognizes that the moment has arrived, so a skill with a vague description will sit unused while the agent improvises badly. The skill is only as good as its trigger. Write the description as if you are telling a new hire exactly when to reach for this playbook, or it will gather dust.

#Subagents: the fresh context that keeps the main thread clean

The third primitive is the one that makes the loop scale.

A subagent is a separate instance of the agent with its own context window, spun up to handle a delegated piece of work. The main session hands it a task, the subagent does all its exploring, file-reading, and dead-end reasoning inside its own window, and only the result comes back. The messy middle never touches your main thread. This matters because a single long agent session degrades as its context fills with the debris of everything it has already tried. Subagents are how you run a big job without letting the exploration for step three poison the agent's judgment on step seven.

In practice this is what lets a loop take on real scope. A "reviewer" subagent checks the work a "builder" subagent produced, each in a clean window, the way you would split the maker from the checker on a real team. The main loop orchestrates; the subagents do the isolated work and report back. That separation is why builders describe subagents as the feature that took their Claude Code setup from a clever assistant to something that actually holds together across a multi-step task.

#Assembling the loop

Put the three together and the loop stops being a metaphor and becomes a machine you can point at a goal.

Loading diagram...

Skills supply the how-to at the moment it is needed. Subagents do the isolated work without clogging the main thread. Hooks fire the non-negotiable checks that the model is not allowed to skip. Wrap that in a loop that pulls the next task and repeats, and you have the thing Cherny described: a system that prompts the agent so you do not have to. This is loop engineering at the level a working builder can actually reach today, not a research demo.

And this is genuinely a step up. Scheduled, self-checking agent runs are real, they ship in Claude Code right now, and assembling these primitives will get you further than any amount of prompt-tuning. If you build with Claude Code, the practical implication is direct: your next hour is better spent wiring one hook and one subagent than polishing another prompt, because the prompt is a one-time gain and the loop compounds.

#The reframe: the loop runs the work, but it cannot decide what "done" means

Here is the part the loop tweets leave out, and it is the part that matters most.

Every one of these three primitives controls how the loop runs. A hook decides when a check fires. A skill decides how a task is performed. A subagent decides where the work happens. None of them decides what you are building or how you will know it is right. Your Stop hook can run the test suite on every pass, but something has to have written the tests, and something has to have decided that passing them actually means the feature does what you intended. That "something" is not a hook, a skill, or a subagent. It is a plan with acceptance criteria, and the loop cannot generate it for itself.

A vibe coder in a recent Reddit thread rebuilt this idea from scratch without any of the vocabulary, and said it better than most docs: "You have to define 'done' for your application, plan all the work it takes to get there... requirements, acceptance tests, code. If you want deterministic results, you need deterministic verification." That is the whole game. A loop only holds together at scale when there is a fixed standard it is checking each pass against. Without one, the reviewer subagent has nothing to review against, the Stop hook is checking that the code runs rather than that it is correct, and every pass of the loop can quietly drift a little further from what you actually wanted. The loop runs beautifully and ships the wrong thing.

This is exactly the gap BrainGrid is built to close. BrainGrid is the plan-first app-building platform, and it runs the same loop, Plan then Build then Verify then Repeat, but it owns the two pieces the Claude Code primitives cannot generate: the plan and the standard. You describe the feature, and the Planning Agent turns it into a requirement with explicit acceptance criteria, the definition of done your loop's checks measure against. The Builder Agent then builds it, either in the BrainGrid Cloud sandbox or in your own GitHub repo through Claude Code, Cursor, or Codex over MCP, so your hooks and subagents keep doing what they are good at while the loop finally has a target. Verification checks the build against every criterion, and the feature is not done until the evidence says it matches intent. The primitives make the loop run. The plan is what makes the loop worth running.

#FAQ

#What are Claude Code hooks?

Claude Code hooks are shell commands, HTTP endpoints, or prompts that run automatically at specific points in the agent's lifecycle, such as before it edits a file, before it runs a shell command, or when a task finishes. Because they fire deterministically rather than depending on the model to remember an instruction, they are used to enforce guarantees like running a formatter after every edit, blocking a risky command, or running the test suite before the agent can declare a task complete. They are the closest thing Claude Code has to a permission and automation system, and they are configured once in your settings rather than requested on each prompt.

#What is the difference between hooks, skills, and subagents in Claude Code?

The three solve different problems. Hooks are always-on rules that fire automatically at set moments and cannot be skipped by the model, so they are for guarantees like tests and linting. Skills are on-demand knowledge, folders of instructions the agent loads only when it recognizes the relevant situation, so they are for specialized expertise you do not want in context all the time. Subagents are separate agent instances with their own context windows that handle a delegated task and return only the result, so they are for isolating messy work and keeping the main session clean. Hooks control when checks run, skills control how a task is done, and subagents control where the work happens.

#Do I need to use hooks, skills, and subagents to build with Claude Code?

No, you can build productively with Claude Code using plain prompts, and many people do. These three features matter when you want to move from prompting one step at a time to running a more autonomous loop that ships multi-step work with less babysitting. Hooks give you deterministic checks, skills give you reusable expertise, and subagents let a bigger job run without degrading the main context. If your agent keeps skipping steps you told it to take, forgetting your conventions, or losing the thread on long tasks, those are the signals that assembling these primitives will pay off.

#What is loop engineering?

Loop engineering is the practice of designing a system that prompts and orchestrates an AI coding agent automatically, instead of prompting it by hand one step at a time. The term spread after Boris Cherny, who leads Claude Code at Anthropic, said he no longer prompts Claude directly but writes loops that prompt Claude for him. In Claude Code, the building blocks of such a loop are hooks, skills, and subagents. The catch is that a loop only produces reliable results when it has a fixed standard to check each pass against, which means requirements and acceptance criteria the loop verifies the work against, not just automation that keeps it running.

#Can a Claude Code loop verify that a feature is actually correct?

Only partly, and this is the key limitation. Hooks can run your tests and subagents can review the work, but that only verifies what the tests and the reviewer were told to check for. Something still has to define what "done" means for the feature, write the acceptance criteria, and decide that passing the checks actually equals doing what you intended. That definition is a plan, and the loop's primitives cannot generate it for themselves. This is why builders pair an agent loop with an explicit requirement and acceptance criteria: the loop runs the work, but the plan is what tells it, and you, that the result is right.

BrainGrid is the plan-first app-building platform that turns your idea into a requirement with acceptance criteria, so your Claude Code loop finally has a definition of done to build and verify against. Try it at braingrid.ai.