100 KiB

Raw Permalink Blame History

сейчас январь 2026

хочу разобраться с Anthropic фичами для claude code subagents skills

с одной стороны классно что антропик вводит новые концепции в AI разработку. Но у меня ощущение что subagents это у них получилось не совсем удачно или не совсем то, что ожидало бы сообщество И затем они выпустили skills - что на самом деле больше отражает суть "агентов" и это то, что на самом деле нужно было делать когда они выпускали подагентов. Какова реальная ситуация на данный момент? Ощущение что скиллс получили больший адопшен и любовь разработчиков так ли это? чем лучше на самом деле пользоваться? есть ли вообще смысл заводить в мелких и средних проектах агентов? вообше вся эта система с агентами пользовательского и проектного уровня хоть работает? у меня это лично както "не зашло". дело усугубляется тем что я работаю в claude code екстеншине для vscode и вообше не вижу вызываются ли мои агенты или нет? для примера, я в одном проекте создал трех агентов: фронтендер, дизайнер, бэкендер. каждому прописал конкретные требования по код стайлу, дизайн системе, ключевым подходам и организации монорепы - то что раньше я бы просто прописал в корневом CLAUDE. MD однако мне постоянно приходится напоминать в промптах использовать нужных агентов. к томуже во многих фронтовых задачах нужно взаимодействие обоих но я не вижу насколько правильно это происходит (может и норм но в vscode это сложно отследить) и главное не понятно дает ли введение этих агентов какуюто пользу. нужно ли дальше добавлять агентов с какойто узкой экспертизой

Теперь у меня достаточно информации для составления подробного анализа. Позволь мне создать итоговый отчет.

Реальная ситуация с Subagents и Skills в Claude Code (январь 2026)

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

Что произошло: краткая хронология

Август 2025: Anthropic выпустила subagents как основную фичу для Claude Code¹². Идея казалась революционной — создать специализированных AI-ассистентов с отдельными контекстными окнами, кастомными промптами и специфичными разрешениями на инструменты. Сообщество восприняло это с энтузиазмом, но быстро столкнулось с проблемами.

Октябрь 2025: Anthropic анонсировала Skills³⁴ — радикально более простую концепцию. Skills — это просто папки с markdown-инструкциями, скриптами и ресурсами, которые Claude загружает автоматически когда они релевантны задаче.

Декабрь 2025: На AI Engineering Summit представители Anthropic (Barry Zhang и Mahesh Murag) публично заявили: "Не стройте агентов, стройте Skills вместо этого"⁵⁶. Это было официальное признание того, что индустрия пошла не в ту сторону.

Почему subagents "не зашли"

Твой личный опыт отражает системные проблемы, которые обнаружило всё сообщество:

1. Отсутствие видимости (твоя главная боль)

В VSCode extension действительно нет нормального способа отследить вызов subagents⁷⁸⁹. Это не баг — это фундаментальная проблема дизайна. Subagents работают в отдельных контекстах и возвращают только summary результатов главному агенту¹⁰. Пользователи жалуются:

"The biggest gripe is lack of visibility. You can't see what they are doing or thinking. This makes it hard to determine if intervention is necessary."⁷

"Subagents are slow, consume vast tokens while hiding their work."⁷

Даже с debug-режимом (Ctrl+R) невозможно нормально отследить что происходит внутри subagent⁸.

2. Потеря контекста

Каждый subagent работает в изоляции со своим контекстным окном¹¹¹⁰. Это означает:

Они не знают о работе друг друга
Главному Claude приходится полагаться на неполные отчёты
При работе над одними файлами возникают конфликты¹²¹³

Разработчик описывает типичную проблему:

"Subagents tend to lose context when operating in the background, which disrupts workflow. Despite tweaking configurations, I haven't ensured they maintain necessary context during longer tasks."¹¹

3. Координация — твоя боль

Твоя ситуация с frontend/designer/backend агентами типична. Проблема в том, что:

Subagents не могут вызывать друг друга напрямую¹⁴
Взаимодействие идёт только через главного агента: Primary → subagent1 → Primary → subagent2¹⁴
При работе над связанными задачами (frontend + backend) координация превращается в хаос¹²¹⁵

Один разработчик описывает это как "too much trust in subagents even when instructed otherwise, limiting visibility into their activities"⁷.

4. Оверхед сложности

Для мелких и средних проектов subagents добавляют больше проблем, чем решают:

Нужно тщательно проектировать boundaries между агентами¹⁶
Приходится явно управлять тем, какие инструменты доступны каждому²
Требуется постоянно напоминать Claude использовать правильного агента¹⁷¹⁸

Почему Skills получили больший adoption

Твоё ощущение совершенно верное. Skills действительно получили значительно больше любви сообщества, и вот почему:

1. Философский сдвиг от Anthropic

На AI Engineering Summit Barry Zhang объяснил ключевой insight⁵⁶:

"We used to think agents in different domains will look very different. The agent underneath is actually more universal than we thought. Instead of building new agents for every use case, companies should rely on a single general agent powered by a library of skills."

Проблема с агентами: они пытались решить проблему специализации через изоляцию. Skills решают её через контекст по требованию¹⁹²⁰.

2. Простота и прозрачность

Skills — это просто markdown-файлы²¹⁴. Не нужно:

Настраивать permissions для tools
Думать о context isolation
Отслеживать работу отдельных агентов
Координировать между агентами

Claude сам решает когда загрузить skill на основе описания задачи²²⁴. Это model-invoked vs user-invoked подход.

3. Портативность

Skills работают везде: Claude.ai, Claude Code, API⁴²³. Subagents — только в Claude Code²⁴²⁵. Это огромное преимущество для реального enterprise adoption.

4. Компонуемость

Skills стакаются вместе автоматически⁴²⁰. Claude может загрузить несколько skills одновременно для комплексной задачи. С subagents это превращается в orchestration nightmare.

5. Network effects

За 5 недель после запуска пользователи создали тысячи skills⁶. Anthropic открыла официальный репозиторий²⁶, и skills становятся индустриальным стандартом²⁷²⁸ — OpenAI, Microsoft, GitHub Copilot начали адаптировать эту концепцию.

Что на самом деле нужно делать

Основываясь на анализе 80+ источников и практическом опыте сообщества:

Для мелких/средних проектов (твой случай):

1. CLAUDE.md >> Project agents

Твоя интуиция абсолютно верна. Для проектов до ~50k LOC хорошо структурированный CLAUDE.md значительно эффективнее кучи агентов²⁹³⁰³¹³²³³.

Что включать в CLAUDE.md:

Код стайл и конвенции
Архитектура проекта и организация монорепы
Дизайн система
Ключевые подходы к frontend/backend

То, что ты "раньше прописывал в корневом CLAUDE.MD" — это и есть правильный подход³⁴³⁰.

2. Skills вместо subagents для специализации

Твои три агента (frontend, designer, backend) лучше переписать как skills²⁰¹⁸³⁵:

~/.claude/skills/
├── frontend-standards/
│   └── SKILL.md  # React patterns, code style, design system
├── backend-patterns/
│   └── SKILL.md  # API design, error handling, monorepo structure
└── design-system/
    └── SKILL.md  # Component library, spacing, colors

Claude будет автоматически загружать нужный skill когда ты работаешь над frontend или backend³⁶³⁷. Никаких явных упоминаний не нужно.

3. Используй subagents только для специфичных кейсов

Subagents имеют смысл только для:

Параллельных независимых задач: когда нужно обработать 50 файлов одновременно³⁸³⁹
Изоляции контекста: когда нужно большое исследование без загрязнения основного контекста¹⁷⁴⁰
Длительных фоновых задач: запустил и забыл (Ctrl+B)⁴¹⁴²

Но НЕ для:

Координации между frontend/backend
"Экспертных ролей" (это лучше через skills)
Узкой специализации в рамках одного проекта

Когда агенты (вообще) имеют смысл

Анализ показывает чёткую картину⁴³⁴⁴⁴⁵⁴⁶:

