Skip to content
Deep Work Plan сьогодні на Product Hunt Підтримати
← Усі документи специфікації

Додатки

Версія 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-skill setup плюс 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.