Додатки

Обсяг версії: Це збережений базовий документ v5.0.0. Поточний стандарт, DWP 7.0.0, також вимагає відповідних розширень V6_*.md і V7_*.md, перелічених в індексі специфікації. Наявні плани v5 і v6 зберігають зафіксовані правила.

Версія 2.1.0. Аддони — розширення основної методології Deep Work Plan. Сім із восьми є опційними та ніколи не потрібні для відповідності — репозиторій без опційних аддонів повністю AI-first і відповідає DWP. Кожен опційний аддон пропонується під час онбордингу, явно приймається або відхиляється, а після прийняття узгоджується з наявним налаштуванням замість його знищення. Один компонент є заявленим винятком: починаючи зі стандарту 2.3.0 локальний огляд AI Diff Reviewer є частиною обовʼязкового базового рівня — онбординг його встановлює, і кожен Final Review його запускає — тоді як його CI-поверхня лишається опційною.

Контракт аддона

Кожен shipping-аддон постачає чотири обовʼязкові компоненти:

Виявлення: потік onboard перераховує skills/deepworkplan/addons/ і представляє кожен аддон як опційний крок у Phase 7b, після основного scaffolding.

Shipping-аддони (вісім)

Сьогодні доступні вісім аддонів — сім опційних плюс обовʼязковий локальний огляд. Кожен має сторінку каталогу kit з деталями для користувача та нормативну spec у скілі Deep Work Plan. Чотири з них — devcontainer, Herdr, DeepWorkPlan Vim і Agentkit — тонкі інтегратори, закріплені за тегом продукту з власним репозиторієм і циклом релізів; кожен продукт працює і без Deep Work Plan. Прийнятий аддон записується в реєстр аддонів .dwp/config.json (DWP 7.0.0), який може лише пропонувати або підсилювати — він ніколи не визначає відповідність і не блокує план.

Devcontainer (перший аддон)

Тонкий інтегратор devcontainer-kit (dck, закріплено на v1.1.1, інтерфейс 2): шаблон Dev Containers, який dck init розгортає в репозиторії як його власний контейнер, а також скіл dck-dockerfile.

• Сторінка kit: Devcontainer
• Що додає: docker/local/<service>/Dockerfile на основі офіційного образу середовища виконання, закріпленого за digest (python-3.13, node-24 або debian, без спільного базового образу), dev.sh поверх лаунчера dck (up, shell, rebuild, doctor), агентів для програмування як шар, який вмикається за бажанням, порти лише на loopback, git через SSH за допомогою агента хоста без жодного ключа всередині, якщо тільки розробник сам не ввімкне [ssh] copy_keys у своєму профілі хоста, та машини Herdr для кожного контейнера зі стандартним розкладом
• Поведінка: виявляється через dck doctor --json (інтерфейс 2); dck init узгоджує наявний devcontainer лише після прийняття його diff і спершу створює резервну копію файлу — ніколи не затирається
• Коли пропонувати: більшість репозиторіїв з Docker або сервісами, що виграють від ізольованого dev-контейнера

Dailybot (другий аддон)

Опційне підключення до команди Dailybot розробника для видимості прогресу агента.

• Сторінка kit: Dailybot — повна довідка можливостей
• Що підключає DWP-аддон: чотири звіти життєвого циклу плану (kickoff, significant task, blocked, completion) через sub-skill dailybot report; опційне детерміноване примусове виконання хуків (dailybot hook, CLI >= 3.9.0)
• Парний скіл: встановлення DailybotHQ/agent-skill (закріплено на v3.23.20) відкриває 17 можливостей — чат у Slack/Teams/Discord/Google Chat, check-in, створення форм, ask AI, kudos, дошки й завдання Plan, мітки організації, 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-поверхня. Цей аддон автоматично оновлюється з кожним релізом, тож показаний нижче тег є чинним на момент написання і може відставати від vendored-копії — джерелом істини про фактично встановлений тег є власний SKILL.md аддона та його релізи на GitHub. Встановлення завжди закріплюється за опублікованим тегом, а не за рухомою гілкою.