Используй агентов когда:

Задача легко декомпозируется на независимые части
Код можно безопасно заменить (не mission-critical)
Нужно быстрое прототипирование
Работаешь с boilerplate/tedious code⁴⁷

НЕ используй когда:

Tight coupling между компонентами (твой случай)
Требуется глубокое понимание архитектуры
Проект требует maintenance в долгосрочной перспективе⁴⁸
Complexity > твоя способность review код быстро⁴⁵

Практические рекомендации для твоей ситуации

На основе твоего описания (3 агента в монорепе, VSCode, frontend/backend/designer):

1. Избавься от project-level agents

Перенеси их содержимое в:

./CLAUDE.md — архитектура, монорепа, базовые подходы
~/.claude/skills/ — специализированные знания как skills

2. Создай 2-3 skills вместо агентов

frontend-development.skill.md:

---
name: frontend-development
description: Expert in React, Next.js frontend development following project code style and design system
---

## Code Style
[твои frontend стандарты]

## Design System  
[компоненты, patterns, spacing rules]

## When to use
Use this skill when:
- Building React components
- Implementing UI features
- Working with design system

Аналогично для backend. Skills будут загружаться автоматически³⁶⁴⁹.

3. Используй Plan Mode активно

В VSCode extension включи Plan Mode⁵⁰⁵¹. Это позволит:

Видеть что Claude планирует делать
Корректировать до выполнения
Понимать логику без "черного ящика" subagents

4. Leverage context engineering

Вместо агентов используй:

@-mentions для файлов/контекста⁵⁰
Явные промпты: "Focus on frontend standards from CLAUDE.md"
TODO.md файлы для tracking⁵²⁵³

Что говорит Anthropic официально

Их позиция кристально ясна⁵⁶:

"Don't build agents — build skills instead. Skills are organized collections of files that package composable procedural knowledge for agents. The real breakthrough isn't more agents, but agent skills."

Barry Zhang на summit прямо сказал: agents "lack expertise and often miss important context"⁵. Skills решают это без оверхеда координации.

Итоговая правда

Твоё ощущение что "subagents получилось не совсем удачно" — абсолютно верное⁵⁴³⁸¹¹. Проблемы:

Visibility — в VSCode действительно не видно что происходит
Coordination overhead — для связанных задач (frontend+backend) это больше проблем чем пользы
Adoption — skills получили значительно больше любви, и сам Anthropic это признал
Смысл для мелких/средних проектов — минимальный²⁹⁴⁸⁵⁵

Твой workflow (CLAUDE.md + явные промпты) более эффективен для проектов твоего масштаба чем введение агентов³⁰³²⁵⁶³³.

Рекомендация: Мигрируй на Skills для специализированных знаний, используй качественный CLAUDE.md для project context, и используй subagents только для occasional параллельных задач где нужна изоляция контекста. Для твоих frontend/designer/backend агентов — skills будут работать намного лучше. ⁵⁷⁵⁸⁵⁹⁶⁰⁶¹⁶²⁶³⁶⁴⁶⁵⁶⁶⁶⁷⁶⁸⁶⁹⁷⁰⁷¹⁷²⁷³⁷⁴⁷⁵⁷⁶⁷⁷⁷⁸⁷⁹⁸⁰⁸¹⁸²⁸³⁸⁴⁸⁵⁸⁶⁸⁷⁸⁸⁸⁹⁹⁰⁹¹⁹²⁹³⁹⁴⁹⁵⁹⁶⁹⁷⁹⁸⁹⁹¹⁰⁰¹⁰¹¹⁰²¹⁰³¹⁰⁴¹⁰⁵¹⁰⁶¹⁰⁷¹⁰⁸¹⁰⁹¹¹⁰

⁂

для чего тогда вообще нужны агенты? это тупиковая ветка или или есть какието кейсы где без них никак?

Агенты точно не тупик, но это «тяжёлая техника», которая нужна сильно реже, чем её сейчас пытаются применять. ¹¹¹¹¹²

Когда агенты реально нужны

1. Длинные, многосессионные задачи

Агенты полезны, когда работа длится часы/дни, разбита на сессии и должна делать прогресс без тебя в цикле. ¹¹³¹¹⁴¹¹⁵

Примеры:

Большой рефакторинг/миграция (Next 12 → 15, Redux → Zustand и т.п.).
Реализация десятков фич по длинному списку требований.
Поддержка «долгоживущих» процессов: периодический анализ логов, чистка техдолга, автогенерация отчётов.

Anthropic отдельно пишет про «long‑running agents» с initializer‑агентом и coding‑агентом, которые:

Ведут журнал прогресса.
Работают фича‑за‑фичей.
Обеспечивают чистое состояние репозитория в конце каждой сессии. ¹¹³¹¹⁴¹¹⁵

2. Автономная работа «поговорить + сделать»

Из их whitepaper: агенты особенно полезны там, где нужно и общаться, и действовать, с понятным критерием успеха и фидбек‑лупом. ¹¹⁶¹¹¹¹¹²

Примеры:

Coding‑агенты, которые сами:
- Берут issue, планируют, правят код, гоняют тесты, пушат PR.
- Anthropic явно приводит этот сценарий как основной. ¹¹²
Внешние домены: customer support, финансы, legal, где агент:
- Читает контекст (ticket/документы).
- Планирует шаги.
- Зовёт инструменты (CRM, БД, API).
- Спрашивает человека только на ревью‑точках. ¹¹¹

3. Когда workflow слишком ветвистый для «if‑else»

Если процесс:

Многошаговый.
Ветвится по куче условий.
Меняется со временем.

То agent‑loop проще, чем вручную городить workflow‑движок. ¹¹⁷¹¹⁸

Типичные примеры:

Диагностические системы (поиск корня проблемы по логам/метрикам).
Research‑боты, которые итеративно ищут, фильтруют, агрегируют инфу. ¹¹⁷

Когда тебе, как индивидуалу, агенты почти не нужны

Anthropic сами говорят: «начинайте с простых LLM API/prompt‑ответ паттернов и только потом переходите к агентам, если этого реально не хватает». ¹¹⁹¹¹¹

Для одиночного dev’а на маленьком/среднем проекте:

Хороший CLAUDE.md + Skills + нормальная структура репы дают 80–90% эффекта. ¹²⁰¹²¹¹²²
Агенты добавляют:
- Сложность в отладке и наблюдаемости.
- Риск «runaway изменений» по коду. ¹²³¹²⁴¹²⁵

Именно поэтому у тебя ощущение, что «не зашло» — это нормальный, здоровый сигнал: твои задачи пока слишком локальные и управляемые, чтобы оправдать весь оверхед агентности. ¹²⁶¹²⁷

Не тупик, а нишевая штука

Anthropic в «Building Effective AI Agents» прямым текстом пишет: агент имеет смысл, когда: ¹¹¹¹¹²¹¹⁸

Нужна автономия (агент сам решает следующий шаг).
Есть внешние действия (инструменты/репо/CI, а не только текст).
Есть feedback‑сигнал (тесты, валидация, бизнес‑метрикa).
Есть человеческий oversight в ключевых точках.

А для всего остального они сами пушат подход «один универсальный агент + библиотека Skills», а не зоопарк под‑агентов. ¹²⁸¹²⁹¹¹¹

Если говорить конкретно для тебя

Твой стек/режим работы (solo/lead, много фронта, быстрые итерации) — это почти идеальный кейс без тяжёлых агентов:

Делай упор на:
- CLAUDE.md для контекста проекта. ¹²¹¹²²
- Skills для «ролей» (frontend, backend, дизайн‑система и т.п.). ¹³⁰¹³¹¹³²
Агента имеет смысл заводить точечно, если ты хочешь:
- «Ночью гоняй PR‑бота», который сам берёт issues из GitHub и валит PR’ы под твой review. ¹¹²¹³³
- Или «долгий refactor‑bot», который по чуть‑чуть вычищает конкретный слой (например, legacy API layer) с логом прогресса. ¹¹³¹¹⁴

