К основному содержанию
скилл CX Codex

done-blocked — скилл для Claude Code: что делает и как установить

Фиксирует строгий формат финала для агентов: статус только DONE или BLOCKED с доказательствами. Помогает убрать расплывчатые отчёты в пайплайнах.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add avelikiy/great_cto --skill done-blocked -a claude-code
Открыть на GitHub

Что делает done-blocked

Скилл задаёт протокол завершения работы для субагентов. Промежуточные отчёты остаются гибкими. Финальный вердикт обязан содержать ровно один из двух статусов: DONE или BLOCKED. Для успешного завершения агент фиксирует артефакт и следующий этап пайплайна. Для статуса BLOCKED требуются три поля: предпринятые попытки (tried), точная причина сбоя (failed_because) и запрос на разблокировку (need).

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

Вердикт выводится в последней строке ответа и сохраняется в .great_cto/verdicts/<agent>-<YYYY-MM-DD-HHMMSS>.log. Это позволяет вести аудит и отслеживать повторяющиеся системные препятствия.

Какие задачи решает

  • стандартизировать финальную сдачу задач субагентами
  • отсечь неопределённые отчёты о статусе выполнения
  • собирать точные причины сбоев с логами и путями к файлам
  • сохранять журнал вердиктов для аудита пайплайна

Примеры запросов агенту

  • Заверши аудит безопасности и сформируй финальный вердикт по контракту done-blocked
  • Закрой задачу разработки и запиши статус в .great_cto/verdicts/
  • Подготовь отчёт тестирования с однозначным статусом DONE или BLOCKED

Как установить done-blocked

1Через Skills CLI (Vercel)

npx skills add avelikiy/great_cto --skill done-blocked -a claude-code

2Вручную: положить файлы

~/.claude/skills/done-blocked/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/done-blocked/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Вопросы о done-blocked

Как установить done-blocked в Claude Code?

Выполните команду npx skills add avelikiy/great_cto --skill done-blocked -a claude-code в терминале.

Зачем нужен скилл done-blocked?

Он обязывает агентов выбирать только один из двух статусов: DONE или BLOCKED. Это убирает двусмысленность при передаче работы следующему этапу конвейера.

Что произойдёт, если агент не заполнит одно из полей в отчёте BLOCKED?

Оркестратор отклонит такой вердикт. Для статуса BLOCKED строго обязательны три поля: tried, failed_because и need.

Исходный текст

SKILL.md · MIT
---
name: done-blocked
description: Reusable reporting contract for any agent that hands work back to the pipeline. Forces ONE of two terminal statuses (DONE or BLOCKED) with a specific evidence shape. Stops vague "probably finished" and "kind of stuck" verdicts.
when_to_use: |
  Apply to every terminal verdict an agent writes — the last line of a spawned agent run, the top of a report file, or the summary appended to a Beads task comment. Specifically:
  - architect ARCH doc completion → DONE or BLOCKED
  - senior-dev task close → DONE or BLOCKED
  - qa-engineer QA report verdict → DONE (PASS) or BLOCKED (FAIL with evidence)
  - security-officer CSO audit verdict → DONE (APPROVED) or BLOCKED (findings)
  - devops deploy step → DONE or BLOCKED
  - l3-support incident triage step → DONE or BLOCKED
  - project-auditor audit completion → DONE or BLOCKED
  Do NOT force this on intermediate progress pings (those are advisory). Only terminal verdicts.
effort: low
allowed-tools: Read, Write, Bash
paths:
  - ".great_cto/verdicts/**"
  - "docs/**"
---

# DONE / BLOCKED Reporting Contract

Terminal status is exactly two states, and BLOCKED requires specific evidence — not vague obstruction reports.

## The contract

Every agent's final handoff line is one of:

```
DONE: <one-sentence summary of what shipped>
  artifact: <path to report/PR/commit>
  next: <who picks this up — pipeline stage, gate, or "pipeline continues">
```

```
BLOCKED: <one-sentence summary of the obstacle>
  tried: <what was attempted — file paths, commands, error signatures>
  failed_because: <concrete reason — not "unclear", not "complex">
  need: <specific unblock — file access, missing config, CTO decision, another agent>
```

## Hard rules

1. **No third state.** "Mostly done", "done with caveats", "almost there" → choose. If caveats exist, the caveat itself decides:
   - Caveat is cosmetic / P2+ → **DONE** (file a Beads bug, move on)
   - Caveat blocks the next pipeline stage → **BLOCKED** (do not pretend)

2. **BLOCKED requires three fields.** `tried` + `failed_because` + `need`. Missing any field → the verdict is rejected and the agent must re-report. No exceptions for "obvious" cases.

3. **Silence is not DONE.** If the agent stops producing output without a terminal line, the parent / next stage treats it as BLOCKED with `failed_because: silent — no terminal verdict written`.

4. **`failed_because` must be concrete.** These are rejected:
   - "environment issue" → say *which* command failed with *what* error
   - "tests failing" → say *which* tests and the actual assertion message
   - "unclear requirements" → say *which* decision is needed and the two options
   - "not enough context" → say *which* file / doc / config you tried to read

5. **`need` names a specific unblock.** These are rejected:
   - "more information" → ask one specific question
   - "help from another agent" → name the agent (architect / security-officer / …)
   - "CTO approval" → state the exact choice (approve gate X, pick option A vs B, waive check)

## Where the verdict goes

Every agent writes the verdict to **two places**:

1. **Last line of agent output** (visible to the orchestrator that spawned it).
2. **`.great_cto/verdicts/<agent>-<YYYY-MM-DD-HHMMSS>.log`** — append-only audit trail.

