Превращение рутины в автоматизацию

Превращает задачу, которую вы делаете вручную каждую неделю, в именной скилл: вызывается по названию или работает по расписанию.

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Превращает задачу, которую вы делаете вручную каждую неделю, в именной скилл: вызывается по названию или работает по расписанию.
Когда брать: Когда вы повторяете одну и ту же работу и хотите, чтобы она делалась по короткой просьбе или сама по расписанию.
Когда не брать: Если задача разовая и не повторится.
Пример запроса: Я каждую неделю сверяю комиссии со страховыми компаниями. Давай сделаем из этого скилл, который я смогу просто вызывать.
Работает лучше с: коннекторы к вашим рабочим системам

Входит в плагин small-business. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку build-agent в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: build-agent
description: >
  Превращает задачу, которую владелец постоянно делает вручную, в именной
  скилл многократного использования, который можно вызвать по названию или
  поставить на расписание. Наблюдает, как он делает это один раз, или слушает
  его описание, определяет, что меняется, а что остаётся неизменным, пишет
  скилл с контрольными точками согласования в нужных местах, регистрирует его
  в маршрутизаторе и делится им с командой. Так бизнес получает рабочий
  процесс, который для него никто не выпускал. Используй каждый раз, когда
  владелец описывает что-то повторяющееся, что хотел бы сделать
  автоматическим, в том числе фразами «я делаю это каждую неделю», «ты можешь
  запомнить, как это делается», «сделай так, чтобы я мог просто попросить об
  этом», «создай мне агента», «автоматизируй это для меня», «преврати это в
  рабочий процесс» или «я хочу, чтобы это происходило каждый понедельник».
  Применяй, когда он описывает рутину, даже если об автоматизации не просит.
allowed-tools: Read, WebFetch
---

Создание агента

Превращай то, что владелец делает каждую неделю, в то, о чём он просит по названию.

Благодаря этому плагину не приходится поставлять рабочие процессы для каждой отрасли. Никакой каталог не охватит рутину оформления разрешений у подрядчика по септикам или сверку комиссий страховых компаний в страховом агентстве. А эти владельцы могут построить такое сами.

Шаг 1. Посмотри, как это происходит, или выслушай описание

Две точки старта, и первая намного лучше.

Лучше всего: они только что сделали это в этом разговоре. Если владелец прошёл задачу вместе с тобой — достал файлы, принял решения, дважды тебя поправил, — то эта переписка и есть спецификация. Достань её оттуда, а не опрашивай заново. Поправки, которые он вносил, — самая ценная часть, потому что в них закодировано суждение, которое владелец сам никогда бы не подумал сформулировать.

Иначе: они описывают. Попроси их конкретно пройти по последнему разу, когда они это делали. Реальные детали всегда лучше абстрактного описания: «в прошлый вторник я взял файл страховщика, сверил его с тем, что мы оформили, и отработал шесть расхождений» говорит больше, чем «я сверяю комиссии».

Прочитай reference/capture.md: там описано, как получить полную картину без допроса.

Шаг 2. Отдели то, что меняется, от того, что остаётся неизменным

В этом вся суть шага. Скилл, в который жёстко зашиты детали прошлого вторника, работает только в прошлый вторник.

По каждой части задачи реши:

Неизменное — последовательность, источники, формат результата, правила
Меняется — даты, имена, суммы, какой файл, какой клиент
Суждение — места, где решает владелец; они становятся шлагбаумами согласования

Поправки, которые владелец вносил по ходу рассказа, обычно и отмечают точки суждения. Когда человек говорит «нет, не этот — всё, что дешевле 50 USD, мы пропускаем», это правило. Когда он говорит «хм, зависит», это шлагбаум согласования.

Шаг 3. Найди шлагбаумы согласования

Шлагбаум нужен каждому шагу, который отправляет, тратит, публикует или удаляет. И каждому шагу, на котором владелец колебался.

Не ставь шлагбаумы на всё: скилл, который девять раз просит разрешения, хуже, чем делать вручную. Ограничивай значимое и неоднозначное, а остальному дай идти.

Прочитай reference/skill_authoring.md: там описано, где должны стоять шлагбаумы и как их формулировать.

Шаг 4. Напиши скилл

Создай настоящий скилл той же формы, что и всё остальное в этом плагине: SKILL.md с шапкой (frontmatter) и пронумерованными шагами, а также папку reference/, если детали того стоят.

Требования, которые он должен выполнять, как и каждый поставляемый скилл:

Название и папка совпадают, строчные буквы через дефис
Описание говорит, что скилл делает и когда его запускать, от третьего лица
Настоящий запасной вариант на случай, когда коннектора нет
Шлагбаумы согласования на всё значимое
Никогда не выдумывает числа; отсутствующие данные сообщаются как отсутствующие

Пиши на языке владельца, а не на общем деловом. Если они называют это «файл страховщика», то в скилле так и написано. Скиллу, полному незнакомых слов, не доверят работать без присмотра.

Шаг 5. Проверь на реальном случае, прежде чем на него полагаться

Прогони новый скилл на случае, ответ на который владелец уже знает, — лучше всего на том самом, который он проходил. Покажи результат рядом с тем, что у него получилось вручную.

