Maison

Skill

Productivité et flux de travail

planning-and-task-breakdown

addyosmani/agent-skills

Décomposez le travail en petites tâches vérifiables, dotées de critères d'acceptation explicites, classées par dépendances et segmentées verticalement pour garantir une mise en œuvre fiable.

...Développer tout

Heure mise à jour 3 septembre 2026

# planning # dependency graph # acceptance criteria # checkpoints # task breakdown # vertical slicing

Planification et décomposition des tâches

Présentation

Décomposez le travail en petites tâches vérifiables, assorties de critères d’acceptation explicites. Une bonne décomposition des tâches fait toute la différence entre un agent qui accomplit son travail de manière fiable et un autre qui produit un résultat confus et désordonné. Chaque tâche doit être suffisamment petite pour être mise en œuvre, testée et vérifiée au cours d’une seule session ciblée.

Quand l'utiliser

Vous disposez d’un cahier des charges et devez le décomposer en unités réalisables
Une tâche semble trop vaste ou trop vague pour que l’on puisse s’y attaquer
Le travail doit être réparti en parallèle entre plusieurs agents ou sessions
Vous devez communiquer la portée du travail à une personne
L'ordre de mise en œuvre n'est pas évident

Quand NE PAS l’utiliser : modifications portant sur un seul fichier dont la portée est évidente, ou lorsque le cahier des charges contient déjà des tâches bien définies.

Le processus de planification

Étape 1 : Passer en mode planification

Avant d'écrire le moindre code, travaillez en mode lecture seule :

Lisez le cahier des charges et les sections pertinentes du code source
Identifiez les modèles et conventions existants
Cartographiez les dépendances entre les composants
Notez les risques et les inconnues

N'écrivez PAS de code pendant la phase de planification. Le résultat attendu est un document de planification, et non une implémentation.

Étape 2 : Identifier le graphe de dépendances

Cartographier les relations de dépendance :

Schéma de base de données
    │
    ├── Modèles/types de l'API
    │       │
    │       ├── Points de terminaison de l'API
    │       │       │
    │       │       └── Client API front-end
    │       │               │
    │       │               └── Composants de l’interface utilisateur
    │       │
    │       └── Logique de validation
    │
    └── Données d’amorçage / migrations

L'ordre de mise en œuvre suit le graphe de dépendances de bas en haut : commencez par poser les fondations.

Étape 3 : Découpage vertical

Au lieu de développer d’abord l’intégralité de la base de données, puis l’ensemble de l’API, puis toute l’interface utilisateur, construisez un chemin de fonctionnalité complet à la fois :

Mauvaise approche (segmentation horizontale) :

Tâche 1 : Construire l’intégralité du schéma de base de données
Tâche 2 : Construire tous les points de terminaison de l’API
Tâche 3 : Construire tous les composants de l’interface utilisateur
Tâche 4 : Relier le tout

Bon exemple (segmentation verticale) :

Tâche 1 : l’utilisateur peut créer un compte (schéma + API + interface utilisateur pour l’inscription)
Tâche 2 : l’utilisateur peut se connecter (schéma d’authentification + API + interface utilisateur pour la connexion)
Tâche 3 : l’utilisateur peut créer une tâche (schéma de tâche + API + interface utilisateur pour la création)
Tâche 4 : l’utilisateur peut consulter la liste des tâches (requête + API + interface utilisateur pour l’affichage de la liste)

Chaque tranche verticale offre une fonctionnalité opérationnelle et testable.

Étape 4 : Rédiger les tâches

Chaque tâche suit la structure suivante :

## Tâche [N] : [Titre descriptif court]

**Description :** Un paragraphe expliquant ce que cette tâche permet de réaliser.

**Critères d'acceptation :**
- [ ] [Condition spécifique et testable]
- [ ] [Condition spécifique et testable]

**Vérification :**
- [ ] Tests réussis : `npm test -- --grep "nom-de-la-fonctionnalité"`
- [ ] Compilation réussie : `npm run build`
- [ ] Vérification manuelle : [description de ce qu’il faut vérifier]

