Structure des prompts KSP

Portée

Ce document définit le contrat normatif des prompts de reprise KSP, leur cycle de vie et les règles de dimensionnement des releases/sessions qu'ils préparent.

Série, release concrète et session

Une notation de série telle que 0.1.x regroupe des fonctionnalités apparentées. Elle n'est pas une unité de session et n'a pas à être réalisable en une seule session.

Exemple : 0.1.x peut regrouper plusieurs releases concrètes comme 0.1.1, 0.1.2, 0.1.3, chacune avec son propre cycle de prereleases et, en principe, sa propre session de travail principale.

Le contrôle de charge s'applique donc d'abord à la release concrète préparée et à ses prereleases, pas à toute la série fonctionnelle.

Cycle d'une release concrète

Sauf raison explicitement documentée :

pre.001 = brainstorming/audit si nécessaire + planification + découpage de la release ;
les prereleases intermédiaires = tranches bornées de développement/validation ;
la dernière prerelease = validation finale + documentation + nettoyage/archivage + préparation du prompt/release suivante.

Dimensionnement des prereleases

Lors de pre.001, une prerelease intermédiaire estimée à plus d'environ 15 à 20 minutes de travail effectif de session doit être scindée.

Cette durée est un budget de planification et non une promesse d'exécution.

Si la complexité réelle augmente, la tranche est redécoupée plutôt que surchargée.

Dimensionnement d'une release/session

Avant de finaliser le prompt d'une release concrète, vérifier que son plan complet est compatible avec une session de qualité.

Si une release concrète paraît trop lourde, la scinder en plusieurs releases de la même série lorsque les fonctions restent du même groupe, ou changer de série si une frontière fonctionnelle différente le justifie.

Exemple : si 0.1.1 devient trop large, créer 0.1.2 plutôt que forcer tout 0.1.x dans une seule session.

Une série complète peut naturellement s'étendre sur de nombreuses sessions.

Une release concrète, en revanche, doit être planifiée pour être ouverte et clôturée dans une seule session de chat. Une version volontairement laissée ouverte pour être reprise dans une autre session n'est pas un découpage acceptable.

Si pre.001 révèle qu'une clôture dans la session est incertaine, la release est scindée avant l'implémentation fonctionnelle lourde. Cette contrainte s'ajoute au budget de 15–20 minutes par prerelease ; elle ne le remplace pas.

Structure recommandée d'un prompt

Identité de la série et de la release concrète visée ;
Mission ;
Base requise ;
État validé à préserver ;
Sources de vérité internes ;
Sources externes normatives ;
Décisions acquises ;
Objectifs et livrables ;
Hors périmètre ;
Méthode de travail ;
Versionnement/deltas/commits ;
Contraintes techniques spécifiques ;
Plan initial souple et prereleases bornées ;
Validations attendues ;
Critères de sortie ;
Préparation de la release/session suivante.

Règles de rédaction

Le prompt référence les sources canoniques au lieu de recopier inutilement leur contenu.
Une règle normative appartient à docs/rules/.
Une décision durable appartient à docs/architecture/.
Une idée non décidée appartient à docs/IDEAS.md.
Un prompt doit signaler les questions ouvertes plutôt que les résoudre arbitrairement.
Une release concrète manifestement surdimensionnée doit être redécoupée avant ouverture de sa session principale.

3.6 KiB Raw Blame History Unescape Escape