Именно этот шаг определяет, будут ли скиллом пользоваться. Владелец, увидевший, как он воспроизводит заведомо верный результат, поставит его на расписание. Тот, кто не видел, будет запускать его вручную и каждый раз проверять, а это ничего не экономит.

Если не совпало, исправь скилл и запусти снова. Не проси владельца принять почти совпадение.

Шаг 6. Зарегистрируй и задай периодичность

Добавь его в smb-router, чтобы запросы простым языком доходили до него, и запиши фразы-триггеры, которыми владелец действительно пользуется.

Если задача повторяющаяся, предложи поставить её на расписание. Именно расписание превращает «скилл, который я мог бы запустить» в «то, что происходит без меня», а это и есть результат, которого они хотели.

Шаг 7. Поделись, с согласованием

Предложи поделиться с командой. Скажи, что значит поделиться: кто получит, до каких данных скилл дотянется и что сможет делать без присмотра.

Говори о риске прямо, когда скилл отправляет, тратит или пишет. Скилл, который рассылает письма клиентам, запущенный человеком, не создававшим его и не знающим его допущений, — реальная опасность. Рекомендуй для общих скиллов, что-либо отправляющих, режим «только черновики».

Чего не делать

Не опрашивай заново о задаче, которую они только что прошли. Переписка — это и есть спецификация.
Не зашивай пример жёстко. Имена, даты и суммы меняются; последовательность нет.
Не ставь шлагбаум на каждый шаг. Девять согласований хуже, чем делать вручную.
Не пропускай тестовый прогон. Непроверенный скилл вечно проверяют вручную, а это ничего не экономит.
Не пиши на общем деловом языке. Их слова, иначе им не поверят.
Не строй ничего, что отправляет или тратит, без шлагбаумов согласования. Никогда, о чём бы ни просил владелец.

После сборки

У владельца теперь есть именной скилл, который можно вызвать или поставить на расписание. Если новый скилл упёрся в инструмент, который не подключён, естественный следующий шаг — «подключись к моему ERP» (build-connector): он превращает отсутствующую систему в работающий источник. Рядом также: «дай мне сводку», чтобы вплести новый результат в ежедневную картину, и «бриф на понедельник», если скилл должен питать еженедельный. Предлагай не больше трёх и пропускай любое предложение, от которого владелец уже отказался в этой сессии.

Справочные файлы

reference/capture.md — как получить полную картину задачи без допроса
reference/skill_authoring.md — структура, шапка и где должны стоять шлагбаумы согласования
reference/gotchas.md — типичные ошибки, из-за которых получается скилл, которым никто не пользуется

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/small-business/skills/build-agent, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: build-agent
description: >
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.
allowed-tools: Read, WebFetch
---

# 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

Источник: anthropics/knowledge-work-plugins / small-business / build-agent ↗. Ссылка проверена 2026-10-10.

---
name: build-agent
description: >
  Превращает задачу, которую владелец постоянно делает вручную, в именной
  скилл многократного использования, который можно вызвать по названию или
  поставить на расписание. Наблюдает, как он делает это один раз, или слушает
  его описание, определяет, что меняется, а что остаётся неизменным, пишет
  скилл с контрольными точками согласования в нужных местах, регистрирует его
  в маршрутизаторе и делится им с командой. Так бизнес получает рабочий
  процесс, который для него никто не выпускал. Используй каждый раз, когда
  владелец описывает что-то повторяющееся, что хотел бы сделать
  автоматическим, в том числе фразами «я делаю это каждую неделю», «ты можешь
  запомнить, как это делается», «сделай так, чтобы я мог просто попросить об
  этом», «создай мне агента», «автоматизируй это для меня», «преврати это в
  рабочий процесс» или «я хочу, чтобы это происходило каждый понедельник».
  Применяй, когда он описывает рутину, даже если об автоматизации не просит.
allowed-tools: Read, WebFetch
---

# Создание агента

Превращай то, что владелец делает каждую неделю, в то, о чём он просит по названию.

Благодаря этому плагину не приходится поставлять рабочие процессы для каждой отрасли. Никакой каталог не охватит рутину оформления разрешений у подрядчика по септикам или сверку комиссий страховых компаний в страховом агентстве. А эти владельцы могут построить такое сами.

## Шаг 1. Посмотри, как это происходит, или выслушай описание

Две точки старта, и первая намного лучше.

**Лучше всего: они только что сделали это в этом разговоре.** Если владелец прошёл задачу вместе с тобой — достал файлы, принял решения, дважды тебя поправил, — то эта переписка и есть спецификация. Достань её оттуда, а не опрашивай заново. Поправки, которые он вносил, — самая ценная часть, потому что в них закодировано суждение, которое владелец сам никогда бы не подумал сформулировать.

**Иначе: они описывают.** Попроси их конкретно пройти по последнему разу, когда они это делали. Реальные детали всегда лучше абстрактного описания: «в прошлый вторник я взял файл страховщика, сверил его с тем, что мы оформили, и отработал шесть расхождений» говорит больше, чем «я сверяю комиссии».

