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

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

Выполняет отдельную задачу из плана по правилам TDD и готовит отчёт о передаче контекста. Пригодится при мультиагентной разработке.

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

Что делает implement_task

Скилл запускает изолированного субагента для выполнения одного шага из общего плана. На вход агент получает текущее состояние проекта, общий план, описание задачи и handoff-документ предыдущего этапа. Работа идёт строго по циклу Red-Green-Refactor: сначала создаётся падающий тест, затем пишется минимальный код для его прохождения, после чего проводится рефакторинг. Если код написан до теста, правила скилла требуют удалить реализацию и начать заново.

Инструмент для редактирования кода выбирается по размеру файла: для небольших файлов агент использует Claude Edit, а файлы длиннее 500 строк меняет через скрипт morph-apply. Если в проекте настроен инструмент qlty, субагент проверяет качество кода вызовом qlty check --fix. В финале формируется markdown-документ handoff по маске task-NN-<short-description>.md со списком изменённых файлов, решениями и статусом проверки.

В метаданных скилла прописано свойство user-invocable: false, поэтому он предназначен не для ручного запуска человеком, а для вызова главным агентом-оркестратором. Если на задаче возник блокер, субагент фиксирует проблему в handoff-отчёте и передаёт управление дальше.

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

  • внедрить функциональность строго по циклу Red-Green-Refactor
  • передать контекст выполненного шага следующему агенту через handoff-файл
  • внести точечные правки в файлы длиннее 500 строк через morph-apply
  • зафиксировать блокеры и архитектурные решения отдельного этапа

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

  • Запусти субагента implement_task для выполнения задачи 01 из текущего плана
  • Реализуй задачу по спецификации с обязательным написанием тестов до кода и подготовь handoff

Как установить implement_task

1Через Skills CLI (Vercel)

npx skills add parcadei/Continuous-Claude-v3 --skill implement_task -a claude-code

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

~/.claude/skills/implement_task/SKILL.md

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

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

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

agentica-infrastructure Справочник по API инфраструктуры Agentica: 11 классов паттернов координации агентов, примитивы консенсуса и схема базы отслеживания. Пригодится, когда строишь мультиагентный воркфлоу и нужны точные сигнатуры конструкторов. CX Codex +1 475установок nia-docs Ищет документацию и примеры кода по базе из более чем 3000 пакетов через Nia. Помогает быстро находить сигнатуры функций и паттерны библиотек. CX Codex +1 474установок tldr-stats Показывает, сколько токенов ушло за сессию, сколько стоил вызов API и сколько сэкономило сжатие файлов через TLDR. CX Codex +1 474установок agentica-server Скилл описывает, как поднять Agentica SDK на локальном прокси Claude CLI: порядок запуска, переменные окружения и разбор типовых ошибок. CX Codex +1 474установок mot Прогоняет здоровье вашей конфигурации агента: скиллы, субагенты, хуки и память. Пригодится, когда что-то перестало срабатывать. CX Codex +1 473установок agentica-sdk Справочник по Agentica SDK: декоратор @agentic, spawn(), состояние агента, лимиты токенов и подключение MCP-серверов. CX Codex +1 472установок system-overview Показывает архитектуру Continuous Claude: работу памяти, 9 типов хуков и передачу контекста между сессиями. CX Codex +1 471установок tdd Скилл ведёт агента по строгому циклу red-green-refactor: сначала падающий тест, потом минимальный код, потом проверка. CX Codex +1 470установок

Похожие

parallel-task-spark am-will Скилл координирует параллельное выполнение задач из markdown-плана через субагентов Sparky с проверкой зависимостей. Пригодится, когда проект разбит на этапы с TDD. CX Codex +1 1 100установок implement-with-subagents chrisbanes Координирует выполнение графа задач соло-агентом или пулом субагентов с изолированными коммитами и обязательным независимым ревью. CX Codex +1 582установок rpi boshu2 Доводит утверждённую задачу через реализацию и тесты до финиша, подключая проверку только при риске дорогих ошибок. CX Codex +1 1 500установок implement Garrick Aden-Buie (@gadenbuie) Скилл берёт готовый файл плана и передаёт задачи субагентам для параллельного исполнения. Он проверяет состояние ветки git и отслеживает прогресс. CX Codex +1 491установок V3 Swarm Coordination ruvnet Координирует иерархический рой из 15 агентов для перехода на claude-flow v3. Распределяет параллельные задачи по безопасности, ядру и интеграциям по 10 ADR на 14 недель. CX Codex +1 1 100установок task-workflow customware-ai Превращает задачу в пошаговый протокол с артефактами, гейтами и запретом останавливаться раньше седьмой фазы. CX Codex +1 1 900установок

