AutoGineer
Generated banner for Build Agent
Generated logo for Build Agent

Build Agent

AnthropicOfficialPublished by Anthropic

  • Skill
  • Meta (authoring, orchestration, planning, memory)
  • Agent tooling
  • Apache-2.0
  • No issues found
Download ZIP

From the author

Turns a task the owner keeps doing by hand into a named, reusable skill they can trigger by name or put on a schedule. Watches them do it once or listens to them describe it, works out what varies and what stays fixed, writes the skill with approval checkpoints in the right places, registers it with the router, and shares it with the team. This is how a business gets a workflow nobody shipped for them. Use this whenever the owner describes something repetitive they wish were automatic — including phrasings like "I do this every week," "can you remember how to do this," "make this a thing I can just ask for," "build me an agent," "automate this for me," "turn this into a workflow," or "I want this to happen every Monday." Reach for it when they describe a routine, even without asking for automation.
— the description by Anthropic

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Build Agent is a meta-skill designed to capture and formalize an owner's manual workflows into structured, executable agent skills. It guides the process of observing a task, identifying variable versus fixed components, implementing necessary approval gates for safety, and registering the resulting skill for future use or scheduling. By focusing on the owner's specific terminology and validating results against known outcomes, it ensures the generated automation is both trustworthy and practical for team-wide adoption.

What it does

  • Observes and extracts task specifications from live conversations or detailed descriptions.
  • Distinguishes between fixed process steps and variable inputs like dates or amounts.
  • Identifies and inserts approval gates for consequential or ambiguous actions.
  • Generates standardized skill documentation including frontmatter and procedural steps.
  • Validates the new skill against known-good results before deployment.
  • Registers the skill for manual triggering or automated scheduling.

When to use it

  • When an owner describes a repetitive task they perform manually.
  • When a user asks to automate a routine or build a custom agent.
  • When a user expresses a desire for a task to occur on a recurring schedule.
  • When you need to convert a one-off manual process into a reliable, reusable workflow.

Advantages

  • Reduces manual effort by automating recurring business routines.
  • Ensures safety through mandatory approval gates for sensitive actions.
  • Maintains user trust by using the owner's specific terminology.
  • Enables team-wide collaboration by sharing formalized, tested skills.
  • Prevents over-automation by balancing manual oversight with execution.

Usage examples

“I do this every Monday, can you build me an agent to handle my commission reconciliation?”
The agent will analyze your current process, identify the fixed steps and judgment points, and draft a reusable skill for commission reconciliation.
“I want this to happen every week without me, can you turn this into a workflow?”
The agent will capture the steps of your current task, build a formal skill, and set up a recurring schedule for it to run automatically.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/anthropics/build-agent/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip build-agent.zip -d .agents/skills

Documentation by Anthropic

Build Agent

Turn something the owner does every week into something they ask for by name.

This is what keeps the plugin from having to ship every industry's workflow. No catalog can cover a septic contractor's permit routine or an insurance agency's carrier commission reconciliation. Those owners can build them.

Step 1 — Watch it happen, or hear it described

Two starting points, and the first is much better.

Best: they just did it in this conversation. If the owner has walked through the task with you — pulled the files, made the decisions, corrected you twice — that transcript is the specification. Extract it rather than re-interviewing them. The corrections they made are the most valuable part, because they encode judgment the owner would never have thought to state.

Otherwise: they describe it. Ask them to walk through the last time they did it, concretely. Real specifics beat an abstract description every time — "last Tuesday I pulled the carrier file, matched it against what we'd booked, and chased six discrepancies" tells you more than "I reconcile commissions."

Read reference/capture.md for how to get a complete picture without an interrogation.

Step 2 — Separate what varies from what stays fixed

This is the whole craft of the step. A skill that hardcodes last Tuesday's specifics only works on last Tuesday.

For each part of the task, decide:

  • Fixed — the sequence, the sources, the output format, the rules

  • Varies — dates, names, amounts, which file, which customer

  • Judgment — the parts where the owner decides, which become approval gates