**Dépendances :** [Numéros des tâches dont celle-ci dépend, ou « Aucune »]

**Fichiers susceptibles d’être modifiés :**
- `src/chemin/vers/fichier.ts`
- `tests/chemin/vers/test.ts`

**Portée estimée :** [Faible : 1 à 2 fichiers | Moyenne : 3 à 5 fichiers | Élevée : 5 fichiers ou plus]

Étape 5 : Ordre et point de contrôle

Organisez les tâches de manière à ce que :

Les dépendances soient respectées (commencer par poser les bases)
Chaque tâche laisse le système dans un état fonctionnel
Des points de contrôle de vérification aient lieu toutes les 2 à 3 tâches
Les tâches à haut risque soient effectuées en début de processus (pour détecter rapidement les échecs)

Ajoutez des points de contrôle explicites :

## Point de contrôle : après les tâches 1 à 3
- [ ] Tous les tests sont réussis
- [ ] L'application se compile sans erreur
- [ ] Le flux utilisateur principal fonctionne de bout en bout
- [ ] Vérification par un humain avant de poursuivre

Directives pour l’estimation de la charge de travail

Taille	Fichiers	Portée	Exemple
XS	1	Modification d'une seule fonction ou d'un seul paramètre de configuration	Ajout d’une règle de validation
S	1-2	Un composant ou un point de terminaison	Ajouter un nouveau point de terminaison API
M	3-5	Une tranche de fonctionnalité	Processus d’inscription d’un utilisateur
L	5-8	Fonctionnalité à plusieurs composants	Recherche avec filtrage et pagination
XL	8+	Trop volumineux — décomposez davantage	—

Si une tâche est de niveau L ou supérieur, elle doit être décomposée en tâches plus petites. Un agent est plus performant sur les tâches de niveau S et M.

Quand décomposer davantage une tâche :

Si cela nécessite plus d’une session de travail concentrée (environ 2 heures ou plus de travail de l’agent)
Vous ne pouvez pas décrire les critères d’acceptation en 3 points ou moins
Elle concerne au moins deux sous-systèmes indépendants (par exemple, l’authentification et la facturation)
Si vous vous retrouvez à écrire « et » dans le titre de la tâche (ce qui indique qu'il s'agit en réalité de deux tâches)

Modèle de document de planification

# Plan de mise en œuvre : [Nom de la fonctionnalité/du projet]

## Présentation générale
[Résumé en un paragraphe de ce que nous développons]

## Décisions architecturales
- [Décision clé n° 1 et justification]
- [Décision clé n° 2 et justification]

## Liste des tâches

### Phase 1 : Fondations
- [ ] Tâche 1 : ...
- [ ] Tâche 2 : ...

### Point de contrôle : Fondations
- [ ] Tests réussis, compilation sans erreur

### Phase 2 : Fonctionnalités principales
- [ ] Tâche 3 : ...
- [ ] Tâche 4 : ...

### Point de contrôle : fonctionnalités principales
- [ ] Le flux de bout en bout fonctionne

### Phase 3 : Peaufinage
- [ ] Tâche 5 : ...
- [ ] Tâche 6 : ...

### Point de contrôle : Achèvement
- [ ] Tous les critères d'acceptation sont remplis
- [ ] Prêt pour la révision

## Risques et mesures d'atténuation
| Risque | Impact | Mesure d'atténuation |
|------|--------|------------|
| [Risque] | [Élevé/Moyen/Faible] | [Stratégie] |

## Questions en suspens
- [Question nécessitant une intervention humaine]

Possibilités de parallélisation

Lorsque plusieurs agents ou sessions sont disponibles :

Parallélisation sans risque : tranches de fonctionnalités indépendantes, tests des fonctionnalités déjà implémentées, documentation
Doit être effectué de manière séquentielle : migrations de bases de données, modifications d'états partagés, chaînes de dépendances
Nécessite une coordination : fonctionnalités partageant un contrat d’API (définir d’abord le contrat, puis paralléliser)

Rationalisations courantes