Прочитай `reference/capture.md`: там описано, как получить полную картину без допроса.

## Шаг 2. Отдели то, что меняется, от того, что остаётся неизменным

В этом вся суть шага. Скилл, в который жёстко зашиты детали прошлого вторника, работает только в прошлый вторник.

По каждой части задачи реши:

- **Неизменное** — последовательность, источники, формат результата, правила
- **Меняется** — даты, имена, суммы, какой файл, какой клиент
- **Суждение** — места, где решает владелец; они становятся шлагбаумами согласования

Поправки, которые владелец вносил по ходу рассказа, обычно и отмечают точки суждения. Когда человек говорит «нет, не этот — всё, что дешевле 50 USD, мы пропускаем», это правило. Когда он говорит «хм, зависит», это шлагбаум согласования.

## Шаг 3. Найди шлагбаумы согласования

Шлагбаум нужен каждому шагу, который отправляет, тратит, публикует или удаляет. И каждому шагу, на котором владелец колебался.

Не ставь шлагбаумы на всё: скилл, который девять раз просит разрешения, хуже, чем делать вручную. Ограничивай значимое и неоднозначное, а остальному дай идти.

Прочитай `reference/skill_authoring.md`: там описано, где должны стоять шлагбаумы и как их формулировать.

## Шаг 4. Напиши скилл

Создай настоящий скилл той же формы, что и всё остальное в этом плагине: `SKILL.md` с шапкой (frontmatter) и пронумерованными шагами, а также папку `reference/`, если детали того стоят.

Требования, которые он должен выполнять, как и каждый поставляемый скилл:

- Название и папка совпадают, строчные буквы через дефис
- Описание говорит, что скилл делает **и** когда его запускать, от третьего лица
- Настоящий запасной вариант на случай, когда коннектора нет
- Шлагбаумы согласования на всё значимое
- Никогда не выдумывает числа; отсутствующие данные сообщаются как отсутствующие

**Пиши на языке владельца, а не на общем деловом.** Если они называют это «файл страховщика», то в скилле так и написано. Скиллу, полному незнакомых слов, не доверят работать без присмотра.

## Шаг 5. Проверь на реальном случае, прежде чем на него полагаться

Прогони новый скилл на случае, ответ на который владелец уже знает, — лучше всего на том самом, который он проходил. Покажи результат рядом с тем, что у него получилось вручную.

Именно этот шаг определяет, будут ли скиллом пользоваться. Владелец, увидевший, как он воспроизводит заведомо верный результат, поставит его на расписание. Тот, кто не видел, будет запускать его вручную и каждый раз проверять, а это ничего не экономит.

Если не совпало, исправь скилл и запусти снова. Не проси владельца принять почти совпадение.

## Шаг 6. Зарегистрируй и задай периодичность

Добавь его в `smb-router`, чтобы запросы простым языком доходили до него, и запиши фразы-триггеры, которыми владелец действительно пользуется.

Если задача повторяющаяся, предложи поставить её на расписание. Именно расписание превращает «скилл, который я мог бы запустить» в «то, что происходит без меня», а это и есть результат, которого они хотели.

## Шаг 7. Поделись, с согласованием

Предложи поделиться с командой. Скажи, что значит поделиться: кто получит, до каких данных скилл дотянется и что сможет делать без присмотра.

**Говори о риске прямо, когда скилл отправляет, тратит или пишет.** Скилл, который рассылает письма клиентам, запущенный человеком, не создававшим его и не знающим его допущений, — реальная опасность. Рекомендуй для общих скиллов, что-либо отправляющих, режим «только черновики».

## Чего не делать

- **Не опрашивай заново о задаче, которую они только что прошли.** Переписка — это и есть спецификация.
- **Не зашивай пример жёстко.** Имена, даты и суммы меняются; последовательность нет.
- **Не ставь шлагбаум на каждый шаг.** Девять согласований хуже, чем делать вручную.
- **Не пропускай тестовый прогон.** Непроверенный скилл вечно проверяют вручную, а это ничего не экономит.
- **Не пиши на общем деловом языке.** Их слова, иначе им не поверят.
- **Не строй ничего, что отправляет или тратит, без шлагбаумов согласования.** Никогда, о чём бы ни просил владелец.

## После сборки

У владельца теперь есть именной скилл, который можно вызвать или поставить на расписание. Если новый скилл упёрся в инструмент, который не подключён, естественный следующий шаг — «подключись к моему ERP» (`build-connector`): он превращает отсутствующую систему в работающий источник. Рядом также: «дай мне сводку», чтобы вплести новый результат в ежедневную картину, и «бриф на понедельник», если скилл должен питать еженедельный. Предлагай не больше трёх и пропускай любое предложение, от которого владелец уже отказался в этой сессии.

## Справочные файлы

- `reference/capture.md` — как получить полную картину задачи без допроса
- `reference/skill_authoring.md` — структура, шапка и где должны стоять шлагбаумы согласования
- `reference/gotchas.md` — типичные ошибки, из-за которых получается скилл, которым никто не пользуется

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/small-business/skills/build-agent, лицензия Apache-2.0. Изменения: перевод на русский язык.