```bash
mkdir -p .great_cto/verdicts
VERDICT_FILE=".great_cto/verdicts/<agent>-$(date -u +%Y-%m-%d-%H%M%S).log"
printf '%s\n' "$VERDICT_LINE" > "$VERDICT_FILE"
```

## Examples

**Good — DONE:**
```
DONE: CSO audit passed — 0 P0, 2 P1 findings filed as Beads tasks.
  artifact: docs/security/CSO-2026-04-19.md
  next: gate:ship ready for CTO approval
```

**Good — BLOCKED:**
```
BLOCKED: senior-dev cannot claim task BD-42 — circular dependency with BD-38.
  tried: bd ready → BD-42 did not appear; bd dep tree BD-42 → shows BD-38 blocks BD-42, BD-42 blocks BD-38
  failed_because: both tasks depend on each other transitively (BD-42 → BD-38 → BD-39 → BD-42)
  need: architect to split BD-39 into two tasks so the cycle breaks
```

**Rejected — vague BLOCKED:**
```
BLOCKED: couldn't finish QA — environment problems.
  tried: ran tests
  failed_because: stuff broken
  need: help
```
Why rejected: `tried` lacks command/path; `failed_because` is tautological; `need` is not actionable.

## Measuring the contract

`.great_cto/verdicts/*.log` is machine-readable. Weekly digest can compute:
- `DONE:BLOCKED` ratio per agent — too many BLOCKED from one agent = that role is under-resourced or prompt is unclear
- `failed_because` clustering — if the same reason appears 3+ times, that's a recurring obstruction worth a meta-fix (tooling, doc, skill)
- Silence rate (agents with no terminal verdict written) — should trend to zero

## Anti-patterns

- Writing both DONE and BLOCKED in the same report ("DONE but blocked on X"). Pick one. If you're blocked, the work isn't done.
- Using DONE as a politeness signal when the gate still fails. The verdict is for the machine, not the CTO's feelings.
- Writing the verdict only to stdout without persisting to `.great_cto/verdicts/`. The audit trail is what makes the contract measurable.

© avelikiy · MIT · avelikiy/great_cto

Похожие скиллы

Все скиллы по теме «Настройка агента: память, контекст, субагенты» →
setup-matt-pocock-skills Matt Pocock Скилл настраивает репозиторий для инженерных скиллов Matt Pocock: задаёт трекер задач, метки триажа и расположение доменной документации. Запустите его перед первым использованием остальных скиллов. 1 052 851установок ask-matt Matt Pocock Помогает выбрать подходящий скилл или рабочий поток из набора Matt Pocock. Пригодится, когда непонятно, с чего начать задачу: от идеи до разбора бага. 766 587установок to-tickets Matt Pocock Разбивает план, спецификацию или переписку на небольшие сквозные задачи и отмечает, какие из них блокируют остальные. Пригодится, когда нужно согласовать порядок работы до публикации задач в трекере. 711 230установок writing-plans Jesse Vincent Скилл превращает требования к многошаговой задаче в подробный план реализации до начала работы с кодом. Пригодится, когда исполнителю нужно зафиксировать файлы, интерфейсы и проверки. CX Codex 282 859установок caveman-review JuliusBrussee Пишет замечания к коду одной строкой: место, проблема, исправление. Пригодится, когда ревью диффа или PR надо пройти быстро и без воды. CX Codex +1 411 800установок caveman-compress JuliusBrussee Сжимает CLAUDE.md, списки задач и другие текстовые файлы в краткий формат, сохраняя читаемую резервную копию. CX Codex +1 411 500установок

Из того же набора26

opportunity-solution-tree Скилл помогает связать измеримый результат с проблемами клиентов, вариантами решений и экспериментами. Пригодится, когда команда выбирает, что исследовать или строить дальше. CX Codex +1 ★ 107звёзд репо observability-baseline Добавляет в новый сервис перехват ошибок в Sentry, структурные логи с request_id и эндпоинты /healthz и /readyz. Пригодится, когда проект только собирается и первый сбой в проде не должен остаться незамеченным. CX Codex +1 ★ 107звёзд репо lifecycle-messaging Скилл помогает проектировать email- и SMS-сообщения с учётом согласия, доставки и разделения транзакционных и маркетинговых рассылок. Пригодится при подключении провайдера или добавлении сообщений в продукт. CX Codex +1 ★ 107звёзд репо great_cto Скилл превращает Claude в оркестратора: CTO описывает задачу словами, а агенты сами проходят этапы пайплайна. Пригодится тем, кто ведёт проект целиком через агента. CX Codex +1 ★ 107звёзд репо discovery Скилл помогает собрать контекст и ограничения до архитектурного решения, аудита или плана безопасности. Используйте его, когда важных деталей ещё нет в запросе. CX Codex +1 ★ 107звёзд репо deploy-landed Скилл проверяет, что на сервере работает именно нужный коммит, переменные окружения на месте и продукт выполняет свою работу. Пригодится после деплоя, рестарта или правки на сервере. CX Codex +1 ★ 107звёзд репо crystallize Собирает повторяющиеся уроки из журналов сессий и готовит черновики скиллов. Запускайте, когда накопились знания, которые стоит перенести в переиспользуемые инструкции. CX Codex +1 ★ 107звёзд репо cost-model Задаёт единый формат раздела о стоимости в планах и архитектурных документах. Нужен, когда отчёт называет экономию и её придётся защищать. CX Codex +1 ★ 107звёзд репо

Спонсоры проекта

Компании, которые помогают держать аналитику открытой