Rationalisation	Réalité
« Je verrai bien au fur et à mesure »	C’est ainsi que l’on se retrouve avec un enchevêtrement inextricable et des retouches. 10 minutes de planification permettent de gagner des heures.
« Les tâches sont évidentes »	Notez-les quand même. Les tâches explicites font ressortir les dépendances cachées et les cas limites oubliés.
« La planification, c’est une charge supplémentaire »	La planification, c’est la tâche elle-même. Une mise en œuvre sans plan, ce n’est que de la saisie.
« Je peux tout garder en tête »	Les fenêtres contextuelles ont une capacité limitée. Les plans écrits survivent aux limites des sessions et au compactage.

Signaux d’alerte

Commencer la mise en œuvre sans liste de tâches écrite
Des tâches qui indiquent « mettre en œuvre la fonctionnalité » sans critères d’acceptation
Absence d’étapes de vérification dans le plan
Toutes les tâches sont de taille XL
Absence de points de contrôle entre les tâches
L'ordre des dépendances n'est pas pris en compte

Vérification

Avant de commencer la mise en œuvre, vérifiez que :

Chaque tâche dispose de critères d'acceptation
Chaque tâche comporte une étape de vérification
Les dépendances entre les tâches sont identifiées et classées correctement
Aucune tâche ne concerne plus de ~5 fichiers
Des points de contrôle existent entre les phases principales
Le plan a été examiné et approuvé par une personne

Voir aussi

Les critères d’acceptation s’appliquent à chaque tâche et répondent à la question « avons-nous construit ce qu’il fallait ? ». Ils s’ajoutent à la « définition de « terminé » » à l’échelle du projet, le seuil que chaque tâche doit franchir avant d’être considérée comme terminée. Voir references/definition-of-done.md.

Voir sur GitHub

---
name: planning-and-task-breakdown
description: Decompose work into small, verifiable tasks with explicit acceptance criteria, ordered by dependencies and sliced vertically for reliable implementation.
---

# Planning and Task Breakdown

## Overview

Decompose work into small, verifiable tasks with explicit acceptance criteria. Good task breakdown is the difference between an agent that completes work reliably and one that produces a tangled mess. Every task should be small enough to implement, test, and verify in a single focused session.

## When to Use

- You have a spec and need to break it into implementable units
- A task feels too large or vague to start
- Work needs to be parallelized across multiple agents or sessions
- You need to communicate scope to a human
- The implementation order isn't obvious

**When NOT to use:** Single-file changes with obvious scope, or when the spec already contains well-defined tasks.

## The Planning Process

### Step 1: Enter Plan Mode

Before writing any code, operate in read-only mode:

- Read the spec and relevant codebase sections
- Identify existing patterns and conventions
- Map dependencies between components
- Note risks and unknowns

**Do NOT write code during planning.** The output is a plan document, not implementation.

### Step 2: Identify the Dependency Graph

Map what depends on what:

```
Database schema
    │
    ├── API models/types
    │       │
    │       ├── API endpoints
    │       │       │
    │       │       └── Frontend API client
    │       │               │
    │       │               └── UI components
    │       │
    │       └── Validation logic
    │
    └── Seed data / migrations
```

Implementation order follows the dependency graph bottom-up: build foundations first.

### Step 3: Slice Vertically

Instead of building all the database, then all the API, then all the UI — build one complete feature path at a time:

**Bad (horizontal slicing):**
```
Task 1: Build entire database schema
Task 2: Build all API endpoints
Task 3: Build all UI components
Task 4: Connect everything
```

**Good (vertical slicing):**
```
Task 1: User can create an account (schema + API + UI for registration)
Task 2: User can log in (auth schema + API + UI for login)
Task 3: User can create a task (task schema + API + UI for creation)
Task 4: User can view task list (query + API + UI for list view)
```

Each vertical slice delivers working, testable functionality.

### Step 4: Write Tasks

Each task follows this structure:

