Ты все еще копируешь задачи руками? Серьезно?
Каждый раз, когда ты кидаешь в Claude Code ссылку на тикет в Jira или Linear, ты делаешь одну и ту же глупость - тратишь токены на то, чтобы модель сама разобрала HTML страницы, вычленила описание, комментарии, acceptance criteria. А потом она делает это снова для следующей задачи. И снова. В итоге половина лимита уходит не на код, а на парсинг веб-форм.
Я перепробовал кучу подходов: ручной копипаст, curl страницы, даже писал скрипты на Python для выгрузки через API. Но всё это ломается, когда задач становится больше трех, а контекст начинает перетекать из одного спринта в другой. Тогда я наткнулся на идею, которую уже используют в лучших практиках работы с Claude Code — дать агенту доступ к структурированному контексту через RAG, но не через файлы, а через таск-трекер.
Так родился TaskCtx — открытый плагин (MIT, лежит на GitHub), который подключается к Claude Code через MCP (Model Context Protocol) и автоматически собирает контекст со всех задач, которые ты указал в запросе. Внутри — RAG пайплайн, эмбеддинги от text-embedding-3-small (OpenAI) или локального BGE-small-en-v1.5, и векторное хранилище на основе FAISS. Всё это работает локально, данные не улетают на сторонние сервера (кроме эмбеддингов, если выбрал OpenAI).
Суть: ты пишешь в Claude Code что-то вроде «добавь поле company_id в модель User, задача TASK-1234, контекст из TASK-1200 и TASK-1215», и плагин сам подтягивает описание, комментарии, код из прикрепленных PR и acceptance criteria. Агент получает чистый structured context, а не сырой HTML.
Почему RAG, а не просто API-запрос?
Тут есть тонкий момент. Если просто дергать Jira API и пихать JSON ответа в промпт, ты получишь кучу мусора: системные поля, неизвестные типы задач, историю изменений. Токены сгорят, а модель утонет в шуме.
RAG решает это двумя вещами:
- Индексация и чанкинг - каждая задача режется на смысловые блоки (описание, комментарии, вложения). Только релевантные куски попадают в контекст.
- Семантический поиск - ты можешь указать три задачи, а плагин выберет из них только те части, которые действительно относятся к делу. Экономия токенов — до 60%.
Если хочешь понять, как это работает под капотом, советую глянуть сравнение 21 инструмента сборки контекста — там подробный бенчмарк и цифры по экономии.
Как это выглядит на практике
Плагин работает как MCP-сервер. Claude Code обращается к нему через инструменты:
fetch_task— получить полную задачу по ключу.related_context— найти похожие задачи по смыслу (RAG по всем проиндексированным тикетам).search_tasks— полнотекстовый поиск по названиям и описаниям.
Пошаговая настройка TaskCtx
Сейчас разложу по полочкам, чтобы ты не наступал на те же грабли, что и я.
1 Клонируем репозиторий и устанавливаем зависимости
git clone https://github.com/taskctx/taskctx-mcp.git
cd taskctx-mcp
pip install -r requirements.txt
Всё ставится в локальное окружение. Никаких Docker (если не хочешь). На выходе получаешь server.py и папку indexer.
2 Настраиваем интеграцию с таск-трекером
Создай файл config.yaml в корне:
# config.yaml
tracker:
type: jira # или linear, github-issues
api_url: https://your-domain.atlassian.net
email: your-email@example.com
api_token: ${JIRA_API_TOKEN}
embedding:
provider: openai # или local
model: text-embedding-3-small
# для local: model: BAAI/bge-small-en-v1.5
vector_store:
path: ./data/vector_index
indexing:
refresh_interval: 300 # секунд, через сколько переиндексировать задачи
chunk_size: 512
⚠️ Предупреждение: если используешь OpenAI для эмбеддингов, каждый запрос к таск-трекеру будет генерировать затраты на API. При большом количестве задач (1000+) лучше поднять локальную модель. Плагин поддерживает sentence-transformers. Тесты показывают, что BGE-small-en-v1.5 дает accuracy 92% против 95% у OpenAI — разница несущественна для тикетов.
3 Скармливаем плагину список задач для индексации
Запускаем первичную индексацию. Плагин пройдется по всем проектам (или по указанным JQL-фильтрам) и соберет последние 200 задач. Если у вас в проекте 10 000 тикетов — лучше ограничить выборку, чтобы не ждать часами.
python indexer/build_index.py --project "DEV" --max-tasks 500
Индекс сохранится в ./data/vector_index. Далее плагин будет автоматически подтягивать новые/измененные задачи каждые 5 минут (параметр refresh_interval).
4 Подключаем MCP-сервер к Claude Code
В файле конфигурации Claude Code (обычно ~/.claude/claude_desktop_config.json) добавляем запись:
{
"mcpServers": {
"taskctx": {
"command": "python",
"args": ["path/to/taskctx-mcp/server.py"],
"env": {
"JIRA_API_TOKEN": "токен"
}
}
}
}
Перезапускаем Claude Code. Теперь в списке доступных инструментов появится taskctx.
5 Тестируем запросом
Пишем в чат: «нужно добавить валидацию email при регистрации. Подробности в задаче DEV-421, похожие реализации были в DEV-400 и DEV-390»
Claude Code вызовет fetch_task для DEV-421, а затем related_context для двух других. В контекст попадут только релевантные куски: описание бага, acceptance criteria, комментарии тимлида. Модель видит структурированные данные и сразу пишет рабочий код.
Грабли, на которые я наступил (и ты наступишь)
Плагин открытый, но это не значит, что он из коробки пашет идеально. Вот три проблемы, которые я выловил за месяц эксплуатации.
1. Задачи с вложениями — убийца контекста
Если в тикете висит скриншот или PDF с техзаданием, плагин по умолчанию не пытается его обработать. Он просто игнорирует вложения. Пришлось допилить: теперь на каждый файл изображения вызывается OCR (через Tesseract) или парсинг текста из PDF. Но это сильно замедляет индексацию. Решение — включать обработку вложений только для избранных тикетов через метку image:parse в Jira.
2. Если в команде используют несколько трекеров
У нас часть задач висит в Linear, часть в GitHub Issues. Плагин умеет подключаться только к одному инстансу за раз. Я сделал два экземпляра сервера (taskctx-linear и taskctx-github) и прописал оба в конфиг Claude Code. Но тогда каждый запрос дергает два сервера — это избыточно. В итоге перевел всё на Linear, а GitHub Issues дублирую через вебхуки.
Кстати, если хочешь собирать контекст не только из трекера, но и из документации, посмотри Context7 MCP для работы с актуальной документацией — он отлично закрывает эту нишу.
3. RAG иногда подсовывает не те куски
Семантический поиск — штука вероятностная. Если в двух задачах похожие описания, но разная суть, RAG может смешать контекст. Чтобы снизить риск, я добавил в плагин брифинг-шаг — перед тем как отдать контекст, модель (той же LLM) проверяет релевантность каждого чанка. Это замедляет ответ на 1–2 секунды, но резко повышает точность.
Подробнее про этот подход я писал в статье о Contextrie — брифинг-шаге для локальных агентов. Рекомендую внедрить аналогичный фильтр.
Когда этот плагин реально экономит токены (и нервы)
Я замерил несколько сценариев на своем проекте с ~300 задач в активных спринтах:
| Сценарий | Без TaskCtx (токены) | С TaskCtx (токены) | Экономия |
|---|---|---|---|
| Реализация фичи по одной задаче | 4500 | 2100 | 53% |
| Рефакторинг с контекстом трех задач | 12800 | 4900 | 62% |
| Code review с ссылкой на тикет | 3500 | 1200 | 66% |
Цифры, конечно, зависят от плотности контекста, но тренд очевиден: плагин окупает время на настройку уже за неделю активной разработки.
А как же пять механизмов памяти Claude Code?
Ты можешь спросить: зачем мне внешний плагин, если у Claude Code есть свои механизмы памяти? Отвечу: те пять механизмов работают в рамках одной сессии и не умеют обращаться к внешним API (без кастомных инструментов). TaskCtx расширяет возможности: он дает агенту доступ к динамическому контексту из трекера, который меняется каждые несколько минут (коллеги комментируют задачу, добавляют критерии).
Можно ли заменить TaskCtx связкой из других опенсорсных инструментов?
Да, конечно. Например, ты можешь взять локальный семантический поиск srag, написать коннектор к Jira API и скормить результаты в Claude Code. Но зачем изобретать велосипед, если TaskCtx уже делает это с учетом специфики трекеров: умеет обрабатывать кастомные поля, JQL-фильтры, вложения, и поставляется с готовыми промптами?
К слову о промптах — плагин использует готовые шаблоны для RAG, которые снижают галлюцинации. Если будешь писать свой велосипед, обязательно забери их.
Коротко: кому это реально нужно?
- Командам с плотным спринтом — когда задачи перетекают одна в другую, контекст вручную не удержишь.
- Тем, кто платит за Claude Code Pro — экономия токенов снижает переключения на медленную модель.
- Разработчикам, которые хотят оставить модель в курсе последних изменений в трекере — без ручного копипаста.
Если ты работаешь один над pet-проектом, плагин тоже пригодится: он избавляет от необходимости держать в голове, о чем была задача трехнедельной давности.
Неидеально, но лучше, чем ничего
У TaskCtx есть недостатки: он не умеет парсить Confluence страницы (пока), для больших проектов с тысячами задач индексация жрет память, а без брифинг-шага точность проседает. Но зато он открытый, можно форкнуть и допилить под себя. И судя по тому, как быстро развивается экосистема Claude Code (уже больше 200 MCP-серверов на июнь 2026), через полгода нас ждут еще более умные интеграции.
Советую не ждать идеала, а взять плагин прямо сейчас, подкрутить конфиг под свои процессы — и забыть о ручном сборе контекста навсегда. Первый же день с TaskCtx покажет, сколько времени ты тратил на копирование тикетов.
Бонус: В репозитории есть готовый GitHub Action, который автоматически обновляет индекс при изменении задачи в Jira (через вебхук). Не забудь его включить, иначе индекс будет устаревать на 5 минут.
FAQ и возможные ошибки
- Ошибка: «MCP server not found»
- Проверь путь к
server.pyв конфиге. Частая причина — абсолютный путь не совпадает. Используй$(pwd)/taskctx-mcp/server.pyв Unix или полный путь в Windows. - Ошибка: «Index is empty»
- Убедись, что у плагина есть доступ к трекеру (права на чтение задач). Проверь API-токен. Или запусти индексацию вручную с
--force. - Как переключить трекер с Jira на Linear?
- В конфиге поменяй
type: jiraнаlinear, укажи API-ключ Linear. Переиндексируй заново (старый индекс удали). - Плагин не видит задачи из других проектов
- По умолчанию он индексирует только те проекты, которые явно указаны в конфиге. Добавь список
projects: [DEV, OPS]под разделindexing.