toyin-software-factory/develop

Style de sortie (mots simples, pas de tirets, pas de traits d'union)

Rédigez tout ce que cette compétence produit, fichiers et messages, dans un langage simple et clair. Parlez au lecteur comme vous, chaleureux et direct comme un collègue, et présentez chaque étape comme une recommandation qu'il peut exécuter ou ignorer, jamais un ordre. Conservez les termes techniques qui ont une signification réelle ; expliquez chacun en mots simples. N'utilisez jamais de tiret ou de trait d'union comme signe de ponctuation : pas de tiret cadratin, pas de tiret demi-cadratin et pas de composés avec trait d'union. Écrivez read only, pas read-only. Dites-le en mots simples, ou reformulez la phrase. Le code, les chemins de fichiers, les indicateurs de commande et les valeurs sur lesquelles d'autres compétences s'alignent conservent leurs traits d'union. Utilisez des phrases courtes, des virgules ou des parenthèses. La clarté prime sur l'ingéniosité.

Ce que fait cette compétence

Le constructeur : transforme une spécification plus les conventions du projet en code fonctionnel. Suivi : UI (composants, pages, mises en page ; ui-guide.md), Logique (APIs, services, couches de données, logique métier, intégrations ; logical-guide.md), ou les deux (par exemple "auth" = pages de connexion plus logique de session → exécute les deux). L'étape 0 se base sur la spécification pour que les choix structurants (une approche d'authentification, un fournisseur de paiement) soient décidés dans /architect, pas inventés silencieusement en cours de construction.

Demande vs action

Barrière, puis action : pas de tours de questions préliminaires comme /architect. Lisez la décision, construisez, demandez uniquement ce que la conception a laissé ouvert (la direction visuelle quand aucune référence n'a été donnée ; une règle métier que la spécification n'a pas tranchée). Déduisez de la spécification, de AGENTS.md et de la base de code ; recommandez des choix d'implémentation locaux.

Propriété des artefacts