Все остальные сценарии, где ты сейчас пытаешься размазать роли на frontend/designer/backend‑агентов, проще и надёжнее закрываются Skills + грамотным контекстом, а не «настоящими» агентами. ¹²³¹²⁸¹²⁹ ¹³⁴¹³⁵¹³⁶¹³⁷¹³⁸¹³⁹¹⁴⁰

⁂

ок. но просто интересно как эту агентскую систему строить? выглядит как сложный кейс где нужен отдельный фреймворк. кто и как сетапит такую систему?

Картинка такая: «агентская система» действительно ближе к отдельному фреймворку/инфраструктуре, и её обычно строят либо продуктовые команды, либо спец‑команды AI‑платформ внутри компаний, а не одиночные девы. ¹⁴¹¹⁴²

Базовая архитектура агентской системы

1. Не с агентов, а с workflows

Anthropic в «Building Effective Agents» прямо говорит: сначала проектируют workflow‑паттерн, а уже потом оборачивают его в агента. ¹⁴¹¹⁴³¹⁴²

Типовые кирпичи:

Augmented LLM: один Claude c:
- доступом к инструментам (HTTP, БД, git, shell, RAG и т.п.);
- хорошим промптом/контекст‑инженерингом. ¹⁴¹¹⁴⁴
Workflow‑паттерны (то, что многие по привычке называют «мульти‑агентной системой»):
- prompt chaining (пошаговый пайплайн);
- routing (роутинг задач к разным подсистемам);
- parallelization (параллельные ветки);
- orchestrator‑worker (центральный «координатор» + воркеры);
- evaluator‑optimizer (генератор + критик/ревьюер). ¹⁴⁵¹⁴⁶¹⁴⁷

2. Orchestrator–worker как основной «мульти‑агент» паттерн

В продакшене чаще всего используют схему: один orchestrator + несколько workers. ¹⁴⁵¹⁴⁸¹⁴⁹¹⁵⁰

Orchestrator:
- держит общий контекст: цель, ограничения, состояние мира;
- решает, какие шаги делать и кого звать;
- собирает/сводит результаты. ¹⁴⁵¹⁴⁸
Workers:
- заточены под конкретную задачу: coding‑worker, research‑worker, data‑worker, support‑worker и т.п.;
- имеют свои tools и policy (например, только чтение репы vs право пушить). ¹⁵⁰

Важно: часто все эти роли работают на одном и том же LLM, разница только в промпте/инструментах, а не в «отдельных моделях». ¹⁴¹¹⁵⁰

Кто это настраивает и как выглядит стек

1. В Enterprise / продуктовых командах

Там обычно есть:

AI Platform / ML‑инфра команда:
- поднимает «орchestrator‑layer» (LangChain, CrewAI, AutoGen, собственный фреймворк); ¹⁵¹¹⁵²¹⁵³
- настраивает доступ к Claude API, MCP‑сервакам, секретам, observability (логирование, трассировка, метрики). ¹⁵⁴¹⁴⁴
Продуктовые команды:
- описывают бизнес‑workflows (онбординг, обработка тикетов, отчёты);
- формулируют роли/skills/tools. ¹⁴¹¹⁴²

Классический стек:

orchestrator на Python/TypeScript (LangChain / ai-sdk.dev / свой рантайм); ¹⁴⁹¹⁵⁰¹⁵⁵
Claude как LLM + tools (через Claude Agent SDK / MCP / свои HTTP‑инструменты); ¹⁵⁶¹⁴⁴¹⁵⁷
внешние системы: GitHub, Jira, CRM, Postgres, REST. ¹⁵⁷¹⁴⁴

2. В «интеграторах» / консалтинге

Есть целые компании, которые специализируются на агентских системах на Claude (в тексте про Claude Agent SDK приводят SaaSNext как пример). ¹⁵⁷¹⁵⁴

Что они делают:

берут домен (финансы, support, ops);
проектируют паттерн (чаще orchestrator‑worker + evaluator‑optimizer); ¹⁴⁵¹⁴⁸
пишут свои tools и Skills;
вяжут всё с CI/CD, мониторингом, RBAC и audit‑логами. ¹⁵⁷¹⁵⁴¹⁵¹

По факту — это уже отдельная платформа поверх Claude, а не «воткнули пару агентов в IDE».

3. В open‑source / dev‑ориентированных проектах

Тут популярны:

anthropic‑cookbook с примерами паттернов/агентов; ¹⁵⁵
AI SDK (Vercel/ai‑sdk.dev) с готовыми паттернами, включая orchestrator‑worker; ¹⁴⁹
оркестрационные фреймворки: LangChain, CrewAI, AutoGen, SuperAGI и т.п. ¹⁵¹¹⁵³¹⁵⁰

Разработчик делает:

описывает роли как конфиг (YAML/TS/JSON);
определяет список tools для каждой роли;
пишет код orchestrator’а, который:
- создаёт sub‑agents,
- прокидывает им задачи,
- агрегирует ответы. ¹⁴⁹¹⁵⁰

Как бы это выглядело в твоём кодерском контексте

Представь, что ты не пытаешься «настроить агентов в VSCode», а делаешь отдельный сервис/CLI:

Orchestrator‑agent:
- читает issue из GitHub/Jira;
- планирует работу (список шагов/подзадач);
- решает, кого звать: coding‑worker, docs‑worker, infra‑worker. ¹⁴⁵¹⁴⁹
Coding‑worker (Claude + tools):
- умеет:
  - читать/писать файлы;
  - запускать тесты;
  - создавать ветку/PR. ¹⁵⁶¹⁵⁷¹⁴⁴
Docs‑worker:
- обновляет README, ADR, changelog. ¹⁴⁵
Evaluator‑worker:
- читает diff;
- проверяет против coding‑guidelines/CLAUDE.md;
- пишет summary/замечания. ¹⁴⁵¹⁴³

Поверх всего:

Логирование действий всех агентов;
Чекпоинты, где нужен human‑approval (например, перед merge). ¹⁵⁸¹⁵⁴

Это уже не про «настроил трёх агентов в VSCode», а про микросервис/CLI‑утилиту, которую можно крутить в CI/CD или локально.

Почему так ощущается «как отдельный фреймворк»

Потому что это и есть отдельный слой:

Нужны:
- state management (где живёт прогресс? файлы? БД? git‑ветка?); ¹⁴⁸¹⁵⁰
- observability (кто что сделал, где упали, почему принялось то или иное решение); ¹⁵⁴¹⁵¹
- permissions и sandboxing для tools; ¹⁵⁷¹⁵⁴
- error‑handling и recovery (ретраи, fallback‑стратегии, эскалации человеку). ¹⁴⁸¹⁵⁸

Anthropic в whitepaper честно пишет: агент — это не фича, а система. Поэтому они и советуют:

«Начинайте с простых augmented LLM/workflows. Агентный слой имеет смысл только когда вы готовы в него инвестировать как в отдельный продукт.» ¹⁴¹¹⁴²

Если упрощать до практики лично для тебя:

Да, чтобы «правильно» строить многоролевую агентную систему, тебе почти всегда нужен свой мини‑фреймворк/сервис, а не только то, что есть в IDE.
Делают это либо:
- продуктовые/платформенные команды;
- либо ты сам, но уже как отдельный internal‑tool/микросервис (CLI, bot, CI‑агент).
Внутри — один из стандартных паттернов Anthropic (orchestrator‑worker, evaluator‑optimizer и т.п.) + Claude Agent SDK/AI‑SDK/LangChain в качестве клея. ¹⁴⁵¹⁴⁹¹⁵⁷¹⁵⁰

Если хочешь, в следующем шаге можно прямо накидать скелет твоего «dev‑агента» под GitHub/monorepo в стиле orchestrator + coding‑worker на TS/Python. ¹⁵⁹¹⁶⁰¹⁶¹¹⁶²

⁂

да не, не надо

