Додатки
Версія 2.1.0. Аддони — розширення основної методології Deep Work Plan. Чотири з пʼяти є опційними та ніколи не потрібні для відповідності — репозиторій без опційних аддонів повністю AI-first і відповідає DWP. Кожен опційний аддон пропонується під час онбордингу, явно приймається або відхиляється, а після прийняття узгоджується з наявним налаштуванням замість його знищення. Один компонент є заявленим винятком: починаючи зі стандарту 2.3.0 локальний огляд AI Diff Reviewer є частиною обовʼязкового базового рівня — онбординг його встановлює, і кожен Final Review його запускає — тоді як його CI-поверхня лишається опційною.
Контракт аддона
Кожен shipping-аддон постачає чотири обовʼязкові компоненти:
| Компонент | Призначення |
|---|---|
| Spec | Нормативний опис RFC-2119 того, що надає аддон і що означає «відповідність цьому аддону» |
| Reasoning templates | Шаблони, які агент заповнює, міркуючи про stack цільового репозиторію — не copy-paste |
| Onboarding hook | Точка входу SKILL.md, яку потік onboard викликає після прийняття розробником |
| Validation step | Чекліст, що підтверджує правильне застосування аддона |
Виявлення: потік onboard перераховує skills/deepworkplan/addons/ і представляє кожен аддон як опційний крок у Phase 7b, після основного scaffolding.
Shipping-аддони (пʼять)
Сьогодні доступні пʼять аддонів — чотири опційні плюс обовʼязковий локальний огляд. Кожен має сторінку каталогу kit з деталями для користувача та нормативну spec у скілі Deep Work Plan.
Devcontainer (перший аддон)
Compose-налаштування .devcontainer/ + docker/, виведене з виявленого stack.
- Сторінка kit: Devcontainer
- Що додає: персистентні томи auth AI-CLI (Claude, Codex, Cursor, gh, Dailybot),
dailybot-project-network,DOCKER_DEV_ENV=vscode, аліаси валідації (codecheck,check,fix,test), гігієна секретів public-OSS - Поведінка: ~85% стабільного каркасу; ~15% виведено per stack. Наявні devcontainers узгоджуються, ніколи не затираються
- Коли пропонувати: більшість репозиторіїв з Docker або сервісами, що виграють від ізольованого dev-контейнера
Dailybot (другий аддон)
Опційне підключення до команди Dailybot розробника для видимості прогресу агента.
- Сторінка kit: Dailybot — повна довідка можливостей
- Що підключає DWP-аддон: чотири звіти життєвого циклу плану (kickoff, significant task, blocked, completion) через sub-skill dailybot
report; опційне детерміноване примусове виконання хуків (dailybot hook, CLI>= 3.7.0) - Парний скіл: встановлення DailybotHQ/agent-skill (зараз 3.10.3) відкриває 14 можливостей — чат у Slack/Teams/Discord/Google Chat, check-in, авторство форм, ask AI, kudos, per-repo API keys (
.dailybot/env.json), email тощо. DWP-аддон підключає лише report; інші можливості викликаються безпосередньо через скіл Dailybot - Auth: повністю делеговано скілу Dailybot (
dailybot loginабоDAILYBOT_API_KEY); цей аддон ніколи не зберігає облікові дані - Vendor-neutral guardrail: основний DWP має нульову залежність від Dailybot; ніколи не встановлюйте автоматично для всіх
- Коли пропонувати: розробник або команда вже використовує Dailybot або явно просить командне звітування
Dependency upgrade (третій аддон)
Оновлення залежностей незалежно від менеджера пакетів, пакетами, з валідацією та можливістю відкату.
- Сторінка kit: Dependency upgrade
- Що додає: виявляє реальний менеджер репозиторію (npm/pnpm/yarn + ncu, pip/poetry/uv, cargo, go mod, bundler, composer, …), оновлює пакетами за semver, запускає validation gate репозиторію після кожного пакета, відкочує збої, підсумовує без auto-commit
- Команда: встановлює
/lib-upgradeу.agents/commands/лише після прийняття - Коли пропонувати: пропонується для кожного репозиторія з оголошеними залежностями; неактивний делегатор
/lib-upgradeвстановлюється за згодою онбордингу, якщо явно не відхилено — установка не запускає жодного оновлення
Design system (четвертий аддон)
DESIGN.md з областю поверхні інтерфейсу, який читає будь-який coding agent для узгодженого UI, CLI або conversational output.
- Сторінка kit: Design system
- Що додає:
docs/DESIGN.md(посилання зAGENTS.md) з до трьох профілів в одному файлі: visual-ui (токени та компоненти rendered UI), cli-output (семантичні стилі терміналу, деградація TTY/NO_COLOR), conversational (голос, анатомія повідомлення, рендеринг per platform з plain-text fallbacks) - Сила профілю: виявлення робить пропозицію обовʼязковою; установка захищена явною згодою — як у guide-режимі, так й у trust-режимі — visual-ui наполегливо рекомендується при виявленні; cli-output і conversational рекомендовані при виявленні, завжди питаються, ніколи не auto-applied
- Коли пропонувати: лише коли виявлено user-facing поверхню інтерфейсу — не для чистих бібліотек, headless-сервісів чи infra-only репозиторіїв
AI Diff Reviewer (пʼятий аддон — обовʼязковий локальний огляд, опційна CI-поверхня)
AI Diff Reviewer (marketplace «AI Diff Reviewer») надає обовʼязковій перевірці безпеки Final Review структурований локальний огляд і необовʼязково контролює pull request у CI. Починаючи зі стандарту 2.3.0 локальний огляд є частиною базового рівня; опційною лишається лише CI-поверхня. Цей аддон автоматично оновлюється з кожним релізом, тож його поточна версія ніколи не закріплена в цьому тексті — перевіряйте власний SKILL.md аддона або його релізи на GitHub, щоб дізнатися, який саме тег vendored.
- Сторінка kit: AI Diff Reviewer — повна довідка можливостей
- Обовʼязково під час онбордингу (Phase 7a): закріплене за тегом встановлення vendored-скіла (
npx --yes skills add DailybotHQ/[email protected] --skill ai-diff-reviewer -y) плюс адаптований під репозиторій.review/extension.md(черезgenerate-extension) за згодою онбордингу; цільове оновлення harness узгоджує обидва, коли вони відсутні; відмова записується як заявлений виняток і про неї звітуєverify, доки оглядач не встановлено - Обовʼязково в кожному Final Review: перевірка безпеки запускає типовий батьківський потік upstream над накопиченим набором змін і додає його вивід до локального для плану
analysis_results/SECURITY_REVIEW.md(усередині власної теки плану, ніколи в корені репозиторія); відсутній скіл або розширення — це записана знахідкаlocal reviewer not installed— ніколи не мовчазний пропуск і ніколи не несподіваний бустреп: встановлення належить згоді онбордингу або явному виклику адд-она; знахідкиcriticalзавершеного проходу блокують завершення, доки їх не виправлено або явно не прийнято - Опційна CI-поверхня (Flow B):
pr-review.yml(DailybotHQ/ai-diff-reviewer@v2) через upstream sub-skillsetupплюсapply-reviewяк супутник, якого викликає розробник — пропонується явно, ніколи не встановлюється без запиту, ніколи не за замовчуванням, ніколи не як завдання плану - Неблокування (лише виклик): локальний огляд, що міг стартувати, але завершився помилкою, — попередити один раз, записати й продовжити; він ніколи не провалює завдання
- Паритет (Flow B): спільний
prompt.md+ розширення вирівнюють методологію/серйозність; CI Iteration-Aware Review може скоротити раунди 2+, тоді як локальний прохід лишається повним - Нейтральність щодо постачальника: жоден потік Deep Work Plan не потребує комерційного сервісу, CI-провайдера чи секрету — оглядач — це закріплений за тегом MIT-скіл, який запускає власний coding agent розробника
- Відповідність:
verifyзвітує про відсутній локальний оглядач як збій для репозиторіїв, що заявляють стандарт 2.3.0 або новіший, і як знахідку версії harness для застарілих репозиторіїв
Скіли
Скіли — багаторазові процедури, що викликаються за іменем. Скіл пакує повторюваний workflow (запуск тестів, виправлення lint, створення компонента).
Методика постачає невеликий набір основних sub-skill. Серед них sub-skill author дозволяє репозиторію розвивати власний kit: викликається через /skill-create і /agent-create, міркує про наявний layout .agents/ і конвенції, потім створює новий скіл, агента або тонкий command delegator, що їм відповідає, і тримає каталог синхронізованим. Той самий sub-skill забезпечує прохід звірки skills у Final Review.
Запис kit: Skill create, Agent create.
Агенти
Агенти — спеціалізовані працівники з визначеною роллю (reviewer, executor, architect). Вони живуть у .agents/agents/ і каталогізуються в .agents/docs/.
Аддони обслуговування
Аддон dependency-upgrade (вище) — основний maintenance-аддон. Він міркує про реальний package manager репозиторію замість припущення npm, класифікує оновлення за semver, оновлює безпечними пакетами, запускає валідацію після кожного пакета й відкочує невдалі пакети.
Аддон design-system
Див. Design system у shipping-аддонах. DESIGN.md на рівні репозиторію відрізняється від технічного design doc per feature: README плану DWP, acceptance criteria завдань і validation gates уже покривають design per feature. Аддон design-system заповнює довговічний, repo-native контекст інтерфейсного дизайну.
Пресети
Пресети адаптують DWP до конкретного tech stack (Django, React, Go, Astro + Svelte тощо). Перегляньте каталог kit.
Адаптери
Адаптери зіставляють команди DWP із системою команд конкретного агента (Claude Code, Cursor, Codex, Gemini, Copilot, OpenClaw та інші). Записи адаптерів у kit живуть під іменем кожного агента.
Приклади
Приклади демонструють DWP на практиці: порівняння до/після, зразкові плани, кейс-стаді. Див. Examples і Dogfood this site.
Нагадування про відповідність
Репозиторій ПОВИНЕН бути повністю відповідним із нулем аддонів. Аддони — шарові опційні можливості, ніколи передумови. Див. Conformance.