Modules complémentaires

Version 2.1.0. Les modules complémentaires sont des extensions de la méthodologie centrale de Deep Work Plan. Quatre des cinq sont optionnels et jamais requis pour la conformité — un dépôt sans addons optionnels est pleinement AI-first et conforme DWP. Chaque addon optionnel est proposé lors de l’onboarding, accepté ou refusé explicitement et — lorsqu’il est accepté — réconcilie avec la configuration existante au lieu de l’écraser. Un composant est l’exception déclarée : depuis le standard 2.3.0, la revue locale AI Diff Reviewer fait partie du socle requis — l’onboarding l’installe et chaque Final Review l’exécute — tandis que sa surface CI reste optionnelle.

Le contrat d’addon

Chaque addon actif fournit quatre composants obligatoires :

Découverte : le flux onboard énumère skills/deepworkplan/addons/ et présente chaque addon comme une étape opt-in dans la Phase 7b, après le scaffolding central.

Addons actifs (cinq)

Cinq addons sont actifs aujourd’hui — quatre opt-in plus la revue locale requise. Chacun a une page du catalogue kit avec des détails orientés utilisateur et une spec normative dans la skill Deep Work Plan.

Devcontainer (premier addon)

Une configuration .devcontainer/ + docker/ basée sur compose, raisonnée à partir de la stack détectée.

• Page kit : Devcontainer
• Ce qu’il ajoute : volumes persistants d’auth CLI IA (Claude, Codex, Cursor, gh, Dailybot), dailybot-project-network, DOCKER_DEV_ENV=vscode, alias de validation (codecheck, check, fix, test), hygiène des secrets pour OSS public
• Comportement : ~85 % squelette stable ; ~15 % raisonné par stack. Les devcontainers existants sont réconciliés, jamais écrasés
• Quand proposé : la plupart des dépôts avec Docker ou des services bénéficiant d’un conteneur de dev isolé

Dailybot (deuxième addon)

Une connexion optionnelle à l’équipe Dailybot du développeur pour la visibilité de la progression des agents.

• Page kit : Dailybot — référence complète des capacités
• Ce que l’addon DWP connecte : quatre rapports du cycle de vie du plan (kickoff, tâche significative, bloqué, achèvement) via la sous-skill report de dailybot ; application déterministe optionnelle par hooks (dailybot hook, CLI >= 3.7.0)
• Skill jumelée : installer DailybotHQ/agent-skill (actuellement 3.10.3) expose 14 capacités — chat sur Slack/Teams/Discord/Google Chat, check-ins, autorisation de formulaires, ask AI, kudos, clés API par dépôt (.dailybot/env.json), e-mail et plus. L’addon DWP ne connecte que report ; les autres capacités sont invoquées directement via la skill Dailybot
• Auth : entièrement reportée à la skill Dailybot (dailybot login ou DAILYBOT_API_KEY) ; cet addon ne stocke jamais de credentials
• Garde-fou neutre vis-à-vis du fournisseur : le DWP central a zéro dépendance à Dailybot ; ne jamais installer automatiquement pour tout le monde
• Quand proposé : le développeur ou l’équipe utilise déjà Dailybot, ou demande explicitement des rapports d’équipe

Dependency upgrade (troisième addon)

Mises à niveau de dépendances par lots, validées et réversibles, agnostiques au gestionnaire de paquets.

• Page kit : Dependency upgrade
• Ce qu’il ajoute : détecte le gestionnaire réel du dépôt (npm/pnpm/yarn + ncu, pip/poetry/uv, cargo, go mod, bundler, composer, …), met à niveau par lots classés semver, exécute la porte de validation du dépôt après chaque lot, annule les échecs, résume sans commit automatique
• Commande : installe /lib-upgrade dans .agents/commands/ uniquement lorsqu’il est accepté
• Quand proposé : proposé pour tout dépôt avec des dépendances déclarées ; le délégué inerte /lib-upgrade s’installe sous le consentement de l’onboarding sauf refus explicite — une installation n’exécute aucune mise à niveau

Design system (quatrième addon)

Un DESIGN.md à portée de surface d’interface que tout agent de codage lit pour une sortie UI, CLI ou conversationnelle cohérente.

• Page kit : Design system
• Ce qu’il ajoute : docs/DESIGN.md (référencé depuis AGENTS.md) avec jusqu’à trois profils empilés dans un seul fichier : visual-ui (jetons et composants d’UI rendue), cli-output (styles sémantiques de terminal, dégradation TTY/NO_COLOR), conversational (voix, anatomie du message, rendu par plateforme avec replis en texte brut)
• Force du profil : la détection rend l’offre obligatoire ; l’installation est conditionnée à une acceptation, en mode guidé comme en mode confiance — visual-ui est fortement recommandé lorsqu’il est détecté ; cli-output et conversational sont recommandés lorsqu’ils sont détectés, toujours demandés, jamais appliqués automatiquement
• Quand proposé : uniquement lorsqu’une surface d’interface orientée utilisateur est détectée — pas pour les bibliothèques pures, services headless ou dépôts infra uniquement

AI Diff Reviewer (cinquième addon — revue locale requise, surface CI optionnelle)