лучше про skills расскажи я пользуюсь vscode и claude code которого запускаю или прям во встроенном терминале либо в расшерении для клод как тут обстоит дело с визуаоизацией, контролем, автоматическим выбором? скиллы я сам создаю или беру готовые, настраивать и тюнить могу? предположим у меня такие задачи и идеи описать из в какихто отдельных сущностях. до этого я бы использовал агентов, но ты убедил меня что это не подходит. итак

фронтенд требования: определенный стиль создания компонентов, организации папок, требования к разделению на клиент и серверные компоненты. nextjs v 15

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

git: нужно делать коммиты с соблюдением паттерна в сообщениях

dev server: нужно запускать и осианавливать девсервер, читать логи, проверять что страницы грузятся без ошибок

Skills как раз отлично ложатся на твои четыре «сущности». Ниже – как это работает именно в связке VS Code + Claude Code.

Как работают Skills в Claude/VS Code

Skills — это портативные «капсулы процедурных знаний»: папки с SKILL.md (и опциональными скриптами), которые Claude может автоматически подгружать, когда задача совпадает с описанием skill’а. ¹⁶³¹⁶⁴
Автовыбор: модель сама решает, активировать ли skill, по name и description в frontmatter и по содержимому SKILL.md. ¹⁶³¹⁶⁴¹⁶⁵
Автоматическая работа в IDE: Claude Code в VS Code использует те же Skills, что и веб/CLI/API, и подгружает их прозрачно, без явных команд типа use skill X. ¹⁶³¹⁶⁶¹⁶⁷

Визуализация пока слабоватая: явного списка «какие skills сейчас активны» в стандартном расширении нет; это обсуждают как недостающую фичу, но поведение подтверждают как рабочее и автоматическое. ¹⁶⁵¹⁶⁸¹⁶⁹

Ты можешь:

создавать свои skills;
редактировать/тюнить любой skill;
миксовать свои и готовые из репозиториев. ¹⁷⁰¹⁷¹¹⁶⁵

Где лежат skills и как их видит Claude Code

Типовой layout (упрощённо):

~/.claude/skills/
  frontend-next15/
    SKILL.md
  design-system/
    SKILL.md
  git-commits/
    SKILL.md
  dev-server/
    SKILL.md

Claude (включая Claude Code в VS Code) сканирует каталог skills и использует name/description для решения, когда их включать. ¹⁶³¹⁶⁴¹⁶⁷
В проекте можно делать и локальные skills, если хочешь жёстко привязать к репе (например, в .claude/skills), но глобальные в ~/.claude/skills работают везде. ¹⁶⁸¹⁷²

Как тебе оформить твои 4 области в Skills

Ниже – черновая структура 4 skills под твои кейсы. Формат обобщён по примерам из best‑practices. ¹⁶⁵¹⁷¹

1. Skill: frontend + Next 15

~/.claude/skills/frontend-next15/SKILL.md

---
name: frontend-next15
description: >
  Frontend development expert for this user's projects:
  Next.js 15, React, strict separation of client/server components,
  specific folder structure and component patterns.
tags: [frontend, nextjs, react, components]
---

## Purpose

Help implement and refactor frontend code in Next.js 15 projects
following the user's conventions for:
- folder structure;
- component creation patterns;
- client/server component separation.

## Tech context

- Framework: Next.js 15
- Language: TypeScript
- UI: React function components

## Folder structure conventions

[ОПИШИ здесь свою структуру: `app/`, `components/`, `features/` и т.д.]

## Client vs server components

[Чётко опиши правила, например:
- Server components по умолчанию.
- Client components только если нужен state/effects/interaction.
- Где можно/нельзя использовать hooks и browser API.]

## Component style

[Твои требования к:
- Props (shape, naming).
- Styling (Tailwind/SC/чистый CSS).
- Разбиение на presentational/logic components, и т.п.]

## When to use this Skill

Claude SHOULD use this Skill when:
- задача связана с фронтендом, React или Next.js страницами/route handlers;
- создаются или меняются UI‑компоненты;
- обсуждается структура папок или перенос/рефакторинг компонентов.

Ключевое: жёстко и явно сформулировать, когда skill должен применяться – Claude использует description и этот раздел, чтобы решить, подгружать ли его. ¹⁶⁵¹⁶⁴

2. Skill: дизайн‑система и палитра

~/.claude/skills/design-system/SKILL.md

---
name: design-system-ui
description: >
  Design system and visual style for this user's frontend projects:
  color palette, typography, spacing, component styling rules.
tags: [design, ui, components, styling]
---

## Purpose

Ensure all new and updated UI components follow the design system:
colors, typography, spacing, radius, shadows, and interaction states.

## Color palette

[Опиши точные токены/переменные, hex/rgba + как их использовать.]

## Typography

[Шрифты, размеры, scale, line-height, где какие уровни заголовков.]

## Spacing & layout

[Правила отступов, grid/flex паттерны, контейнеры и т.п.]

## Component guidelines

- Использовать существующие primitives/atoms, где возможно.
- Не дублировать уже существующие паттерны, а расширять их.
- Для новых компонентов:
  - сначала описать API и state;
  - потом предложить структуру/стили в рамках дизайн‑системы.

## When to use this Skill

Claude SHOULD use this Skill when:
- создаются новые UI‑компоненты;
- меняется внешний вид существующих;
- обсуждаются цвета, шрифты, отступы, визуальный стиль.

Если ты часто просишь «подскажи, как лучше сделать компонент в рамках дизайн‑системы», Claude начнёт автоматически подтягивать этот skill в таких промптах. ¹⁶³¹⁶⁴¹⁶⁵

3. Skill: git commits (commit message policy)

~/.claude/skills/git-commits/SKILL.md

---
name: git-commit-style
description: >
  Enforce this user's git commit message convention and help
  craft commit messages that follow it.
tags: [git, commits, workflow]
---

## Commit message convention

[Опиши свой шаблон: Conventional Commits / свой формат, примеры good/bad.]

Пример:
- `feat(frontend): add product card component`
- `fix(api): handle 401 error for profile endpoint`
- `chore: bump dependencies`

## Rules

- ВСЕ сообщения коммитов ДОЛЖНЫ следовать этому паттерну.
- Сообщение должно описывать intent, а не implementation details.
- Не использовать общие формулировки типа "fix", "update" без контекста.

## How Claude should help

Когда пользователь просит подготовить или отредактировать commit message:

1. Прочитать diff/описание изменений.
2. Сформировать 1–3 варианта сообщения в требуемом формате.
3. Подчеркнуть, какие части диффа покрываются этим сообщением.

## When to use this Skill

Claude SHOULD use this Skill when:
- пользователь упоминает git, commit, PR, "commit message";
- запрашивает формулировку или редактирование сообщения коммита;
- просит подготовить описание изменений для VCS.

Теперь, когда ты пишешь что‑то вроде «подготовь commit message для этого diff», Claude с высокой вероятностью активирует этот skill и будет придерживаться правил без постоянных напоминаний. ¹⁶⁵¹⁶⁴¹⁷¹

4. Skill: dev server (run, stop, логи, проверки)

~/.claude/skills/dev-server/SKILL.md

---
name: dev-server-management
description: >
  Help manage local dev server: start/stop, inspect logs,
  and verify that key pages load without errors.
tags: [dev-server, logs, debugging]
---

## Environment assumptions