```markdown
## Task [N]: [Short descriptive title]

**Description:** One paragraph explaining what this task accomplishes.

**Acceptance criteria:**
- [ ] [Specific, testable condition]
- [ ] [Specific, testable condition]

**Verification:**
- [ ] Tests pass: `npm test -- --grep "feature-name"`
- [ ] Build succeeds: `npm run build`
- [ ] Manual check: [description of what to verify]

**Dependencies:** [Task numbers this depends on, or "None"]

**Files likely touched:**
- `src/path/to/file.ts`
- `tests/path/to/test.ts`

**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]
```

### Step 5: Order and Checkpoint

Arrange tasks so that:

1. Dependencies are satisfied (build foundation first)
2. Each task leaves the system in a working state
3. Verification checkpoints occur after every 2-3 tasks
4. High-risk tasks are early (fail fast)

Add explicit checkpoints:

```markdown
## Checkpoint: After Tasks 1-3
- [ ] All tests pass
- [ ] Application builds without errors
- [ ] Core user flow works end-to-end
- [ ] Review with human before proceeding
```

## Task Sizing Guidelines

| Size | Files | Scope | Example |
|------|-------|-------|---------|
| **XS** | 1 | Single function or config change | Add a validation rule |
| **S** | 1-2 | One component or endpoint | Add a new API endpoint |
| **M** | 3-5 | One feature slice | User registration flow |
| **L** | 5-8 | Multi-component feature | Search with filtering and pagination |
| **XL** | 8+ | **Too large — break it down further** | — |

If a task is L or larger, it should be broken into smaller tasks. An agent performs best on S and M tasks.

**When to break a task down further:**
- It would take more than one focused session (roughly 2+ hours of agent work)
- You cannot describe the acceptance criteria in 3 or fewer bullet points
- It touches two or more independent subsystems (e.g., auth and billing)
- You find yourself writing "and" in the task title (a sign it is two tasks)

## Plan Document Template

```markdown
# Implementation Plan: [Feature/Project Name]

## Overview
[One paragraph summary of what we're building]

## Architecture Decisions
- [Key decision 1 and rationale]
- [Key decision 2 and rationale]

## Task List

### Phase 1: Foundation
- [ ] Task 1: ...
- [ ] Task 2: ...

### Checkpoint: Foundation
- [ ] Tests pass, builds clean

### Phase 2: Core Features
- [ ] Task 3: ...
- [ ] Task 4: ...

### Checkpoint: Core Features
- [ ] End-to-end flow works

### Phase 3: Polish
- [ ] Task 5: ...
- [ ] Task 6: ...

### Checkpoint: Complete
- [ ] All acceptance criteria met
- [ ] Ready for review

## Risks and Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | [High/Med/Low] | [Strategy] |

## Open Questions
- [Question needing human input]
```

## Parallelization Opportunities

When multiple agents or sessions are available:

- **Safe to parallelize:** Independent feature slices, tests for already-implemented features, documentation
- **Must be sequential:** Database migrations, shared state changes, dependency chains
- **Needs coordination:** Features that share an API contract (define the contract first, then parallelize)

## Common Rationalizations

| Rationalization | Reality |
|---|---|
| "I'll figure it out as I go" | That's how you end up with a tangled mess and rework. 10 minutes of planning saves hours. |
| "The tasks are obvious" | Write them down anyway. Explicit tasks surface hidden dependencies and forgotten edge cases. |
| "Planning is overhead" | Planning is the task. Implementation without a plan is just typing. |
| "I can hold it all in my head" | Context windows are finite. Written plans survive session boundaries and compaction. |

## Red Flags

- Starting implementation without a written task list
- Tasks that say "implement the feature" without acceptance criteria
- No verification steps in the plan
- All tasks are XL-sized
- No checkpoints between tasks
- Dependency order isn't considered

## Verification

Before starting implementation, confirm:

- [ ] Every task has acceptance criteria
- [ ] Every task has a verification step
- [ ] Task dependencies are identified and ordered correctly
- [ ] No task touches more than ~5 files
- [ ] Checkpoints exist between major phases
- [ ] The human has reviewed and approved the plan

## See Also

Acceptance criteria are per-task and answer "did we build the right thing?". They sit on top of the project-wide Definition of Done, the standing bar every task clears before it counts as done. See `references/definition-of-done.md`.