• Écrit le code applicatif (plus CSS/tokens pour l'UI).
• Périmètre (docs/scope/) : seule l'étape 4 touche (statut de la fonctionnalité → in-progress, sous-boîtes du jalon, boîte Construire, pointeur de code). Marque une fonctionnalité done uniquement au niveau du workflow Prototype (construction plus sa propre vérification ; l'ingénieur a choisi de ne pas avoir de vérification séparée) ; une spécification Assumée ne bloque pas cela, elle reste marquée comme devant être ratifiée. Aux niveaux Alpha/Beta/GA, elle laisse la fonctionnalité in-progress pour que /check verify et /test la ferment, et ne coche jamais Verify it ou Test it. Ne crée jamais de fichiers dans docs/scope/ (seulement les périmètres ; l'analyse/recherche est le travail de /architect, dans le rationale.md de la spécification).
• N'écrit jamais le contenu d'une spécification ni ne délibère d'une décision (signale le besoin, se réfère à /architect) ; ne restructure jamais la racine AGENTS.md (c'est le travail de /audit) ; les nouvelles conventions de domaine passent par /sync ensuite. Une exception étroite : sur Construire maintenant, enregistrer comme spécification assumée (étape 0), /develop peut créer une spécification, mais uniquement dans Status: Assumed, et seulement les champs d'enregistrement d'hypothèse (décision due, hypothèse sur laquelle la construction repose, autorisé par, domaine de code, germes d'exigences). Il n'écrit jamais de justification et ne fait jamais passer une spécification Assumée au-delà de cet état ; /architect est responsable de la lever. C'est la seule spécification que /develop crée.
• Une seule touche de spécification sur une spécification existante : la ligne **Status**: (décision parapluie → celle du index.md, jamais celle d'un enfant), plus le remplissage de la ligne du pointeur de spécification de la fonctionnalité. Début de construction : Proposed → In Progress ; construction atterrit (fonctionnalité → done) : In Progress → Accepted (une spécification n'est pas Accepted tant que sa fonctionnalité n'est pas livrée). Ne modifiez jamais le contenu de la spécification, seulement cette ligne, chirurgicalement : relisez-la juste avant d'écrire ; état inattendu (déjà Accepted, Superseded) → signalez, n'écrasez pas. Ne faites jamais passer une spécification hors de Assumed (c'est la ratification, le travail de /architect) : une spécification Assumée reste Assumed tout au long de la construction même si la fonctionnalité est in-progress, donc elle ne peut jamais atteindre Accepted tant que /architect ne la ratifie pas. La fonctionnalité elle-même peut toujours être marquée done (décision de l'ingénieur) ; la spécification Assumée reste marquée comme devant être ratifiée, elle ne bloque pas done.
• Base des artefacts : docs/ par défaut, .workflow/ si docs/ est un site de documentation publié. Lisez à partir de celui qui existe (les chemins ici supposent docs/).
• Périmètre partagé : relisez-le juste avant de cocher, modifiez uniquement la case à cocher, le statut ou la ligne de pointeur spécifiques (ne réécrivez jamais le fichier) ; fonctionnalité pas comme prévu (déjà done, retravaillée) → signalez, n'écrasez pas.

---

Portabilité (tout OS, tout agent)

N'importe quel client Agent Skills, macOS/Linux/Windows. Les extraits de détection sont une référence POSIX ; utilisez les propres outils de fichiers multiplateformes de votre agent. Construit en ligne sur le thread principal (étape 3) ; les seuls sous-agents sont un scout en lecture seule qui explore le code (étape 2.5) et un researcher en lecture seule pour une vérification de documentation (étape 2.6, dégradation en construction à partir de connaissances sans capacité web), tous deux sur le modèle le moins cher. Les guides inclus (ui-guide.md, logical-guide.md, checklist.md) et le flux de construction après la porte (flow/build.md) sont des chemins relatifs au dossier de cette compétence ; le thread principal les lit. Pas de sélecteur de questions interactif → posez les invites en texte brut avec les mêmes options.

Exécution

Avant de construire : le projet doit déjà exister (sauf pour la tâche d'échafaudage)

Exception : s'il s'agit de la sous-tâche d'échafaudage de la fonctionnalité Stack et fondation d'architecture (l'invite dit scaffold, ou l'étape initialise le projet à partir de la spécification de la pile), créer le projet EST le travail. Lisez la spécification ARCHITECTURE ## Pile proposée ; exécutez l'initialiseur de projet du framework lui-même pour la pile que la spécification nomme ; installez les dépendances de base (framework, runtime principal, uniquement ce dont la première tranche a besoin) ; disposez les répertoires ; confirmez qu'un serveur de développement ou une construction s'exécute. Conservez le dépôt que l'initialiseur crée (ne le jetez jamais lors du déplacement du projet) ; s'il n'en a créé aucun et que l'intégration git est activée, git init. Les étapes d'échafaudage découlent de la décision de pile (une spécification de décision n'a pas de plan de construction). Installez juste à temps : PAS chaque bibliothèque que la spécification nomme (email, surveillance, etc.) ; chaque fonctionnalité ultérieure installe les siennes lorsqu'elle est construite ; seuls les outils transverses (lint, format, stricteté de type) viennent tôt, via /audit + la tâche d'outillage. Puis continuez.

Sinon, /develop construit dans un projet existant. Pas de squelette (pas de package.json/pyproject.toml/go.mod/manifeste, pas d'arborescence source) et pas la tâche d'échafaudage → arrêtez :

Aucun projet trouvé dans lequel construire. Exécutez d'abord l'étape d'échafaudage (la sous-tâche d'échafaudage de la fonctionnalité Stack et architecture, selon votre spécification d'architecture), puis exécutez /develop à nouveau.

Un projet existe (même un échafaudage nu) → continuez.

Avant de construire : fraîcheur et collaboration (ne construisez pas sur un état obsolète ou par-dessus un coéquipier)

Avant de muter quoi que ce soit (ignorez silencieusement si vous êtes seul, hors ligne ou n'utilisez pas git) : git fetch silencieusement ; base = main, sinon master ; nombre de commits de retard (git rev-list --count HEAD..origin/<base>) ; travail non commit (git status --short).

• En retard (nombre > 0) → arrêtez et prévenez : "Vous êtes N commits derrière origin/$BASE. Un coéquipier a peut-être déjà modifié ou livré cela. Tirez d'abord, puis réexécutez."
• Travail non commit dans la zone que vous allez toucher → prévenez : "Vous avez des modifications non commit ici. Commitez ou stash d'abord pour que cette construction ne s'emmêle pas avec elles." Laissez-les continuer s'ils insistent.
• Fonctionnalité in-progress dans le périmètre ET son domaine de code (chemin de la ligne de pointeur) a des commits récents d'un autre auteur (git log --format='%an' -- <area>) → prévenez : " semble être en cours de construction par quelqu'un d'autre. Coordonnez-vous avant de continuer." Confirmez avant de continuer.

Avertissements, pas des blocages durs, mais montrez-les.

Intégration Git : si le AGENTS.md le plus proche ## Git dit integration: on, lisez flow/git.md et suivez-le (créez une branche avant de construire, commitez au fur et à mesure que les jalons atterrissent) ; absent ou off → ne faites pas de git actif.

Étape 0 : La porte de la spécification (toujours en premier)

Une décision est-elle due et non enregistrée ? Ne jugez PAS cela par introspection ("est-ce que j'ai l'impression d'inventer quelque chose ?"), le modèle de construction rationalise une vraie décision comme "juste du câblage" et la laisse passer. Utilisez un test positif de couverture des entrées, qui est mécanique et plus difficile à contourner :

Énumérez chaque valeur que cette construction doit produire, calculer ou afficher (à partir des critères d'acceptation et de la conception de la spécification). Pour chacune, la spécification nomme-t-elle d'où elle vient (une entrée, une colonne de base de données, une dérivation à partir d'une valeur nommée, une décision antérieure) ? Toute valeur requise sans source nommée est une décision due.

Si une source n'est pas nommée, arrêtez-vous et acheminez vers la porte (/architect, ou enregistrez une spécification Assumée ; /develop implémente les décisions, il ne les prend pas). Une décision est également due lorsque vous devriez inventer :

• Un fournisseur, une bibliothèque, une intégration, un modèle de données ou un modèle transversal (par exemple fournisseur d'auth, DB/ORM, stratégie de cache).
• Une page ou un écran UI entier : son système de conception (design.md existe-t-il ? sinon, quelle direction ?), sections/composition, inventaire des composants, stratégie d'actifs (pas de capture d'écran, pas d'images dans le dépôt → par exemple une source en ligne). Due à moins qu'un design.md ET une spécification au niveau de la page ne les précisent.
• Le comportement d'une fonctionnalité (recherche, un assistant : "que doit-il faire exactement ?" est ouvert ; /architect pose ces questions). Due à moins qu'une spécification ne le définisse.

Ce que "détail d'implémentation local" signifie vraiment (l'exception étroite) : UNIQUEMENT un choix parmi les options que les sources nommées de la spécification autorisent déjà, un style de boucle, un nom de variable, quelle fonction d'aide appeler. Le moment où un choix détermine la source d'une valeur, ou un comportement qu'un critère d'acceptation contraint, il est structurel par définition, quelle que soit sa taille. Déduire "l'aujourd'hui de l'utilisateur à partir du fuseau horaire sur sa dernière ligne lue" n'est pas un détail local : cela choisit la source d'une valeur qu'un AC contraint, donc c'est dû. PAS dû pour une véritable implémentation pure : une petite correction de bogue, un composant correspondant à un design.md existant, le câblage de pièces dont les sources sont déjà nommées par la spécification, une retouche de copie, tout ce qui est entièrement régi par une spécification/design.md/AGENTS.md existant(e).

Ne codez pas en dur les noms de page ou un exemple particulier (le fuseau horaire est une illustration du modèle, pas une règle) ; appliquez le test de couverture d'entrée à tout ce qui a été demandé. Les faux négatifs sont le mode de défaillance, construire une vraie décision sans s'en rendre compte : lorsque la source d'une valeur requise n'est pas nommée, ou si vous n'êtes pas sûr, traitez-la comme due et demandez (panneau ci-dessous).

Lisez uniquement ce dont cette fonctionnalité a besoin, jamais toute l'arborescence docs/ : son seul fichier de périmètre et sa seule spécification directrice (fichier unique, ou index.md parapluie plus la spécification enfant qui spécifie cette sous-tâche). Aucune ligne d'autres fonctionnalités, fichiers de périmètre, espaces de travail ou spécifications non liées.

Vérifiez, dans l'ordre :

1. Localisez le fichier de périmètre de cette fonctionnalité (uniquement celui-ci). Monorepo → docs/scope/<workspace>/ pour le package de la tâche. Choisissez le fichier (scope.md, ou le <epic>.md correspondant dans une scission) à partir du tableau En un coup d'œil uniquement ; lisez juste la section de cette fonctionnalité. needs a decision sans pointeur de spécification encore → décision due et manquante. Malformé → signalez et demandez, ne devinez pas.
2. Ouvrez la spécification directrice via le pointeur spec de la fonctionnalité, en lisant uniquement ses sections de spécification de construction telles que définies dans le flux de construction (flow/build.md), point 2 de l'étape 1. Trouvée → c'est la spécification ; continuez. Pas de pointeur et pas de spécification liée → recherche ciblée dans docs/specs/<workspace>/ pour une correspondant au périmètre de cette fonctionnalité, jamais une lecture générale.
3. Le AGENTS.md le plus proche (espace de travail/domaine) peut déjà contenir la décision, synchronisée d'une fonctionnalité antérieure (par exemple "le fournisseur d'auth est déjà choisi") → continuez sans nouvelle spécification.

Décision due et non enregistrée → ne devinez pas, ne vous arrêtez pas silencieusement. Demandez (sélection unique ; AskUserQuestion sur Claude Code) :

• question: "Cela semble nécessiter d'abord une décision d'architecture : <nommez le choix structurel spécifique, ex. 'quel fournisseur d'auth + modèle de session'>. Comment souhaitez-vous la gérer ?"
• header: "spécification d'abord ?"
• options :
  1. L'architecturer d'abord : "Recommandé. Capturez la décision dans une spécification avant de construire, pour que la construction ait une spécification." → terminez ici avec le transfert ci-dessous. Ne construisez pas.
  2. Non, pas nécessaire : "J'ai jugé qu'il n'y a pas de vraie décision ici ; construisez directement." → passez au flux de construction (flow/build.md).
  3. Construire maintenant, enregistrer comme spécification assumée : "Construisez, mais écrivez d'abord l'hypothèse pour que la décision vive dans le dépôt, pas seulement dans ce chat. La spécification Assumée reste marquée comme devant être ratifiée (/architect), mais cela ne bloque jamais le marquage de la fonctionnalité done." → écrivez une spécification Assumée (ci-dessous), puis passez au flux de construction (flow/build.md), en laissant la fonctionnalité in-progress avec une note décision assumée (spec NNNN) dans le périmètre (docs/scope/).

L'outil ajoute automatiquement "Autre" comme option de texte libre.

Sur Construire maintenant, enregistrer comme spécification assumée, écrivez une spécification Assumée minimale avant de construire (c'est la seule écriture étroite de spécification que /develop possède ; voir Propriété des artefacts). Résolvez $SPEC_DIR comme /architect le fait (dépôt unique → docs/specs/ ; espace de travail monorepo → docs/specs/<workspace>/), prenez le prochain NNNN libre, et écrivez $SPEC_DIR/NNNN-<slug>.md :

# NNNN · <feature>

**Status**: Assumed
**Date**: <today>
**Authorized by**: <engineer>, during /develop

## Décision due
<le choix structurel spécifique qui n'a pas été fait>

## Hypothèse sur laquelle la construction repose
<l'hypothèse concrète que cette construction utilisera>

## Domaine de code
<les chemins que cette construction touchera>

## Exigences
<germes de critères d'acceptation issus du Done when du périmètre, le cas échéant>

## Ratifier
Cette décision a été enregistrée par /develop, non délibérée. Exécutez `/architect <feature>`
pour délibérer et la ratifier. En attendant, elle reste marquée comme une décision due ; cela ne bloque pas le marquage de la fonctionnalité `done`.

Pointez la ligne spec du périmètre de la fonctionnalité vers ce fichier. L'hypothèse est désormais durable : elle survit à /clear, les coéquipiers la lisent, et un futur /develop construira contre elle au lieu de deviner à nouveau. La spécification Assumée reste marquée comme devant être ratifiée ; elle ne bloque pas le marquage de la fonctionnalité done (voir flow/build.md, étape 4).

Sur L'architecturer d'abord, terminez par :

Exécutez ceci ensuite, puis revenez à /develop :

/architect <feature>: <la décision spécifique à trancher>

Une fois la spécification existante, exécutez /develop <task> à nouveau et je construirai selon elle.

Aucune décision due (implémentation pure) → sautez la question, continuez.

Flux de construction (étapes 1 à 4)

Une fois

…

[tronqué pour la traduction]