[Опиши:
- npm/pnpm/yarn;
- команды запуска: `pnpm dev` / `npm run dev` / `turbo dev` и т.д.;
- на каком порту обычно крутится (например, http://localhost:3000).]

## Allowed actions (when tools are available)

When Claude has shell access (Claude Code in VS Code / CLI):

- Запуск dev server:
  - Проверить, не запущен ли уже.
  - Если не запущен — выполнить [твоя команда].
- Остановка dev server:
  - Найти процесс (по команде/порту) и корректно завершить.
- Логи:
  - Читать вывод dev server;
  - Обнаруживать ошибки/stack traces;
  - Предлагать гипотезы и следующие шаги.

## Page health checks

Когда пользователь просит проверить страницу:

1. Убедиться, что dev server запущен.
2. Открыть URL (если есть соответствующий HTTP‑tool) ИЛИ
   проанализировать ошибки в логах, относящиеся к маршруту.
3. Сообщить:
   - грузится ли страница без runtime‑ошибок;
   - есть ли 5xx/4xx;
   - если есть ошибки, предложить plan их исправления.

## When to use this Skill

Claude SHOULD use this Skill when:
- пользователь говорит о dev server, "запусти/останови dev", "посмотри логи";
- просит проверить, что страницы открываются без ошибок;
- упоминает команды `dev`/`start`/`build` для локального окружения.

Важно: чтобы skill действительно мог запускать/останавливать сервер, в Claude Code должны быть разрешены shell‑tools (и соответствующие MCP, если через них). Skill сам по себе только описывает как это делать. ¹⁶³¹⁶⁴¹⁶⁷

Визуализация и контроль в VS Code

Сейчас ситуация такая:

Явного UI «список активных Skills» нет в стандартном Claude Code extension; многие просят это как фичу. ¹⁶⁵¹⁶⁸¹⁶⁹
Тем не менее:
- Skills используются «под капотом» при генерации/редактировании кода и планов. ¹⁶³¹⁶⁴¹⁶⁷
- В Plan Mode видно косвенно, что Claude следует правилам из Skills (структура, стиль, команды). ¹⁷³¹⁷⁴
Есть сторонние надстройки (например, Workflow Studio для VS Code), которые пытаются нарисовать визуальные workflow‑диаграммы для Skills/Subagents/MCP, но это уже доп.расширение, не обязательное. ¹⁷⁵¹⁷⁶

Для контроля:

Ты можешь итеративно тюнить Skills, как описано в best‑practices:
- Наблюдать поведение;
- Подкручивать формулировки (делать MUST/SHOULD более жёсткими);
- Упрощать иерархию, если Claude «теряется»; ¹⁶⁵
- Разделять Skills, если один стал слишком большим и размытым. ¹⁶⁵¹⁶⁸
Рекомендуемый Anthropic цикл: Claude A помогает писать/редактировать SKILL.md, Claude B потом работает под этим skill’ом в реальных задачах; по результатам ты снова правишь skill. ¹⁶⁵¹⁷¹

Как это использовать в твоём workflow

Создаёшь 3–4 skills, как выше, кладёшь в ~/.claude/skills/.
В проекте оставляешь CLAUDE.md для общей архитектуры/монорепы, но всё «как делать» — в Skills. ¹⁶³¹⁶⁴¹⁶⁸
В VS Code:
- Работаешь либо через встроенный терминал claude code, либо через расширение — Skills будут одинаково доступны. ¹⁷⁴¹⁶⁶¹⁷⁷
- В промптах говоришь по‑человечески («сделай компонент вот тут», «подготовь commit message», «запусти dev, посмотри, почему /dashboard падает»), без ручного выбора агентов — Claude сам будет подмешивать нужные skills.

Если хочешь, на следующем шаге могу помочь прямо из твоего существующего CLAUDE.md вытащить куски и разложить их в 4 конкретных SKILL.md под твой текущий проект. ¹⁷⁸¹⁷⁹¹⁸⁰¹⁸¹¹⁸²¹⁸³

⁂

Можно ли использовать готовые Skills и где их искать

Да, готовые Skills есть, и их уже довольно много. Использовать можно, плюс никто не мешает форкать и допиливать под себя.

Где брать готовые Skills

Основные источники:

Официальный репозиторий Anthropic: github.com/anthropics/skills — примерные skills от команды Claude (docx/pdf/xlsx/pptx, web‑testing, mcp‑builder, skill‑creator и т.д.). ¹⁸⁴¹⁸⁵
Кьюрированные подборки:
- awesome-claude-skills — curated список реп и отдельных skills. ¹⁸⁶¹⁸⁷
- claude-skills-collection — большая коллекция официальных + community skills с категориями. ¹⁸⁸
Публичные каталоги:
- skillsmp.com — поиск по 2000+ skills, предпросмотр SKILL.md, быстрый ZIP‑download и CLI‑установка для Claude Code. ¹⁸⁹

Плюс можно искать по GitHub topic claude-skills. ¹⁹⁰

Как использовать и настраивать в Claude Code / VS Code

Claude Code официально поддерживает и личные, и проектные Skills: ¹⁹¹

Личные (глобальные) — доступны во всех проектах:
- путь: ~/.claude/skills/<name>/SKILL.md
Проектные — только внутри конкретной репы:
- путь: .claude/skills/<name>/SKILL.md

Процесс такой:

Нашёл skill (например, webapp-testing или git-commit-style) в одном из репозиториев. ¹⁸⁴¹⁸⁸¹⁹²
Скопировал папку skill’а к себе в:
- ~/.claude/skills/ или в <project>/.claude/skills/. ¹⁹¹¹⁹³
Перезапустил Claude Code / сессию, после чего skill становится видимым и может автоматически грузиться. ¹⁹¹¹⁹⁴

Дальше:

Ты можешь редактировать SKILL.md, менять правила, добавлять свои примеры. Это официально поддерживаемый сценарий. ¹⁹⁵¹⁹¹
Claude использует name + description и контент SKILL.md, чтобы решать, когда именно подгружать этот skill. ¹⁹⁵¹⁹⁶

Если хочешь, можно взять, например, готовый skill для web‑тестирования или git‑workflow из репозитория Anthropics/skills и просто адаптировать его под свои фронтовые/Next 15/commit‑правила, вместо того чтобы писать с нуля. ¹⁸⁴¹⁸⁸¹⁸⁵ ¹⁹⁷¹⁹⁸¹⁹⁹²⁰⁰²⁰¹²⁰²²⁰³²⁰⁴

⁂

как сейчас решают проблему с постановкой задач для claude code? я постоянно сталикваюсь на проектах с такими ситуациями:

во время работы над одной задачей вдруг появляется дополнительное требование которое нужно сделать в отдельной таске. но не хочется вприхивать это в план текущей задачи, поэтому приходится запоминать это и держать в голове
некоторые задачи большие достаточно. я всегда исполльзую plan mode. однако часто бывает, что когда делаем определеннную фазу в плане - уходим глубоко в только эту часть и для нее нужно составлять новый более детальный план и итерировать несколлько раз. в итоге основной главный план теряется
делаю ресеч в Claude Desktop предварительно прежде чем начать имплементировать это уже в коде с Claude code. Обычно результатом появляется список требований и способ имплементации. Приходится просить Claude Desktop сохранить это как MD файл в проект. А потом говорить Claude Code в начале новой сесиии - прочитай таску в файле... Еще усугубляется если результатом ресеча становится несколько идей которые нужно реализовать, но в разное время. Приходится думать где сохранять описание тасок к которым приду потом позже, через месяц.
бывает просто пока делаю одну задачу - вижу место где можно что-то улучшить. Но это но нужно добавить в "бэклог" а не делать прямо сейчас.
какие-то домены проекта имеют общую логику но раскиданны по разным папкам и файлам. Они разрабатываются в течение 3х - 5 месяцев и может больше. Обычно я сооздаю под них Claude.md файл локально в какой-то папке и там описываю постановку задачи, архитектуру и связанные файлы. Затем туда помещаю план разработки (глобальный, положим там 10 задач на 2 месяца). Затем когда что-то конкретное нужно сделать говорю Claude Code - прочитай этот файл, найди соотвествующий код, пойми текущий статус. Проблема с этим подходом, что файл быстро устаревает по мере прогресса. Особенно если отходим от начального плана. Этот файл лежит в одном месте, но связанные фичи лежат в разных других папках. Какие-то задачи положим уже сделанны и по ходу приняты какие-то решения или соглашения по дальнейшей разработке. Но начиная новую сессию - у Клода нет этой информации, приходится или писать ему или постоянно обновлять Claude.md файл. В идеале было бы если бы клод мог посмотреть все сделанные таски по данному эпику например и прочесть принятые решения в логах задач или в отдельной доке, которая пополняется (но проще мне кажется просто в задаче писать когда она готова, что теперь делаем так)

У нас есть простой таск менеджер в команде (мы просто ведем список задач в Slack), на других проектах бывает Jira или Trello - но это все для людей. А хотелось бы иметь какой-то простой способ иметь список задач для проекта в максимально удобной для AI форме с возможностью команд - "добавь задачу в трэкер", "

Отлично — ты описал именно то, что сейчас решают в сообществе. Это не официальная best-practice от Anthropic, но уже есть кристаллизовавшиеся паттерны, и они хорошо работают.

Архитектура для управления задачами в долгих проектах

Вот система, которую рекомендуют опытные разработчики: это комбо из 3–4 артефактов в проекте, которые работают вместе.

1. ROADMAP.md — живой план проекта²⁰⁵

Основная идея: один файл, который Claude сам обновляет по ходу работы.

# Project Roadmap

## High Priority
- [ ] **Task Name** - Description
- [-] **In Progress Task** - Description 🏗️ 2026/01/05
- [x] **Completed Task** - Description ✅ 2026/01/04

## Medium Priority
- [ ] Task 2

## Low Priority
- [ ] Tech debt item

## Recently Completed (Archive)
- [x] Task ✅ 2026/01/01

Как это работает:

Первое, что Claude делает в новой сессии — читает ROADMAP.md.²⁰⁵
По ходу работы он сам обновляет чекбоксы и даты.
Когда завершена фаза — item переходит в "Recently Completed".
В CLAUDE.md ты пишешь инструкцию: "Always check ROADMAP.md first at the start of any session."²⁰⁵

Преимущества:

Контекст не теряется между сессиями.
Отслеживаемый прогресс.
Claude сам оркеструет приоритеты.

Это решает твою проблему с тем, что большой план теряется при погружении в фазу. ROADMAP остаётся живым документом всегда.²⁰⁵

2. ADR (Architecture Decision Records) — почему, а не что²⁰⁶²⁰⁷²⁰⁸²⁰⁹

Когда ты разрабатываешь фичу 3–5 месяцев и принимаешь решения по пути (меняешь подход, выбираешь между вариантами) — эти решения нужно записывать, пока контекст горячий.

Структура ADR проста:

docs/adr/
├── 001-use-server-components-for-data-fetching.md
├── 002-adopt-zod-for-validation.md
└── 003-why-we-separated-ui-and-logic-layers.md

Каждый файл содержит:

# ADR-001: Use Server Components for Data Fetching

**Status**: Adopted | Proposed | Superseded

**Date**: 2025-01-05

**Context**
We needed a way to fetch product data without N+1 queries...

**Decision**
Use Next.js 15 Server Components for all data-heavy pages.

**Rationale**
- Eliminates client-side data fetching overhead
- Keeps secrets server-side
- Reduces bundle size

**Consequences**
- Harder to debug in browser
- Requires understanding of async components
- Migration path needed for old pages

**Alternatives Considered**
- React Query with ISR
- Hybrid approach

Как Claude помогает:

Ты в конце сессии просишь: "Create an ADR for the decision we just made about folder structure."
Claude сканирует diff, понимает решение и пишет ADR.²⁰⁷²⁰⁹
В следующий раз, когда новая задача касается этого домена, Claude читает ADR и знает почему это так, а не просто видит код.

Это решает проблему: "какие-то решения приняты, но новая сессия о них не знает". ADR это фиксит.²⁰⁷

3. TASKS.json или Trello/Jira для отслеживания мелких таск (опционально)²¹⁰

Для inline-задач (найденных по ходу): можно держать JSON или привязать к Trello/TaskWarrior.

{
  "tasks": [
    {
      "id": 1,
      "title": "Fix broken link in docs",
      "domain": "frontend",
      "status": "backlog",
      "priority": "low",
      "context": "Found while working on hero component"
    },
    {
      "id": 2,
      "title": "Refactor auth module",
      "domain": "backend",
      "status": "backlog",
      "priority": "medium"
    }
  ]
}

Как это помогает:

Когда в процессе работы видишь улучшение → говоришь Claude: "Add task: 'Refactor X' to TASKS.json with priority low."
Claude не отвлекается, просто добавляет в JSON.
Потом ты или Claude можешь бросить взгляд на TASKS.json и выбрать, что делать дальше.²¹¹²¹⁰

4. Глобальный CLAUDE.md с инструкциями по workflow²¹²²⁰⁵

# Project Context

## Roadmap Management
**IMPORTANT**: Always check ROADMAP.md first at session start.

When completing a task:
1. Update checkbox status
2. Add timestamp (use `date "+%Y/%m/%d"`)
3. Move completed item to "Recently Completed" section if phase is done

## Architecture Decisions
When you make significant decisions (folder structure, tech choices, patterns):
1. Create or update an ADR in docs/adr/
2. Reference it in code comments if relevant

## Inline Tasks
If you discover something that should be done but isn't part of current task:
- Don't interrupt current work
- Add to TASKS.json with status "backlog"

## Task Execution Pattern
1. Read ROADMAP.md
2. Pick high-priority task
3. Read relevant ADRs for context
4. Create detailed plan (phases.md or inline in Plan Mode)
5. Execute, testing frequently
6. Update ROADMAP and create ADR if needed
7. Commit with conventional message

Как это применить к твоим 4 доменам (frontend, design, git, dev-server)

Домен: Frontend + Design System + Git

ROADMAP.md структура:

## Frontend: Next 15 Components System (3-month epic)

### Phase 1: Foundation (60% done)
- [x] Set up component folder structure ✅ 2026/01/01
- [x] Create Button, Input primitives ✅ 2026/01/02
- [-] Build Modal compound component 🏗️ 2026/01/05

### Phase 2: Forms (Backlog)
- [ ] Form validation with Zod
- [ ] Complex multi-step forms

### Architecture Decisions
See: docs/adr/001-server-client-separation.md

### Design System Decisions
See: docs/adr/002-color-token-structure.md

ADRs:

docs/adr/
├── 001-server-components-for-data.md
├── 002-client-components-for-interactivity.md
├── 003-why-folder-structure-is-app/features/ComponentName.
└── 004-design-token-palette-and-naming.md

Теперь, когда Claude стартует в следующую сессию и видит "Нужно сделать Modal", он:

Читает ROADMAP → понимает, что это Phase 1.
Читает ADR-001 и ADR-002 → понимает, когда server vs client.
Читает ADR-003 → знает структуру папок.
Читает ADR-004 → знает цветовую палитру и именование.
Начинает работу с полным контекстом.²⁰⁷²⁰⁵

Домен: Git commits

Отдельный ADR:

# ADR-005: Commit Message Convention

**Decision**: Use Conventional Commits

**Rules**:
- feat(scope): description
- fix(scope): description
- chore: description

**Examples**:
- feat(frontend): add modal component
- fix(api): handle 401 error

Теперь, когда ты просишь "prepare commit message", Claude читает этот ADR и делает правильно.²¹³²¹²

Домен: Dev Server

В CLAUDE.md:

## Dev Server Management

When asked to run dev server:
1. Check if already running on port 3000
2. If not, run: `pnpm dev`
3. Wait for "ready - started server on 0.0.0.0:3000"
4. Report back with timestamp

When asked to check page health:
1. Start server if needed
2. Look at logs for errors
3. Report: "Page /dashboard loaded successfully" or describe error

Это просто инструкция в CLAUDE.md; отдельного ADR может не быть, так как это operational knowledge, не архитектурное решение.²¹²

Поток для исследовательских задач

Твоя проблема: "Делаю research в Claude Desktop → много идей → нужно сохранить".²¹¹

Решение:

Делаешь research в Claude Desktop.
В конце просишь: "Create a TASK-.md file with these ideas and their dependencies."
Получаешь структурированный файл с разбиением на таски:

# Research: Payment Integration Ideas

## Task 1: Stripe Setup (Do first)
- Description
- Dependencies: None
- Effort: 2 hours
- File: TASKS/payment-task-1.md

## Task 2: Error Handling (After Task 1)
- Description
- Dependencies: Task 1
- Effort: 4 hours
- File: TASKS/payment-task-2.md

## Task 3: Webhooks (After Task 2)
- Description
- Dependencies: Task 2
- Effort: 6 hours
- File: TASKS/payment-task-3.md

Положил в TASKS/ папку. Потом в ROADMAP добавляешь ссылку на эту серию.²¹¹

Когда вернёшься через месяц, твой CLAUDE.md говорит Claude: "Check ROADMAP first", а в ROADMAP ссылка на серию Task'ов. Контекст не потеряется.²⁰⁵

Инструмент: TodoRead/TodoWrite в Claude Code

В Claude Code есть встроенные tools TodoRead и TodoWrite. Они создают локальный список дел, который Claude видит и обновляет.²¹⁴

Это не замена ROADMAP/ADRs, но дополнение для текущей сессии: shows Claude's work plan and enables mid-task steering.²¹⁴

Почему это работает лучше, чем агенты

ROADMAP = глобальная карта (вместо того чтобы держать в голове).
ADRs = объяснения решений (Claude не спрашивает "почему так", он знает).
TASKS.json = inbox для новых идей (не прерывает текущую работу).
CLAUDE.md = инструкции по workflow (Claude следует паттернам без напоминаний).

Всё это простая структура файлов, которую Claude может читать и обновлять. Никаких агентов. Никаких координаторов. Просто жёсткий контекст.²¹²²⁰⁷²⁰⁵

Быстрый стартовый набор для твоего проекта

Создай в корне:

.
├── CLAUDE.md                 (твой текущий)
├── ROADMAP.md               (NEW - живой план)
├── docs/
│   └── adr/                 (NEW - решения)
│       ├── 001-server-components.md
│       ├── 002-folder-structure.md
│       └── 003-commit-convention.md
├── TASKS.json               (NEW - inbox для новых идей)
└── TASKS/                   (NEW - детальные исследования)
    └── payment-research.md  (пример)

В CLAUDE.md добавь сверху:

## Session Start Protocol

1. **Always read ROADMAP.md first** to understand priorities and progress
2. **Check relevant ADRs** in docs/adr/ for architectural context
3. **Review TASKS.json** for any pending backlog items
4. Use Plan Mode for any task > 30 minutes
5. At end of session: update ROADMAP, create/update ADRs if decisions made

[Rest of your CLAUDE.md...]

Этого достаточно. Claude сразу начнёт читать ROADMAP, следить за ADRs, и твой контекст не будет теряться.²¹²²⁰⁵ ²¹⁵²¹⁶²¹⁷²¹⁸²¹⁹²²⁰²²¹²²²²²³²²⁴

⁂

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

возможно это было летом. но я намучился и перестал это делать. плюс мое отличие что у нас проект достаточно крупный и одного roadmap не достаточно - нужно по нескольким направлениям держать свой собственный и соответсвенно клод при старте сессии должен понимать что именно смотреть и обновлять. короче все равно много ручной рутины. и это при том, что в целом клод очень не плохо умеет описывать задачи и суммаризировать решения. как будето ему не хватает какого-то менеджера или MCP для более простой работы (чтоб не тратить токены и время на чтение и изменение файлов а просто чтоб он мог взять список задач, сказать что задача готова и дать репорт) есть ли что-то такое?

Ура! Да, это как раз то, что тебе нужно. И ты совершенно прав — это именно MCP + task-manager система.

MCP для task management уже есть

Есть несколько готовых решений, которые как раз решают твою проблему: Claude забывает обновлять документы, теряет контекст между сессиями, и тратит токены на чтение/запись файлов.²²⁵²²⁶

1. ProjectHub-MCP (самое полнофункциональное)

Это то, что создал разработчик специально для этой проблемы.²²⁶

Что оно делает:

Claude может добавлять/обновлять задачи, менять статусы через простые команды, без чтения/записи файлов.
Хранит всё в PostgreSQL (или другой БД), не в markdown.
Создаёт progress-репорты автоматически.
Синхронизирует с git (видит твои commits и обновляет task status).
Поддерживает 17+ MCP servers одновременно.
Есть простой UI dashboard.

Установка:

git clone https://github.com/anissb/ProjectHub-Mcp
docker-compose up -d  # Всё, development ready

Потом в твоём .claude/config.json (или .mcp.json) добавляешь:

{
  "mcpServers": {
    "projecthub": {
      "command": "node",
      "args": ["path/to/ProjectHub-Mcp/server.js"]
    }
  }
}

Как работает с Claude Code:

Ты: "Я начинаю auth-refactor, это высокий приоритет"

Claude:
1. Создаёт task: { id: 42, title: "auth-refactor", status: "in-progress", priority: "high" }
2. Начинает time-tracking (Pomodoro, если нужен)
3. Работает над кодом

Ты: "Готово, создай progress-report"

Claude:
1. Достаёт все completed tasks этой сессии из БД
2. Смотрит твои commits (синхронизирует автоматически)
3. Генерирует report: "Completed: auth-refactor (4h 22m). Bugs found: 3 (all fixed). Tests: 42/42 passing"

Ты: "Добавь task: 'Optimize login flow' в backlog"

Claude: ✓ Добавлено в БД, priority: medium, domain: backend

Преимущество: Только простая команда → Claude делает, не тратя токены на чтение/запись файлов.²²⁶

2. TaskManager MCP (минималистичный, просто работает)

Более простой, но очень эффективный: MCP server с queue-based таск-системой.²²⁷²²⁸²²⁹

Установка:

npm install @kazuph/mcp-taskmanager

# Или в claude_desktop_config.json:
"mcpServers": {
  "taskmanager": {
    "command": "npx",
    "args": ["-y", "@kazuph/mcp-taskmanager"]
  }
}

Как использовать:

Ты: "План для frontend-epic: 
- Task 1: Setup Design System
- Task 2: Create Button component
- Task 3: Integrate with form
"

Claude: Creates queue and executes sequentially...

Ты: "Mark task 1 as complete, what's next?"

Claude: "Task 1 ✓ completed. Next: Task 2: Create Button component. Here's the plan..."

Ты: "Create progress report"

Claude: "✓ 1/3 tasks done. Estimated time remaining: 6h. Completed: Design system setup..."

Минус: Меньше фич, чем ProjectHub. Плюс: Простейшая установка, никакой БД.²²⁸²²⁹²²⁷

3. claude-task-master (для Cursor/AI-driven development)

Парсит PRD-документы, автогенерирует задачи, управляет приоритизацией.²³⁰²³¹

Подойдёт, если ты часто работаешь с продуктовыми требованиями и хочешь автоматически генерировать задачи из них.²³⁰

Что выбрать именно для твоего кейса

Твоя проблема:

Несколько домен/эпиков, каждый со своим roadmap.
Claude забывает обновлять, нужна автоматическая система.
Нужны простые команды, без ручного чтения/обновления файлов.
Долгие проекты (3–5 месяцев), нужны decision-логи и синхронизация с git.

Рекомендация: ProjectHub-MCP²²⁶

Почему:

Multi-domain support: можно держать несколько эпиков / roadmap'ов параллельно.
Автоматическая синхронизация с git: Claude видит твои commits и сам обновляет task-статус.
ADR/decision-трекинг: есть встроенная система для логирования решений (как раз то, что тебе нужно).
Нет файлов: всё в БД, Claude не тратит токены на markdown-файлы.
UI dashboard: можно посмотреть прогресс не выходя из VS Code (браузер).
Остаётся читаемым: если потребуется, можно экспортировать в markdown для документации/отчёта.²²⁶

Быстрая работа

После установки ProjectHub:

Сессия 1 (День 1):
Ты: "New epic: 'Build Payment System'. Tasks: 
1. Stripe integration
2. Error handling
3. Webhook processing
Priorities: 1=high, 2=medium, 3=medium"

Claude: ✓ Эпик создан, tasks in queue

--- Ночь, две недели прошло ---

Сессия 17 (День 15):
Ты: "Resume Payment System epic. What's our status?"

Claude: 
"✓ Epic: Build Payment System
- Task 1: Stripe integration [COMPLETED 2026/01/05]
- Task 2: Error handling [IN PROGRESS 🏗️]
- Task 3: Webhook processing [BACKLOG]

Since last session (14 days):
- 12 commits related to payment
- 3 ADRs recorded:
  - ADR-1: Why we chose Stripe over PayPal
  - ADR-2: Error handling strategy (sync vs async)
  - ADR-3: Webhook validation approach

New blocker found?
Decisions made?
Continue Task 2 or want to review decisions?"

Никаких потерянных планов. Никаких забытых файлов. Claude автоматически видит контекст через MCP.²²⁶

Как организовать 4 твои домена

В ProjectHub можно делать:

domains/
├── frontend-next15/
│   ├── epic: "Next.js 15 Components System"
│   ├── tasks: [task1, task2, task3...]
│   ├── adrs: [adr-001-server-components, adr-002-folder-structure]
│   └── domain-skill-link: `~/.claude/skills/frontend-next15/`
│
├── design-system/
│   ├── epic: "Design System & Tokens"
│   ├── tasks: [task1, task2...]
│   └── adrs: [adr-001-token-structure]
│
├── git-workflow/
│   ├── epic: "Commit & PR automation"
│   └── adrs: [adr-001-conventional-commits]
│
└── dev-server/
    ├── epic: "Dev environment setup & health checks"
    └── adrs: [adr-001-port-3000-setup]

Claude видит все эпики, знает приоритеты, и когда ты говоришь "start frontend task #3", он:

Читает task-описание из БД (не файла).
Загружает соответствующий ADR из БД (не файла).
Подгружает skill frontend-next15 автоматически (потому что привязан к домену).
Начинает работу с полным контекстом, без токен-траты на файловые операции.²²⁶

Установка: пошагово для твоего кейса

Клонируешь ProjectHub:

git clone https://github.com/anissb/ProjectHub-Mcp ~/ProjectHub-Mcp
cd ~/ProjectHub-Mcp
docker-compose up -d

Добавляешь в Claude Code (.mcp.json в корне проекта):

{
  "mcpServers": {
    "projecthub": {
      "command": "node",
      "args": ["/path/to/ProjectHub-Mcp/server.js"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/projecthub",
        "API_PORT": "3001"
      }
    }
  }
}

В CLAUDE.md добавляешь:

## Task Management via ProjectHub MCP

Available commands:
- "Add task: [description] to [domain] with priority [high/medium/low]"
- "Mark task [id] as complete"
- "Show status of [domain] epic"
- "Create progress report"
- "Record decision: [ADR description]"

Always:
1. Check epic status at session start
2. Create ADR when making architecture decisions
3. Update task status when done

Domains: frontend-next15, design-system, git-workflow, dev-server

Перезапускаешь Claude Code — готово. MCP подхватится, и теперь ты можешь:

Ты: "What tasks are pending in frontend-next15?"
Claude: [Читает из ProjectHub БД, не из файлов]

Ты: "I finished the Modal component, mark task #7 as done and create an ADR about its implementation"
Claude: ✓ Task #7 → complete
         ✓ ADR created

Никаких забытых обновлений. Контекст сохраняется.²²⁶

Это то, что тебе нужно. ProjectHub есть именно для таких случаев: долгие проекты с несколькими эпиками, где Claude постоянно забывает обновлять, и нужна система, которая делает это за него через инструменты MCP, а не файлы.²²⁶ ²³²²³³²³⁴²³⁵²³⁶²³⁷²³⁸²³⁹²⁴⁰²⁴¹²⁴²²⁴³²⁴⁴

⁂

100 KiB Raw Permalink Blame History Unescape Escape

сейчас январь 2026

Реальная ситуация с Subagents и Skills в Claude Code (январь 2026)

Что произошло: краткая хронология

Почему subagents "не зашли"

1. Отсутствие видимости (твоя главная боль)

2. Потеря контекста

3. Координация — твоя боль

4. Оверхед сложности

Почему Skills получили больший adoption

1. Философский сдвиг от Anthropic

2. Простота и прозрачность

3. Портативность

4. Компонуемость

5. Network effects

Что на самом деле нужно делать

Для мелких/средних проектов (твой случай):

Когда агенты (вообще) имеют смысл

Практические рекомендации для твоей ситуации

1. Избавься от project-level agents

2. Создай 2-3 skills вместо агентов

3. Используй Plan Mode активно

4. Leverage context engineering

Что говорит Anthropic официально

Итоговая правда

для чего тогда вообще нужны агенты? это тупиковая ветка или или есть какието кейсы где без них никак?

Когда агенты реально нужны

1. Длинные, многосессионные задачи

2. Автономная работа «поговорить + сделать»

3. Когда workflow слишком ветвистый для «if‑else»

Когда тебе, как индивидуалу, агенты почти не нужны

Не тупик, а нишевая штука

Если говорить конкретно для тебя

ок. но просто интересно как эту агентскую систему строить? выглядит как сложный кейс где нужен отдельный фреймворк. кто и как сетапит такую систему?

Базовая архитектура агентской системы

1. Не с агентов, а с workflows

2. Orchestrator–worker как основной «мульти‑агент» паттерн

Кто это настраивает и как выглядит стек

1. В Enterprise / продуктовых командах

2. В «интеграторах» / консалтинге

3. В open‑source / dev‑ориентированных проектах

Как бы это выглядело в твоём кодерском контексте

Почему так ощущается «как отдельный фреймворк»

да не, не надо

Как работают Skills в Claude/VS Code

Где лежат skills и как их видит Claude Code

Как тебе оформить твои 4 области в Skills

1. Skill: frontend + Next 15

2. Skill: дизайн‑система и палитра

3. Skill: git commits (commit message policy)

4. Skill: dev server (run, stop, логи, проверки)

Визуализация и контроль в VS Code

Как это использовать в твоём workflow

Можно ли использовать готовые Skills и где их искать

Где брать готовые Skills

Как использовать и настраивать в Claude Code / VS Code

как сейчас решают проблему с постановкой задач для claude code? я постоянно сталикваюсь на проектах с такими ситуациями:

Архитектура для управления задачами в долгих проектах

1. ROADMAP.md — живой план проекта205

2. ADR (Architecture Decision Records) — почему, а не что206207208209

3. TASKS.json или Trello/Jira для отслеживания мелких таск (опционально)210

4. Глобальный CLAUDE.md с инструкциями по workflow212205

Как это применить к твоим 4 доменам (frontend, design, git, dev-server)

Домен: Frontend + Design System + Git

Домен: Git commits

Домен: Dev Server

Поток для исследовательских задач

Инструмент: TodoRead/TodoWrite в Claude Code

Почему это работает лучше, чем агенты

Быстрый стартовый набор для твоего проекта

MCP для task management уже есть

1. ProjectHub-MCP (самое полнофункциональное)

2. TaskManager MCP (минималистичный, просто работает)

3. claude-task-master (для Cursor/AI-driven development)

Что выбрать именно для твоего кейса

Быстрая работа

Как организовать 4 твои домена

Установка: пошагово для твоего кейса

100 KiB

Raw Permalink Blame History

1. ROADMAP.md — живой план проекта²⁰⁵

2. ADR (Architecture Decision Records) — почему, а не что²⁰⁶²⁰⁷²⁰⁸²⁰⁹

3. TASKS.json или Trello/Jira для отслеживания мелких таск (опционально)²¹⁰

4. Глобальный CLAUDE.md с инструкциями по workflow²¹²²⁰⁵