L’AI Diff Reviewer (marketplace “AI Diff Reviewer”) dote la passe de sécurité obligatoire du Final Review d’une revue locale structurée et bloque optionnellement les pull requests en CI. Depuis le standard 2.3.0, la revue locale fait partie du socle ; seule la surface CI est optionnelle. Cet addon est actualisé automatiquement à chaque publication, si bien que sa version courante n’est jamais figée dans ce texte : consultez le SKILL.md propre à l’addon ou ses releases GitHub pour connaître le tag réellement vendorisé.

• Page kit : AI Diff Reviewer — référence complète des capacités
• Requise à l’onboarding (Phase 7a) : installation de la skill vendorisée épinglée à un tag (npx --yes skills add DailybotHQ/[email protected] --skill ai-diff-reviewer -y) plus un .review/extension.md adapté au dépôt (via generate-extension), sous le consentement de l’onboarding ; une mise à niveau ciblée de la harness réconcilie les deux lorsqu’ils manquent ; un refus est enregistré comme exception déclarée et signalé par verify jusqu’à son installation
• Requise dans chaque Final Review : la passe de sécurité exécute le flux parent par défaut de la skill upstream sur l’ensemble des changements accumulé et ajoute sa sortie au analysis_results/SECURITY_REVIEW.md local au plan (dans le dossier propre du plan, jamais à la racine du dépôt) ; une skill ou une extension manquante est un constat enregistré local reviewer not installed — jamais un saut silencieux, et jamais un amorçage surprise : l’installation appartient au consentement de l’onboarding ou à une invocation explicite de l’addon ; les constats critical d’un passage terminé bloquent l’achèvement jusqu’à correction ou acceptation explicite
• Surface CI optionnelle (Flow B) : pr-review.yml (DailybotHQ/ai-diff-reviewer@v2) via la sous-skill upstream setup, plus apply-review en tant que compagnon invocable par le développeur — proposé explicitement, jamais installé sans demande, jamais le défaut, jamais une tâche du plan
• Jamais bloquant (invocation uniquement) : une revue locale qui peut démarrer mais échoue sur une erreur avertit une fois, enregistre et poursuit ; elle ne fait jamais échouer la tâche
• Parité (Flow B) : prompt.md partagé + extension aligne méthodologie/sévérité ; la Revue consciente des itérations CI peut raccourcir le round 2+ tandis que le passage local reste complet
• Garde-fou neutre vis-à-vis du fournisseur : aucun flux Deep Work Plan n’exige de service commercial, de fournisseur CI ni de secret — le reviewer est une skill MIT épinglée à un tag, exécutée par le propre agent de codage du développeur
• Conformité : verify signale un reviewer local manquant comme un échec pour les dépôts déclarant le standard 2.3.0 ou plus récent, et comme un constat de version de la harness pour les dépôts legacy

Skills

Les skills sont des procédures réutilisables invoquées par nom. Une skill empaquette un flux de travail répétable (exécuter des tests, corriger le lint, créer un composant).

La méthodologie fournit un petit ensemble de sous-skills centrales. Parmi elles, la sous-skill author permet à un dépôt de développer son propre kit : invoquée via /skill-create et /agent-create, elle raisonne sur la disposition .agents/ existante et les conventions, puis auteur une nouvelle skill, un agent ou un délégué de commande fin qui correspond, et maintient le catalogue synchronisé. La même sous-skill appuie la passe de réconciliation des skills du Final Review.

Entrée kit : Skill create, Agent create.

Agents

Les agents sont des travailleurs spécialisés avec un rôle défini (reviewer, executor, architect). Ils vivent sous .agents/agents/ et sont catalogués dans .agents/docs/.

Modules complémentaires de maintenance

Le module complémentaire dependency-upgrade (ci-dessus) est le module de maintenance principal. Il raisonne sur le gestionnaire de paquets réel du dépôt plutôt que d’assumer npm, classe les mises à niveau par semver, met à niveau par lots sûrs, exécute la validation après chaque lot et annule tout lot qui échoue.

Module complémentaire design system

Voir Design system sous les addons actifs. Le DESIGN.md au niveau du dépôt est distinct d’un document de design technique par fonctionnalité : le README du plan DWP, les critères d’acceptation des tâches et les portes de validation couvrent déjà le design par fonctionnalité. L’addon design-system comble un contexte de design d’interface durable et natif au dépôt.

Presets

Les presets adaptent DWP à une stack technologique spécifique (Django, React, Go, Astro + Svelte et plus). Parcourez le catalogue kit.

Adaptateurs

Les adaptateurs mappent les commandes DWP au système de commandes d’un agent spécifique (Claude Code, Cursor, Codex, Gemini, Copilot, OpenClaw et autres). Les entrées d’adaptateur vivent dans le kit sous le nom de chaque agent.

Exemples

Les exemples démontrent DWP en pratique : comparaisons avant/après, plans d’exemple, études de cas. Voir Examples et Dogfood this site.

Rappel de conformité

Un dépôt DOIT être pleinement conforme avec zéro addons. Les addons sont des capacités opt-in en couches — jamais des préconditions. Voir Conformance.