The corrections the owner made while walking through it usually mark the judgment points. When someone says "no, not that one — we skip anything under USD 50," that is a rule. When they say "hmm, depends," that is an approval gate.

Step 3 — Find the approval gates

Every step that sends, spends, publishes, or deletes needs a gate. So does every step where the owner hesitated.

Do not gate everything — a skill that asks permission nine times is worse than doing it by hand. Gate the consequential and the ambiguous, and let the rest run.

Read reference/skill_authoring.md for where gates belong and how to phrase them.

Step 4 — Write it

Produce a real skill in the same shape as everything else in this plugin: a SKILL.md with frontmatter and numbered steps, plus a reference/ folder if the detail warrants it.

Requirements it must meet, same as every shipped skill:

  • Name and folder match, lowercase with hyphens

  • Description says what it does and when to trigger, in third person

  • A real fallback for when a connector is missing

  • Approval gates on anything consequential

  • Never invents a number; missing data is reported as missing

Write it in the owner's terms, not in generic business language. If they call it "the carrier file," the skill says carrier file. A skill full of unfamiliar vocabulary is one they will not trust to run unattended.

Step 5 — Test it on a real case, before they rely on it

Run the new skill against a case the owner already knows the answer to — ideally the exact one they walked through. Show the output next to what they got by hand.

This is the step that determines whether the skill gets used. An owner who has seen it reproduce a known-good result will schedule it. One who hasn't will run it manually and check it every time, which saves nothing.

If it doesn't match, fix the skill and run it again. Do not ask the owner to accept a near-miss.

Step 6 — Register and set the cadence

Add it to smb-router so plain-English requests reach it, and record the trigger phrases the owner actually uses.

If it is a recurring task, offer to schedule it. Scheduling is what converts "a skill I could run" into "something that happens without me," which is the outcome they wanted.

Step 7 — Share it, with approval

Offer to share with the team. Say what sharing means: who gets it, what data it can reach, and what it can do unattended.

Be specific about the risk when a skill sends, spends, or writes. A skill that emails customers, running for someone who did not build it and does not know its assumptions, is a real hazard. Recommend draft-only for shared skills that send anything.

What not to do

  • Do not re-interview about a task they just walked through. The transcript is the spec.

  • Do not hardcode the example. Names, dates, and amounts vary; the sequence does not.

  • Do not gate every step. Nine approvals is worse than doing it by hand.

  • Do not skip the test run. An untested skill gets checked manually forever, which saves nothing.

  • Do not write it in generic business language. Their words, or they won't trust it.

  • Do not build something that sends or spends without approval gates. Ever, regardless of what the owner asks for.

After the build

The owner now has a named skill they can trigger or schedule. If the new skill hit a tool that isn't connected, "connect to my ERP" (build-connector) is the natural next step — it turns the missing system into a working source. Also nearby: "brief me" to fold the new output into the daily picture, and "Monday brief" if the skill should feed the weekly one. Offer at most three, and skip any offer the owner already declined this session.

Reference files

  • reference/capture.md — getting a complete picture of the task without an interrogation

  • reference/skill_authoring.md — the structure, frontmatter, and where approval gates belong

  • reference/gotchas.md — the failure modes that produce a skill nobody uses

Files

reference/skill_authoring.md

Skill Authoring

The structure a built skill has to follow to work like everything else in this plugin.

Shape

skills/<name>/
  SKILL.md              required — frontmatter plus numbered steps
  reference/            optional — detail that loads on demand
    <topic>.md

No tests/ directory. This plugin doesn't use them, and a link to one that doesn't exist is a broken reference.

Frontmatter

---
name: <matches the folder exactly — lowercase, hyphens, no underscores>
description: >
  <What it does, then when to trigger it. Third person. One paragraph.>
allowed-tools: Read, WebFetch
---

allowed-tools pre-approves tools; it does not grant new ones. Declare only what the skill's steps use — Read, WebFetch covers a skill that reads files and fetches pages. Never add Bash to a skill that does not run a shell command.

Only these fields are safe: name, description, allowed-tools, license, metadata, compatibility, version. Anything else risks the parser rejecting it.