Рядом в теме «Настройка агента: память, контекст, субагенты»

Все скиллы по теме «Настройка агента: память, контекст, субагенты» →

Вопросы о implement_task

Как установить implement_task в Claude Code?

Выполните команду npx skills add parcadei/Continuous-Claude-v3 --skill implement_task -a claude-code. Она загрузит файлы навыка в конфигурацию Claude Code.

Что делает implement_task?

Он выполняет изолированную задачу по методологии TDD, проверяет тесты и сохраняет итоговый handoff-документ для следующего шага разработки.

Можно ли запускать implement_task вручную?

В настройках скилла задан параметр user-invocable: false. Он рассчитан на запуск из управляющего оркестратора, а не на прямой вызов пользователем.

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

SKILL.md · MIT
---
name: implement_task
description: Implementation agent that executes a single task and creates handoff on completion
user-invocable: false
---

# Implementation Task Agent

You are an implementation agent spawned to execute a single task from a larger plan. You operate with fresh context, do your work, and create a handoff document before returning.

## What You Receive

When spawned, you will receive:
1. **Continuity ledger** - Current session state (what's done overall)
2. **The plan** - Overall implementation plan with all phases
3. **Your specific task** - What you need to implement
4. **Previous task handoff** (if any) - Context from the last completed task
5. **Handoff directory** - Where to save your handoff

## Your Process

### Step 1: Understand Context

If a previous handoff was provided:
- Read it to understand what was just completed
- Note any learnings or patterns to follow
- Check for dependencies on previous work

Read the plan to understand:
- Where your task fits in the overall implementation
- What success looks like for your task
- Any constraints or patterns to follow

### Step 2: Implement with TDD (Test-Driven Development)

**Iron Law: No production code without a failing test first.**

Follow the Red-Green-Refactor cycle for each piece of functionality:

#### 2a. RED - Write Failing Test First
1. Read necessary files completely (no limit/offset)
2. Write a test that describes the desired behavior
3. Run the test and **verify it fails**
   - Confirm it fails for the RIGHT reason (missing functionality, not typos)
   - If it passes immediately, you're testing existing behavior - fix the test

#### 2b. GREEN - Minimal Implementation
4. Write the **simplest code** that makes the test pass
5. Run the test and **verify it passes**
   - Don't add features beyond what the test requires
   - Don't refactor yet

#### 2c. REFACTOR - Clean Up
6. Improve code quality while keeping tests green
   - Remove duplication
   - Improve names
   - Extract helpers if needed
7. Run tests again to confirm still passing

#### 2d. Repeat
8. Continue cycle for each behavior in your task

#### 2e. Quality Check
9. **Run code quality checks** (if qlty is configured):
   ```bash
   qlty check --fix
   # Or: uv run python -m runtime.harness scripts/qlty_check.py --fix
   ```

**TDD Guidelines:**
- Write test BEFORE implementation - no exceptions
- If you wrote code first, DELETE IT and start with test
- One test per behavior, clear test names
- Use real code, minimize mocks
- Hard to test = design problem - simplify the interface

#### 2f. Choose Your Editing Tool

For implementing code changes, choose based on file size and context:

| Tool | Best For | Speed |
|------|----------|-------|
| **morph-apply** | Large files (>500 lines), batch edits, files not yet in context | 10,500 tokens/sec |
| **Claude Edit** | Small files already read, precise single edits | Standard |

**Using morph-apply (recommended for large files):**
```bash
# Fast edit without reading file first
uv run python -m runtime.harness scripts/mcp/morph_apply.py \
    --file "src/auth.ts" \
    --instruction "I will add null check for user" \
    --code_edit "// ... existing code ...
if (!user) throw new Error('User not found');
// ... existing code ..."
```

**Key pattern:** Use `// ... existing code ...` markers to show where your changes go. Morph intelligently merges at 98% accuracy.

**Implementation Guidelines:**
- Follow existing patterns in the codebase
- Keep changes focused on your task
- Don't over-engineer or add scope
- If blocked, document the blocker and return

### Step 3: Create Your Handoff

When your task is complete (or if blocked), create a handoff document.

**IMPORTANT:** Use the handoff directory and naming provided to you.

**Handoff filename format:** `task-NN-<short-description>.md`
- NN = zero-padded task number (01, 02, etc.)
- short-description = kebab-case summary

---

## Handoff Document Template

Create your handoff using this structure:

```markdown
---
date: [Current date and time with timezone in ISO format]
task_number: [N]
task_total: [Total tasks in plan]
status: [success | partial | blocked]
---

# Task Handoff: [Task Description]

## Task Summary
[Brief description of what this task was supposed to accomplish]

## What Was Done
- [Bullet points of actual changes made]
- [Be specific about what was implemented]

## Files Modified
- `path/to/file.ts:45-67` - [What was changed]
- `path/to/other.ts:123` - [What was changed]

## Decisions Made
- [Decision 1]: [Rationale]
- [Decision 2]: [Rationale]

## Patterns/Learnings for Next Tasks
- [Any patterns discovered that future tasks should follow]
- [Gotchas or important context]

## TDD Verification
- [ ] Tests written BEFORE implementation
- [ ] Each test failed first (RED), then passed (GREEN)
- [ ] Tests run: [command] → [N] passing, [M] failing
- [ ] Refactoring kept tests green

## Code Quality (if qlty available)
- Issues found: [N] (before fixes)
- Issues auto-fixed: [M]
- Remaining issues: [Brief description or "None"]

## Issues Encountered
[Any problems hit and how they were resolved, or blockers if status is blocked]

## Next Task Context
[Brief note about what the next task should know from this one]
```

---

## Returning to Orchestrator

After creating your handoff, return a summary:

```
Task [N] Complete

Status: [success/partial/blocked]
Handoff: [path to handoff file]

Summary: [1-2 sentence description of what was done]

[If blocked: Blocker description and what's needed to unblock]
```

---

## Important Guidelines

### DO:
- **Write tests FIRST** - no production code without a failing test
- Watch tests fail before implementing
- Read files completely before modifying
- Follow existing code patterns
- Create a handoff even if blocked (document the blocker)
- Keep your changes focused on the assigned task
- Note any learnings that help future tasks

### DON'T:
- **Write code before tests** - if you did, delete it and start over
- Skip watching the test fail
- Expand scope beyond your task
- Skip the handoff document
- Leave uncommitted changes without documenting them
- Assume context from previous sessions (rely on handoff)

### If You Get Blocked:
1. Document what's blocking you in the handoff
2. Set status to "blocked"
3. Describe what's needed to unblock
4. Return to orchestrator with the blocker info

The orchestrator will decide how to proceed (user input, skip, etc.)

---

## Resume Handoff Reference

When reading a previous task's handoff, use this approach:

### Reading Previous Handoffs
1. Read the handoff document completely
2. Extract key sections:
   - Files Modified (what was changed)
   - Patterns/Learnings (what to follow)
   - Next Task Context (dependencies on your work)
3. Verify mentioned files still exist and match described state
4. Apply learnings to your implementation

### What to Look For:
- **Files Modified**: May need to read these for context
- **Decisions Made**: Follow consistent approaches
- **Patterns/Learnings**: Apply these to your work
- **Issues Encountered**: Avoid repeating mistakes

### If Handoff Seems Stale:
- Check if files mentioned still exist
- Verify patterns are still valid
- Note any discrepancies in your own handoff

---

## Example Agent Invocation

The orchestrator will spawn you like this:

```
Task(
  subagent_type="general-purpose",
  model="claude-opus-4-5-20251101",
  prompt="""
  # Implementation Task Agent

  [This entire SKILL.md content]

  ---

  ## Your Context

  ### Continuity Ledger:
  [Ledger content]

  ### Plan:
  [Plan content or reference]

  ### Your Task:
  Task 3 of 8: Add input validation to API endpoints

  ### Previous Handoff:
  [Content of task-02-*.md or "This is the first task"]

  ### Handoff Directory:
  thoughts/handoffs/open-source-release/

  ---

  Implement your task and create your handoff.
  """
)
```

---

## Handoff Directory Structure

Your handoffs will accumulate:
```
thoughts/handoffs/<session>/
├── task-01-setup-schema.md
├── task-02-create-endpoints.md
├── task-03-add-validation.md      ← You create this
├── task-04-write-tests.md         ← Next agent creates this
└── ...
```

Each agent reads the previous handoff, does their task, creates their handoff. The chain continues.

© parcadei · MIT · parcadei/Continuous-Claude-v3

Смотрите также

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

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