• Сторінка kit: AI Diff Reviewer — повна довідка можливостей
• Обовʼязково під час онбордингу (Phase 7a): закріплене за тегом встановлення vendored-скіла (npx --yes skills add https://github.com/DailybotHQ/ai-diff-reviewer/tree/v3.3.16 --skill ai-diff-reviewer -y) плюс адаптований під репозиторій .review/extension.md (через generate-extension) за згодою онбордингу; цільове оновлення harness узгоджує обидва, коли вони відсутні; відмова записується як заявлений виняток і про неї звітує verify, доки оглядач не встановлено
• Обовʼязково в кожному Final Review: перевірка безпеки запускає типовий батьківський потік upstream над накопиченим набором змін і додає його вивід до локального для плану analysis_results/SECURITY_REVIEW.md (усередині власної теки плану, ніколи в корені репозиторія); відсутній скіл або розширення — це записана знахідка local reviewer not installed — ніколи не мовчазний пропуск і ніколи не несподіваний бустреп: встановлення належить згоді онбордингу або явному виклику адд-она; підтверджені критичні знахідки завершеного проходу блокують завершення, доки їх не виправлено або явно не прийнято (v3, BC-07 — непідтверджені критичні твердження надходять як анотовані попередження, а огляд incomplete/timeout не є чистим проходом, BC-04)
• Опційна CI-поверхня (Flow B): pr-review.yml (DailybotHQ/ai-diff-reviewer@v3) через upstream sub-skill setup плюс супутники apply-review (лише читання) та address-review (робить коміти, push і перевзводить оглядача; новий у v3.1.1) як зручності, які викликає розробник — пропонується явно, ніколи не встановлюється без запиту, ніколи не за замовчуванням, ніколи не як завдання плану
• Неблокування (лише виклик): локальний огляд, що міг стартувати, але завершився помилкою, — попередити один раз, записати й продовжити; він ніколи не провалює завдання
• Паритет (Flow B): спільний prompt.md + розширення вирівнюють методологію/серйозність; CI Iteration-Aware Review може скоротити раунди 2+, тоді як локальний прохід лишається повним
• Нейтральність щодо постачальника: жоден потік Deep Work Plan не потребує комерційного сервісу, CI-провайдера чи секрету — оглядач — це закріплений за тегом MIT-скіл, який запускає власний coding agent розробника
• Відповідність: verify звітує про відсутній локальний оглядач як збій для репозиторіїв, що заявляють стандарт 2.3.0 або новіший, і як знахідку версії harness для застарілих репозиторіїв

Herdr (шостий аддон)

Тонкий інтегратор herdr-peers (закріплено на v1.1.0, протокол 1), інтерактивний транспорт делегування для планів v7.

• Сторінка kit: Herdr
• Що додає: план може передати обмежене завдання агенту для програмування в іншій панелі Herdr — на тій самій машині або на машині, до якої Herdr дістається через SSH, — і записати в журнал його єдину авторизовану відповідь
• Поведінка: протокол peer (stamp, grant, reply, захист від циклів, обмеження глибини й розгалуження) живе в herdr-peers, ніколи не в пакеті; будь-яке використання потребує дозволу контракту agent_delegation, а результат делегата лишається лише заявленим, доки його не спостерігає власний runner плану
• Коли пропонувати: явна згода у Phase 7b; виявлення herdr і herdr-peers лише для читання; транспорт доступний тільки всередині сесії Herdr

DeepWorkPlan Vim (сьомий аддон)

Тонкий інтегратор DeepWorkPlan Vim (закріплено на v1.0.1, інтерфейс 1), термінального редактора для Deep Work Plan (Neovim 0.12+).

• Сторінка kit: DeepWorkPlan Vim
• Що додає: опційну поверхню редактора на рівні машини для агентів і людей — згенерований індекс команд, переглядач планів лише для читання та переглядач Markdown; кожне твердження зчитується із закріпленої машиночитної поверхні продукту
• Поведінка: наявна конфігурація Neovim ніколи не перезаписується без явної згоди; виявлення лише для читання
• Коли пропонувати: явна згода у Phase 7b; лише інформаційно, якщо Neovim 0.12+ відсутній

Agentkit (восьмий аддон)

Тонкий інтегратор coding-agents-kit (ak, закріплено на v1.1.0, інтерфейс 1), headless-транспорт делегування для планів v7.

• Сторінка kit: Agentkit
• Що додає: єдину поверхню команд ak над термінальними агентами для програмування, через яку обмежене завдання плану виконується в режимі headless; можливості subagents, cancel_children і model_routing він надає лише під час виконання — коли його ввімкнено, виявлено й інтерфейс сумісний
• Поведінка: будь-яке використання потребує дозволу контракту agent_delegation; kit за замовчуванням запускає агентів в автономному режимі, і його відмова від автономії (--ask або AGENTKIT_PERMISSIONS=ask) завжди має пріоритет — аддон не вказує жодного прапорця автономії, передає --ask, коли план фіксує відмову, і завжди для делегатів лише для читання; він ніколи сам не встановлює CLI агентів для програмування й ніколи не читає значення ключів провайдерів
• Коли пропонувати: явна згода у Phase 7b; виявлення лише для читання через ak doctor --json

Скіли

Скіли — багаторазові процедури, що викликаються за іменем. Скіл пакує повторюваний 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.