Two patterns break Cowork's YAML parser. Avoid both:

  • A description containing both square brackets and pipes. Write usage in prose instead.

  • A bold-wrapped placeholder — double asterisks around a square-bracketed word — especially inside a fenced code block. Use plain angle brackets for placeholders instead.

The description is the trigger

This is the only thing that decides whether the skill fires. Getting it right matters more than anything in the body.

It needs both halves:

  • What it does — concrete, third person

  • When to trigger — the actual phrases the owner uses

Use the owner's real words. If they say "the carrier file," the description says carrier file. Generic phrasing means the skill sits there unused while the owner does the task by hand.

Lean toward over-triggering. A skill that fires when it wasn't needed costs one sentence. A skill that stays silent when it was needed costs the owner their afternoon, and they conclude the whole thing doesn't work.

Bad:  Reconciles commission data.

Good: Matches the monthly carrier commission file against what's booked in
      the CRM, flags anything off by more than USD 5, and drafts a chase email
      per carrier. Use whenever the owner mentions commissions, the carrier
      file, reconciling what they're owed, or says the monthly statement
      came in.

Body structure

Numbered steps, matching the rest of the plugin:

# <Skill Name>

<One or two lines on what this is for and why it matters.>

## Step 1 — <verb phrase>

<What to do. Explain why where the reason isn't obvious.>

## Step 2 — <verb phrase>

...

## What not to do

- **<The mistake>** — <why it matters>

## Reference files

- `reference/<file>.md` — <what's in it and when to read it>

Under about 125 lines. Detail goes into reference/, which loads only when needed.

Explain the reasoning. A skill that says "always check X" gets followed literally and breaks on the edge case. One that says "check X, because Y happens otherwise" gets handled sensibly when the situation is slightly different.

Where approval gates belong

Gate anything that:

  • Sends — email, message, invoice, anything a third party sees

  • Spends — orders, payments, ad budget

  • Publishes — posts, listings, public content

  • Deletes or overwrites — anything not recoverable

  • Commits — dates, prices, scope

Do not gate reading, computing, drafting, or internal file creation.

A gate states what will happen before asking:

Good: 6 chase emails, one per carrier, totaling USD 2,340 in discrepancies,
      from your address. Send them?

Bad:  Ready to proceed?

The bad version asks the owner to approve something they can't see. That is not consent, it is a rubber stamp, and the first time it goes wrong they stop trusting every gate in the plugin.

Three to five gates in a skill is healthy. Nine means it is worse than doing the task by hand.

The fallback is mandatory

Every skill works with zero connectors. This is a hard design requirement, not a nice-to-have — this audience has too much tool sprawl for anything else.

The fallback is usually one of:

  • Upload a CSV or XLSX

  • Paste the text

  • Forward the email

  • Web research

  • Produce files for the owner to send manually

State it plainly rather than apologetically:

No connector for your carrier portal. Forward me the monthly statement email
and I'll do the rest — same output, one extra step for you.

Rules every built skill inherits

Never invent a number. Missing data is reported as missing, by name. Owners forward these outputs to banks and accountants.

Write in the owner's vocabulary. Not accounting or marketing register.

One preferred path, plus an escape hatch. Do not offer three options.

Name the specific record. "Some discrepancies" is unusable. "USD 412 on the Continental file, line 34" is actionable.

Match the owner's voice when drafting for them. If the built skill drafts anything in the owner's name — email, post, reply, letter — its draft step must read the shared voice profile first, written from a SKILL.md as the two-levels-up path to shared/voice-profile.md. Add the new skill to that file's reader table so a correction the owner makes once holds everywhere.

Registering it

Add the skill to smb-router's routing table with the trigger phrases the owner actually uses, and any connector it requires. The router refuses to route to a skill whose required connector isn't connected, so that field matters.

Then offer a schedule if it recurs. Scheduling is what turns "a skill I could run" into "something that happens without me."

Requirements and compatibility

Written for: Claude Code, Claude apps

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Anthropic
Publisher
Anthropic (Official)
Source
anthropics/knowledge-work-plugins · small-business/skills/build-agent · commit e050c2e
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Anthropic or Anthropic.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download build-agent.zip