mustflow 1.15.97

package/templates/default/locales/fr/.mustflow/docs/agent-workflow.md

@@ -0,0 +1,368 @@
+---
+mustflow_doc: docs.agent-workflow
+locale: fr
+canonical: false
+revision: 13
+lifecycle: mustflow-owned
+authority: workflow-policy
+---
+
+# Flux De Travail Agent
+
+Ce document etend le routeur court dans `AGENTS.md`.
+Il definit la boucle operationnelle par defaut pour les agents qui travaillent dans une racine mustflow.
+
+## Orientation
+
+Consulte les fichiers listes dans `AGENTS.md` avant de lancer des modifications. Utilise `mf doctor` pour un controle rapide, en lecture seule, de l'etat d'installation, des command intents configures et des prochaines etapes suggerees.
+
+Utilise `REPO_MAP.md` uniquement comme carte de navigation generee pour la racine mustflow actuelle. Ce n'est pas une liste complete des fichiers et cela ne remplace pas la lecture des fichiers pertinents pour la tache.
+
+## Contexte Du Projet
+
+`.mustflow/context/` contient un contexte projet specifique a la tache pour les agents.
+Ce n'est pas une archive generale de documentation.
+
+- Lire `.mustflow/context/INDEX.md` seulement quand la tache exige du contexte projet, produit, domaine, interface, backend, donnees, securite ou operations.
+- Lire uniquement les fichiers de contexte selectionnes par l'index.
+- Traiter les fichiers de contexte comme secondaires par rapport aux instructions directes de l'utilisateur, au code actuel, aux tests, aux contrats de commandes et aux politiques configurees.
+- Ne pas deduire des objectifs projet manquants, des non-objectifs, des promesses d'API, des regles de donnees ni des design tokens.
+- Si `DESIGN.md` existe, le traiter comme une ancre externe optionnelle de design visuel pour le travail d'interface. Ne pas dupliquer ses design tokens dans `.mustflow/context/`.
+- Si le contexte entre en conflit avec les fichiers ou commandes actuels, signaler le conflit et se reporter a la source de plus haute autorite.
+
+## Activation Des Skills
+
+Les skills sont des procedures de tache, pas des outils autonomes. Activer une skill signifie lire
+le `.mustflow/skills/<name>/SKILL.md` correspondant et suivre sa procedure dans le contrat de
+commandes actuel.
+
+Au debut d'une tache et avant la premiere edition:
+
+1. Lire `.mustflow/skills/INDEX.md`.
+2. Comparer la tache actuelle aux scenarios listes.
+3. Lire chaque `SKILL.md` correspondant avant de modifier cette partie du travail.
+4. Si aucune skill ne s'applique, faire le plus petit changement prudent sous `AGENTS.md` et
+   `.mustflow/config/commands.toml`.
+
+Activer une skill plus tard si une nouvelle preuve change le type de tache. Par exemple, une
+commande configuree qui echoue active failure triage, un changement de contrat de test active
+test maintenance, et un changement de documentation ou de workflow active docs update.
+
+Quand plusieurs skills s'appliquent, suivre la skill la plus specifique pour chaque portee
+affectee et combiner uniquement leurs command intents declares. Les skills n'autorisent jamais
+des commandes shell brutes, des processus longue duree ni des ecritures hors de la portee de la tache.
+
+Quand une skill est utilisee, ou quand une skill plausible est volontairement ignoree, signalez
+brievement le nom de la skill et la raison de selection dans la prochaine mise a jour utilisateur
+ou dans le rapport final. Ne creez pas de worklog versionne uniquement pour enregistrer la selection
+des skills.
+
+## Stabilite Des Entrees
+
+Traiter les instructions utilisateur, les fichiers locaux, les contrats de commandes et les rapports generes comme des sources distinctes.
+Eviter de confondre ces sources.
+
+- Les instructions directes de l'utilisateur sont prioritaires.
+- Le `AGENTS.md` le plus proche est prioritaire sur des regles parentes plus larges.
+- `.mustflow/config/preferences.toml` contient des valeurs par defaut, pas des exigences obligatoires.
+- Les fichiers generes tels que `REPO_MAP.md`, `.mustflow/cache/**` et `.mustflow/state/**` peuvent devenir obsoletes.
+- Les resumes compactes sont des representations derivees de l'etat. Le code actuel, la configuration, les enregistrements de commandes et les instructions utilisateur actuelles les remplacent.
+
+Quand un fichier genere parait obsolete, rafraichis-le via la commande `mf` correspondante au lieu de l'editer manuellement.
+
+## Voies De Regles Effectives
+
+Ne reduis pas toutes les instructions a une seule liste de priorites. Resous les conflits selon le type de regle:
+
+- Objectif utilisateur: les instructions directes actuelles de l'utilisateur definissent la tache sauf si elles sont dangereuses.
+- Securite du host: les portes d'approbation, sandbox et execution du host restent valables quand elles sont plus strictes.
+- Regles de travail du depot: utiliser le `AGENTS.md` le plus proche et `.mustflow/config/*.toml`.
+- Execution de commandes: `.mustflow/config/commands.toml` est le contrat de commandes du projet.
+- Preuves de verification: les recus `mf run` et les fichiers actuels ont plus de poids que la sortie directe du shell du host.
+- Contexte et preferences: `.mustflow/context/*`, `preferences.toml` et les cartes generees sont des valeurs par defaut de moindre autorite.
+- Etat de session et cache: les resumes du host, `.mustflow/cache/**` et `.mustflow/state/**` ne remplacent jamais les fichiers actuels ni les instructions utilisateur actuelles.
+
+Les ensembles autorises se reduisent par intersection. Les actions interdites, exigences d'approbation,
+regles de confidentialite et regles de commandes destructrices s'accumulent. Si la regle effective n'est
+pas claire, arrete-toi et signale le conflit au lieu de deviner.
+
+## Rafraichissement Des Instructions
+
+Les longues sessions peuvent provoquer une derive des instructions. Traite le rafraichissement des instructions comme un point de controle obligatoire, pas comme un compteur dans les fichiers du projet.
+
+Rafraichis les instructions mustflow a ces moments:
+
+- debut de session
+- debut d'une nouvelle tache
+- avant la premiere edition
+- avant l'execution de commandes lorsque la tache et l'intention de commande actuelles n'ont pas deja un rafraichissement de commande recent
+- apres edition de `AGENTS.md` ou `.mustflow/**`
+- apres changement de racine ou entree dans un depot imbrique
+- apres compaction ou resume du contexte
+- avant le rapport final
+- apres le seuil configure de tours, d'appels d'outils ou de volume de sortie
+
+Utilise `[refresh]` dans `.mustflow/config/mustflow.toml` pour choisir le niveau de rafraichissement:
+
+- `light`: relire `AGENTS.md` et `.mustflow/docs/agent-workflow.md`
+- `command`: relire `AGENTS.md` et `.mustflow/config/commands.toml`
+- `edit`: relire `AGENTS.md`, `.mustflow/config/mustflow.toml` et `.mustflow/docs/agent-workflow.md` avant les modifications sensibles
+- `report`: relire `AGENTS.md`, `.mustflow/config/mustflow.toml` et `.mustflow/config/preferences.toml` avant le rapport final
+- `skill`: relire `AGENTS.md` et `.mustflow/skills/INDEX.md`
+- `full`: relire la sequence complete de lecture mustflow
+
+`before_command_run` est un point de controle de fraicheur pour l'intention de commande actuelle, pas une obligation de relire tous les fichiers avant chaque commande repetee lorsque le contrat de commande n'a pas change.
+
+Ne pas ecrire de compteurs de tours, de compteurs de messages ni d'activite de session dans le depot. Si un hote d'agent suit l'etat de rafraichissement, il doit utiliser un cache local ou un etat gere par l'hote hors des documents versionnes du projet. Les skills peuvent decrire le comportement de rafraichissement, mais ne sont pas des hooks fiables de cycle de vie.
+
+## Compaction Du Contexte
+
+`compaction` n'est pas une fonction de collecte de donnees activee par defaut. C'est une politique de securite pour de futurs harnesses ou hosts. Le modele par defaut la garde desactivee et ne declare que des regles de securite.
+
+Ne stocke pas de raisonnement cache, de secrets, de transcriptions completes, de sortie complete du terminal, d'evenements bruts ni de journaux bruts de commandes dans le projet. Si un host cree des resumes a l'avenir, ils doivent etre relies a leurs sources et rester moins autoritaires que les fichiers actuels et les instructions utilisateur actuelles.
+
+## Limite Du Contrat De Harness
+
+mustflow n'est pas un environnement autonome d'execution d'agents. C'est une couche de contrat locale au depot pour les harnesses d'agents.
+
+- Contrat du cerveau: `AGENTS.md`, ce fichier de flux de travail et les documents de skills definissent le comportement modele attendu.
+- Contrat des mains: `.mustflow/config/commands.toml` et `mf run` definissent une execution sure des commandes.
+- Contrat de session: les enregistrements d'execution, points de controle bornes et handoffs compactes fournissent des preuves pour la reprise.
+
+Ne cree pas de dossiers workers, de systemes de persona, d'orchestration de flotte, de journaux bruts d'evenements, ni de boucles autonomes, sauf si le depot ajoute explicitement ces surfaces optionnelles.
+
+## Phases Des Taches Longue Duree
+
+Pour les taches longue duree ou reprises, separe ces phases:
+
+1. Plan: lire l'objectif de la tache, les regles du depot, le contrat de commandes et les criteres d'acceptation.
+2. Travail: effectuer le plus petit changement sur et adapte a l'unite courante.
+3. Verification: executer uniquement les command intents oneshot configures, de preference via `mf run`.
+4. Evaluation: evaluer le resultat par rapport aux criteres d'acceptation originaux et aux recus d'execution.
+5. Handoff: laisser un handoff compacte quand la tache est incomplete, bloquee ou necessite une continuation.
+
+La phase d'evaluation ne doit pas considerer la declaration de completion du worker comme suffisante. Elle utilise l'objectif de la tache, les fichiers modifies, le contrat de commandes et les recus d'execution.
+
+## Politique De Comportement Git
+
+Les operations Git qui modifient l'etat ou l'historique sont refusees par defaut.
+
+- `git.auto_stage = false`: ne pas preparer de fichiers sans demande utilisateur.
+- `git.auto_commit = false`: ne pas creer de commit sans demande utilisateur.
+- `git.auto_push = false`: ne pas pousser sans demande utilisateur.
+
+Ces valeurs sont des preferences de depot, pas des autorisations. Elles ne remplacent pas les instructions directes de l'utilisateur, `.mustflow/config/commands.toml` ni la politique d'approbation dans `.mustflow/config/mustflow.toml`. En particulier, `git.auto_commit = true` n'accorde pas l'autorisation de push, et `git.auto_push = true` ne peut pas etre active via `mf init`.
+
+## Politique D'Impact De Version
+
+Les reglages d'impact de version sont des preferences du depot. Ils guident les modifications de
+fichiers de version, mais ne remplacent pas les instructions utilisateur directes, les regles de
+securite de l'hote ni les controles d'approbation dans `.mustflow/config/mustflow.toml`.
+
+Utiliser `[release.versioning]` dans `.mustflow/config/preferences.toml` quand le code, les modeles,
+les schemas, le comportement CLI, les metadonnees du paquet, la documentation visible par l'utilisateur,
+la sortie d'installation ou les tests changent.
+
+- `impact_check = true`: signaler si le diff semble exiger un changement de version du paquet ou du modele.
+- `suggest_bump = true`: suggerer patch, minor ou major lorsque les preuves sont claires.
+- `auto_bump = true`: appliquer le changement de version de paquet ou de modele approprie quand
+  l'impact est clair, que la source de version est localisee et qu'aucune regle utilisateur, hote
+  ou approbation plus stricte ne le bloque.
+- `auto_bump = false`: laisser les fichiers de version de paquet et de modele inchanges sauf si
+  l'utilisateur demande un changement de version ou une preparation de release.
+- `require_user_confirmation = true`: demander confirmation avant d'editer les fichiers de version.
+- `require_user_confirmation = false`: ne pas ajouter d'etape de confirmation separee quand
+  `auto_bump = true`.
+
+Avant de suggerer ou d'appliquer un changement de version, localiser la source de version propre au depot.
+Ne pas supposer que `package.json` est le seul fichier de version. Examiner les manifests, documents de
+release et schemas de mise a jour existants correspondant aux langages et frameworks du depot, puis
+signaler quels fichiers font autorite et quels fichiers sont derives.
+
+Candidats courants de source de version:
+
+- JavaScript ou TypeScript: `package.json` et lockfiles quand ils dupliquent les metadonnees du paquet.
+- Python: `pyproject.toml`, `setup.cfg`, `setup.py` ou fichiers `__version__` du paquet.
+- Rust: `Cargo.toml`; considerer `Cargo.lock` seulement si le depot traite le lockfile comme metadonnee de release.
+- Go: tags et documentation de release d'abord; `go.mod` seulement si le chemin du module ou les metadonnees d'outils sont pertinents.
+- Java ou Kotlin: `pom.xml`, `build.gradle`, `build.gradle.kts` ou `gradle.properties`.
+- .NET: `*.csproj`, `Directory.Build.props` ou `*.nuspec`.
+- Ruby, PHP, Dart ou Swift: `*.gemspec`, `lib/**/version.rb`, `composer.json`, `pubspec.yaml` ou `Package.swift`.
+- Conteneurs, charts ou apps: `Chart.yaml`, labels d'image, manifests d'application, notes de release ou metadonnees de deploiement.
+- Modeles mustflow: metadonnees du paquet, manifests de modele, exemples de documentation et tests qui verifient les versions installees.
+
+Quand une version change, garder les metadonnees du paquet, les versions de manifests de modeles,
+les exemples de documentation et les tests synchronises selon les preferences `sync_*`.
+
+## Politique D'Execution Des Commandes
+
+Ne pas deduire les commandes a partir de `package.json`, `Makefile`, `justfile`, `Taskfile.yml` ou des fichiers source.
+Utiliser `.mustflow/config/commands.toml` comme contrat de commandes.
+
+Un command intent est eligible a l'usage agent uniquement quand toutes ces conditions sont vraies:
+
+- `status = "configured"`
+- `lifecycle = "oneshot"`
+- `run_policy = "agent_allowed"`
+- `stdin = "closed"`
+- `timeout_seconds` est un entier positif
+- La commande est declaree avec `argv`, ou avec `mode = "shell"` et `cmd`
+- `cwd` reste dans la racine mustflow actuelle
+
+`manual_only` est un statut pour les nouvelles configurations. `run_policy = "manual_only"` peut etre lu pour compatibilite avec les anciennes configurations, mais les nouveaux modeles doivent utiliser `status = "manual_only"`.
+
+Preferer `mf run <intent>` pour que le projet recoive un enregistrement d'execution concis dans `.mustflow/state/runs/latest.json`.
+
+Executer les command intents `mf run` en serie. Ne pas lancer un second `mf run` tant qu'une autre
+intention configuree est encore en cours. Les intentions qui declarent des `writes` non vides sont
+des phases de verification exclusives; attendre leur fin avant d'executer tout autre `mf run`. C'est
+particulierement important quand une intention reecrit une sortie de paquet comme `dist/`, car
+l'executable local `mf` peut etre charge depuis cette sortie.
+
+Les shells du host peuvent executer des commandes, mais les commandes projet executees directement ne
+comptent pas automatiquement comme verification mustflow. Si une commande contourne `mf run`, traite sa
+sortie comme un contexte de confiance plus faible, sauf si l'utilisateur a approuve explicitement une
+exception manuelle et si le rapport final indique qu'aucun recu d'execution mustflow n'a ete produit.
+
+Ne pas executer directement des serveurs de developpement, watchers, lancements de navigateur, invites interactives ou processus en arriere-plan. Signaler plutot l'intent omis et sa raison.
+
+## Politique D'Edition
+
+Garder les changements dans le perimetre de la tache. Ne pas faire de refactorings opportunistes.
+Ne pas modifier les chemins proteges de `.mustflow/config/mustflow.toml`.
+
+Utiliser le style existant du projet. Si le style n'est pas clair, appliquer les valeurs par defaut dans `.mustflow/config/preferences.toml`.
+
+## File De Revision De Documentation
+
+Lorsqu'un agent cree ou modifie une documentation visible par les utilisateurs, de workflow, de
+modele, de contexte ou de skill, enregistre le document avec `mf docs review add <path>` sauf si
+l'utilisateur demande explicitement de ne pas le suivre. La file est stockee dans
+`.mustflow/review/docs.toml` et n'est creee que lorsque c'est necessaire.
+
+La revision peut etre terminee par un humain, un LLM, un outil ou un processus externe. Enregistre
+seulement le type large de reviseur et des identifiants libres comme l'id du reviseur, le fournisseur,
+le modele, l'intention de commande et le resume. Ne maintiens pas de liste fixe de produits LLM
+specifiques.
+
+Utilise `mf docs review approve <path> --reviewer-kind <kind> --reviewer-id <id>` pour masquer un
+document approuve de la liste par defaut tout en gardant l'historique. Utilise `needs-human` lorsque
+le reviseur ne peut pas approuver avec confiance, et `ignore` seulement lorsque le depot decide
+intentionnellement de sauter la revision.
+
+Les fichiers generes doivent etre rafraichis via des outils:
+
+- `REPO_MAP.md` via `mf map --write`
+- `.mustflow/cache/mustflow.sqlite` via `mf index`
+- `.mustflow/state/runs/latest.json` via `mf run <intent>`
+
+## Verification
+
+Utiliser les intentions de commande configurées pour les controles. Noms d'intent typiques:
+
+- `mustflow_check`
+- `test`
+- `lint`
+- `build`
+- `docs_validate`
+
+Si un intent attendu est manquant, desactive, manuel uniquement ou non configure, ne pas inventer de remplacement.
+Signaler ce qui a ete omis et pourquoi.
+
+## Selection De Verification
+
+Utiliser `[verification.selection]` dans `.mustflow/config/preferences.toml` pour choisir l'etendue de verification.
+Ces preferences n'accordent pas l'autorisation d'executer des commandes. Elles indiquent seulement quels command intents configures examiner.
+
+La verification doit etre proportionnelle au risque. Preferer `test_related`, `test_fast`, `build`
+ou les controles propres a la documentation quand ils sont configures et couvrent la surface modifiee.
+Utiliser les suites completes larges pour les comportements transversaux, le risque de release,
+l'absence de couverture plus etroite ou quand la politique configuree les exige explicitement. Si
+un intent plus etroit conviendrait mais est `unknown`, `manual_only` ou absent, signaler ce manque
+au lieu de traiter silencieusement la suite la plus lente comme valeur normale.
+
+- `strategy = "risk_based"`: preferer les controles configures les plus petits qui couvrent le comportement change, la surface publique, le contrat de commandes et la zone de risque.
+- `strategy = "targeted"`: preferer les controles directement lies sauf si l'utilisateur, une skill ou une politique exige une couverture plus large.
+- `strategy = "full"`: preferer toute la suite de verification configuree applicable.
+- `prefer_related_tests = true`: chercher un intent de test plus etroit et pertinent avant un intent large.
+- `skip_docs_only_full_test = true`: les changements de documentation seuls peuvent eviter les tests larges quand la validation docs couvre la surface modifiee.
+- `skip_translation_only_full_test = true`: les changements de traduction seuls peuvent eviter les tests larges quand le comportement source n'a pas change.
+- `skip_copy_only_full_test = true`: les changements de texte seuls peuvent eviter les tests larges quand aucun comportement, schema, modele ou contrat de commande n'a change.
+- `report_skipped = true`: le rapport final doit nommer les controles omis et la raison.
+
+Si des indices montrent que comportement, securite, donnees, contrats de commandes, sortie de release ou modeles generes ont change,
+ne pas utiliser une preference d'omission pour masquer le risque. Passer a l'intent configure pertinent ou signaler que l'intent requis manque.
+
+## Verrou De Verification
+
+Ne pas affaiblir la validation pour donner l'impression que la tache est terminee.
+
+Les agents ne doivent pas:
+
+- supprimer des tests en echec pour faire passer les controles
+- affaiblir des assertions sans expliquer pourquoi
+- ignorer des command intents pertinents
+- marquer des command intents `not_applicable` uniquement pour eviter un echec
+- changer les criteres d'acceptation apres implementation
+
+Les agents peuvent mettre a jour des tests quand le comportement vise a change, quand l'ancien test est incorrect, ou quand le nouveau comportement exige une nouvelle couverture. Expliquer ce changement dans le rapport final.
+
+## Politique De Pertinence Des Tests
+
+Les tests sont des contrats de comportement, pas des artefacts permanents.
+
+Utiliser `[testing.authoring]` dans `.mustflow/config/preferences.toml` pour guider la facilite
+avec laquelle les agents creent de nouveaux tests. La valeur par defaut
+`new_test_policy = "evidence_required"` signifie qu'un nouveau test doit etre appuye par une preuve
+de contrat de comportement, comme un comportement public modifie, un risque de regression, une regle
+de configuration, un contrat de schema ou un chemin de securite/donnees. Cette preference guide
+seulement l'ecriture des tests; elle n'affaiblit pas la verification requise et ne justifie pas la
+suppression de tests valides.
+
+Les agents ne doivent pas:
+
+- reintroduire un comportement supprime uniquement parce que d'anciens tests l'attendent
+- conserver des tests pour des fonctionnalites supprimees intentionnellement
+- supprimer des tests en echec uniquement pour faire passer la validation
+- affaiblir des assertions sans expliquer le changement de comportement
+- mettre a jour des snapshots uniquement pour faire passer les tests
+
+Les agents peuvent mettre a jour ou supprimer des tests quand le comportement teste a ete retire intentionnellement, quand le contrat public a change, quand le test encode seulement des details d'implementation supprimes, quand la couverture est dupliquee par un test plus robuste, ou quand un snapshot est obsolete.
+
+Quand des tests sont ajoutes, mis a jour, supprimes, ou identifies comme candidats obsoletes, signaler le contrat de comportement, les tests concernes, les commandes executees, les command intents omis et les risques de test restants.
+
+## Budget, Approbation Et Isolation
+
+Utiliser `.mustflow/config/mustflow.toml` pour la politique de securite des longues taches.
+
+- `[budget]` limite les iterations, le temps mur, les executions de commandes, le volume de sortie et les echecs repetes.
+- `[approval]` liste les actions qui exigent une approbation humaine avant de continuer.
+- `[isolation]` decrit la limite preferee de worktree ou de sandbox pour les taches longue duree.
+
+Quand une limite de budget ou une porte d'approbation est atteinte, arrete-toi et signale. Utilise un handoff seulement lorsque ce depot active explicitement un flux de handoff. Ne pas continuer en boucle.
+Ne pas executer un travail autonome longue duree dans un worktree principal avec des changements sales quand la politique d'isolation exige un worktree ou une sandbox separee.
+
+## Gestion Des Echecs
+
+Quand une commande echoue:
+
+1. Conserver le nom original du command intent.
+2. Analyser le code de sortie et la fin tronquee de la sortie.
+3. Identifier la cause racine la plus probable de l'echec.
+4. Eviter de modifier des fichiers non lies.
+5. Relancer la verification pertinente la plus ciblee apres correction.
+6. Signaler les controles omis et les risques restants.
+
+Ne pas stocker de journaux bruts complets, de secrets, de donnees client ni de longues transcriptions dans `.mustflow/`.
+
+## Rapport
+
+Les rapports finaux doivent inclure:
+
+- Fichiers modifies
+- Command intents executes
+- Command intents omis avec raisons
+- Resultat de verification
+- Risque restant
+
+Suggere des commits uniquement quand `.mustflow/config/preferences.toml` l'autorise.

package/templates/default/locales/fr/.mustflow/skills/INDEX.md

@@ -0,0 +1,78 @@
+---
+mustflow_doc: skills.index
+locale: fr
+canonical: false
+revision: 43
+authority: router
+lifecycle: mustflow-owned
+---
+
+# Skills Index
+
+Consult only the skill document relevant to the current task. If no specific skill applies,
+refer to `AGENTS.md` and `.mustflow/config/commands.toml` to implement the most minimal safe change.
+
+## Selection Rules
+
+- At task start and before the first edit, compare the user request and expected changed files with
+  the triggers below.
+- If one or more triggers match, read each `SKILL.md` before editing that scope.
+- When a skill is used, or when a plausible skill is intentionally skipped, leave a concise
+  selection note in the next user-facing update or final report.
+- If a new condition appears during the task, such as a command failure, test contract change, or
+  documentation change, pause and read the newly matching skill before continuing.
+- If no trigger applies, do not invent a skill. Continue with `AGENTS.md`,
+  `.mustflow/docs/agent-workflow.md`, and `.mustflow/config/commands.toml`.
+- Skill documents guide procedure only. They do not authorize command execution outside the declared
+  command intents.
+- Keep the route table compact: each route states the trigger, required input, edit scope, risk,
+  verification intents, and expected output.
+
+| Trigger | Skill Document | Required Input | Edit Scope | Risk | Verification Intents | Expected Output |
+| --- | --- | --- | --- | --- | --- | --- |
+| Generated artifacts, packaged files, binary assets, reports, or downloadable outputs are created, referenced, or reported | `.mustflow/skills/artifact-integrity-check/SKILL.md` | Artifact paths, source or generation path, package rules, and artifact expectations | Artifact references, package metadata, tests, and documentation | unverified or stale artifact claim | `changes_status`, `changes_diff_summary`, `test_release`, `build`, `mustflow_check` | Artifact evidence, inclusion or format checks, skipped checks, and integrity risk |
+| Code changes need review before report | `.mustflow/skills/code-review/SKILL.md` | Diff and task goal | Changed files | behavior and regression | `test`, `test_related`, `test_audit`, `lint` | Findings or no-issue note |
+| Code is being refactored, reorganized, renamed, deduplicated, simplified, or structurally improved while existing behavior should be preserved | `.mustflow/skills/behavior-preserving-refactor/SKILL.md` | Refactoring goal, target area, behavior evidence, local patterns, current changed files, and command contract entries | Small behavior-preserving refactor steps, related tests, and directly synchronized docs or contracts | hidden behavior change, broad cleanup, misleading abstraction, unsafe deduplication, or unverified legacy change | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Goal, behavior evidence, structural risks, refactoring ladder, changes made, excluded behavior changes, verification, and remaining risks |
+| Class inheritance, base classes, abstract classes, template methods, protected state, mixins, framework subclasses, or subtype hierarchies are introduced, reviewed, or refactored, especially for behavior reuse or feature variants | `.mustflow/skills/composition-over-inheritance/SKILL.md` | Inheritance surface, reuse goal, change dimensions, local composition patterns, compatibility constraints, current changed files, and command contract entries | Classes, functions, role interfaces, policies, strategies, adapters, decorators, state machines, tests, wrappers, and directly synchronized docs or templates | fragile parent-child coupling, subclass explosion, broken substitutability, hidden protected state, over-composition, or untested behavior-preserving refactor | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Inheritance review, keep-or-replace decision, change dimensions, composition pattern, tests, verification, and remaining hierarchy risk |
+| Multiple interchangeable algorithms, policies, calculations, scoring methods, sorting methods, recommendation methods, pricing rules, discount rules, shipping methods, payment methods, notification methods, permission policies, provider choices, feature-flag variants, or repeated branches choose how to do the same kind of work | `.mustflow/skills/strategy-pattern/SKILL.md` | Stable workflow, variants and shared purpose, current branch locations, common input and output shape, selection criteria, local Result, dependency injection, decorator, registry, and test patterns, current changed files, and command contract entries | Strategy function types, interfaces, concrete strategies, selectors, resolvers, registries, decorators, context wiring, tests, and directly synchronized docs or templates | over-abstracted small branch, wrong use-case grouping, context knowing concrete strategies, silent fallback, unsafe user-selected strategy, request-stateful strategy, strategy combination explosion, or untested selector behavior | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Strategy classification, shared contract, strategy registry, selector or resolver, default and unsupported-key behavior, tests, verification, and remaining strategy risk |
+| State-changing user or system intents, command data objects, command handlers, command buses, idempotency, authorization, transactions, outbox events, audit logs, retries, concurrency, long-running jobs, or external side effects need one traceable execution unit | `.mustflow/skills/command-pattern/SKILL.md` | User or system intent, source boundary, payload, actor and context, affected resources, local Result, repository, gateway, unit-of-work, outbox, idempotency, audit, retry, and test patterns | Command payloads, command context, handlers, command bus wiring when justified, idempotency, outbox, audit, retry, transaction, controller or worker adapters, tests, and directly synchronized docs or templates | command ceremony for reads, giant handler, hidden domain policy, unsafe duplicate side effect, transaction and external-call coupling, missing audit trail, retry without idempotency, or untested command boundary | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Command classification, payload and context shape, handler dependencies, domain delegation, transaction, outbox, idempotency, retry, audit, concurrency choices, tests, verification, and remaining command safety risk |
+| Controllers, handlers, command handlers, workers, services, or UI events need one stable high-level entry point over a complex subsystem, repeated multi-step workflow, multiple dependencies, external services, storage, queues, caches, transactions, idempotency, retries, logging, or normalized results | `.mustflow/skills/facade-pattern/SKILL.md` | Caller surface, high-level operation, repeated internal sequence, leaked subsystem details, dependencies, expected response and errors, authorization, idempotency, retry, transaction, observability, security, performance, local Result, port, adapter, command, and test patterns | Facade request, context, response, and error types, injected collaborators, orchestration, mappers, error normalizers, idempotency, transactions, retries, events, cache invalidation, logging, tests, and directly synchronized docs or templates | pass-through wrapper, god service, hidden domain policy, public internal steps, SDK or ORM leakage, facade-to-facade coupling, request-stateful facade, unsafe retry, external call inside transaction, or untested subsystem orchestration | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Facade classification, caller simplification, request and context shape, normalized result, injected dependencies, delegated domain rules, transaction/idempotency/retry/logging choices, tests, verification, and remaining facade risk |
+| Business decisions, validation, authorization, pricing, eligibility, state transitions, domain events, effect descriptions, or calculations are mixed with databases, HTTP handlers, repositories, SDK calls, files, queues, logs, metrics, clocks, randomness, environment reads, payments, emails, or framework request/response objects | `.mustflow/skills/pure-core-imperative-shell/SKILL.md` | Business action, decision facts, side effects, current boundary shape, local result/event/effect patterns, behavior evidence, changed files, and command contract entries | Core decision functions, shell orchestration, mappers, result/error types, events, effect descriptions, tests, and directly synchronized docs or templates | business rules hidden in I/O, non-deterministic core, mock-heavy tests, stale decisions, duplicate side effects, transaction/external-call coupling, or over-layered trivial CRUD | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Decision isolated, explicit core input and output, shell responsibilities, events or effects, typed business failures, tests, verification, and remaining mixed-logic risk |
+| Domain objects have lifecycle state, status fields, phase or step fields, allowed actions depend on state, transitions are scattered, external results change state, duplicate events are possible, or state changes need transition tables, guards, effects, history, idempotency, or concurrency control | `.mustflow/skills/state-machine-pattern/SKILL.md` | Entity, state field, state list, event list, terminal states, current state-changing code, guards, context facts, effects, history, idempotency, concurrency risks, local Result and outbox patterns, and command contract entries | State unions, event unions, transition tables, guard functions, pure transition functions, dispatch shell, outbox, transition logs, idempotency records, available-action helpers, tests, and directly synchronized docs or templates | direct state assignment, hidden invalid transition, silent no-op, impure guard, external effect before commit, duplicate webhook damage, state explosion, stale concurrent transition, UI/server rule drift, or untested lifecycle | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Lifecycle classification, states and events, transition table, guards and context facts, effects and history, idempotency and concurrency choices, direct assignment cleanup, tests, verification, and remaining state-machine risk |
+| Expected failures, meaningful absence, null or undefined returns, thrown business errors, boolean success flags, raw string errors, repository lookups, validation, parsing, external adapter errors, or boundary error mapping need explicit value-based handling | `.mustflow/skills/result-option/SKILL.md` | Operation semantics, absence and failure cases, local Result/Option/error conventions, layer ownership, public response rules, sensitive data constraints, changed files, and command contract entries | Result and Option helpers, function signatures, typed errors, boundary mappers, repository/service/controller contracts, tests, and directly synchronized docs or templates | hidden null, swallowed error, thrown business failure, ambiguous boolean result, provider error leakage, public error-shape drift, or over-wrapped total function | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Return shape decision, error codes and categories, absence handling, boundary conversions, preserved throw paths, tests, verification, and remaining exception or null risk |
+| Repeated null, undefined, None, or nil checks, optional dependencies, disabled integrations, null loggers, null analytics, null caches, optional notifications, no-op collaborators, identity processors, or safe neutral implementations are introduced or refactored | `.mustflow/skills/null-object-pattern/SKILL.md` | Optional collaborator, interface, absence semantics, caller branch needs, neutral output, required side effects, security, money, data, and audit risks, assembly location, local Result, Option, dependency injection, strategy, and test patterns | Interfaces, null, no-op, disabled, identity, empty, deny-all, or failing implementations, assembly wiring, non-null dependency types, tests, and directly synchronized docs or templates | hidden required failure, fake success, authorization bypass, dropped persistence, skipped audit, swallowed initialization error, stateful null object, or caller still nullable | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Absence classification, null object decision, neutral implementation, assembly selection, nullable caller cleanup, tests, verification, and remaining hidden-failure risk |
+| User requirements, acceptance criteria, issue reports, bug reports, product notes, compatibility promises, or examples must be preserved as regression coverage before or during implementation | `.mustflow/skills/requirement-regression-guard/SKILL.md` | Requirement source, observable behavior, existing tests or fixtures, implementation scope, changed files, and command contract entries | Focused tests, fixtures, examples, schemas, docs, and implementation changes directly tied to the requirement | untested requirement, invented acceptance criteria, weakened tests, hidden behavior drift, or unverifiable implementation claim | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `test_audit`, `docs_validate_fast`, `test_release`, `mustflow_check` | Requirement sources, coverage map, guards added or reused, implementation changes, deferred requirements, verification, and remaining regression risk |
+| Multiple AI workers, subagents, external agents, parallel task runners, or worktree-based worker roles are planned or used for one repository task | `.mustflow/skills/multi-agent-work-coordination/SKILL.md` | Task goal, worker roles, write permissions, file ownership, workspace isolation, credential boundary, merge owner, and command contract entries | Coordination plan, worker instructions, ownership boundaries, merge notes, and directly synchronized tests or docs | same-file races, conflicting instructions, leaked credentials, shared auth cache, untrusted worker output, merge drift, or unverified parallel result | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `docs_validate_fast`, `test_release`, `mustflow_check` | Worker limit, role map, write ownership, isolation and credential boundaries, merge owner, verification, skipped checks, and remaining coordination risk |
+| An unfamiliar codebase area needs an evidence-based map before planning, implementation, or reporting | `.mustflow/skills/codebase-orientation/SKILL.md` | User request, target area, relevant instructions, and current source, test, schema, template, configuration, or documentation files | Read-only orientation notes and any smallest follow-up edit chosen from inspected evidence | stale documentation, wrong ownership boundary, or invented architecture claim | `changes_status`, `changes_diff_summary`, `mustflow_check` | Scope inspected, entrypoints, flow map, ownership boundaries, verification options, risks, unknowns, and smallest safe next step |
+| Repository improvement, audit, prioritization, stabilization, polish, onboarding, contributor-readiness, production-readiness, or iterative improvement is requested without a single predetermined edit | `.mustflow/skills/repo-improvement-loop/SKILL.md` | User goal, improvement mode, repository evidence, candidate risks, current changed files, and command contract entries | Repository diagnosis, ranked candidates, and at most one scoped improvement cycle unless the user explicitly requests analysis-only | idea spam, ungrounded prioritization, autonomous loop drift, broad rewrite, or unverified improvement claim | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Mode, evidence inspected, scored candidates, selected improvement, files changed or analysis-only note, verification, next improvement question, and stop reason |
+| A dense plan, suggestion, code explanation, review result, flow map, or decision set would be easier to inspect as a safe static HTML review artifact | `.mustflow/skills/visual-review-artifact/SKILL.md` | User request, artifact goal, target audience, source evidence, output path, and relevant command contract entries | Temporary `.mustflow/state/artifacts/**` output or explicitly requested versioned HTML artifact, plus direct references, docs, or package metadata | unsafe HTML behavior, prompt injection, unverified artifact claim, or mistaken approval authority | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Artifact kind and path, source evidence, review-only boundary, local interactions, verification, skipped checks, and remaining decision risk |
+| Changed files need risk classification and verification selection | `.mustflow/skills/diff-risk-review/SKILL.md` | Changed-file list, diff summary, and task goal | Changed surfaces and verification report | under- or over-verification | `changes_status`, `changes_diff_summary`, `test`, `test_related`, `test_audit`, `lint`, `build`, `docs_validate`, `mustflow_check` | Risk level, verification choice, rollback notes |
+| Declared behavior must stay aligned across code, schemas, templates, tests, and docs | `.mustflow/skills/contract-sync-check/SKILL.md` | Changed files, intended behavior, source of truth, derived surfaces, and command contract entries | Contract source and required synchronized surfaces | contract drift | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Contract source, synchronized surfaces, deferred surfaces, verification, and drift risk |
+| Dates, versions, counts, durations, limits, metrics, benchmarks, prices, percentages, or other numeric facts are created, edited, or reported | `.mustflow/skills/date-number-audit/SKILL.md` | Date or numeric fact, source of truth, dependent surfaces, precision expectation, and command contract entries | Numeric statements, metadata, tests, docs, templates, and reports | invented, stale, or mismatched numeric claim | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Audited values, source of truth, synchronized surfaces, skipped checks, and remaining numeric risk |
+| Packages, runtimes, tools, commands, services, or platform capabilities are assumed, added, invoked, or documented | `.mustflow/skills/dependency-reality-check/SKILL.md` | Dependency or capability, repository declarations, version or capability claim, and command contract entries | Dependency declarations, imports, command metadata, tests, and docs | invented or unavailable dependency | `changes_status`, `changes_diff_summary`, `build`, `test_release`, `mustflow_check` | Dependency status, synchronized surfaces, verification, and remaining dependency risk |
+| External systems, protocols, SDKs, databases, webhooks, queues, files, caches, framework requests or responses, AI models, browser storage, or provider data cross the core boundary or need port/adapter translation, error mapping, retry, idempotency, security, or observability handling | `.mustflow/skills/adapter-boundary/SKILL.md` | External system or protocol, inbound/outbound direction, internal use case, local port/adapter patterns, provider risk, changed files, and command contract entries | Ports, adapters, mappers, controllers, workers, stores, gateways, tests, fixtures, assembly wiring, and directly synchronized docs or templates | provider leakage, pass-through wrapper, unclassified external failure, duplicate side effect, unsafe retry, missing timeout, secret or personal-data leak, or untested integration drift | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Boundary classification, internal port, provider containment, validation and mapping, timeout/retry/idempotency handling, security notes, verification, and remaining provider risk |
+| Core or application logic creates, imports, resolves, or hides external dependencies such as databases, SDKs, clocks, random generators, configuration, loggers, framework objects, filesystems, queues, AI clients, or payment/email providers | `.mustflow/skills/dependency-injection/SKILL.md` | Target code area, hidden dependency, intended business capability, layer ownership, local port/adapter patterns, changed files, and command contract entries | Core logic signatures, ports, adapters, assembly roots, tests, and directly synchronized docs or templates | hidden global state, untestable business logic, provider leakage, lifecycle drift, or service-locator coupling | `changes_status`, `changes_diff_summary`, `test_related`, `test`, `lint`, `build`, `docs_validate_fast`, `test_release`, `mustflow_check` | Dependency boundary, direct dependencies found, injection style, ports/adapters, assembly boundary, tests or fakes, verification, and remaining dependency leakage |
+| Git reports CRLF/LF warnings or tracked text files may need line-ending normalization | `.mustflow/skills/line-ending-hygiene/SKILL.md` | Warning text or changed-file evidence, line-ending policy, changed-file status, and command contract entries | Line-ending policy files, tracked text files, command metadata, tests, and reports | silent working-tree rewrite or policy drift | `line_endings_check`, `changes_status`, `mustflow_check` | Policy found, drift files, normalization status, verification, and remaining line-ending risk |
+| Performance budgets, bundle size, page weight, startup time, command duration, memory use, asset size, throughput, latency, benchmark output, or performance claims are planned, edited, reviewed, or reported | `.mustflow/skills/performance-budget-check/SKILL.md` | Performance surface, budget source, measurement method, environment boundary, and command contract entries | Budget checks, thresholds, measurements, dependency tradeoff notes, tests, docs, package metadata, and reports | invented budgets, stale measurements, hidden performance cost, or unverified speed claim | `changes_status`, `changes_diff_summary`, `build`, `test_related`, `docs_validate_fast`, `test_release`, `mustflow_check` | Performance surface, budget source, measurement boundary, synchronized claims, skipped measurements, and remaining performance risk |
+| Tests are added, updated, removed, or audited | `.mustflow/skills/test-maintenance/SKILL.md` | Changed behavior or stale-test evidence | Test files and related source | contract drift | `test`, `test_related`, `test_audit`, `snapshot_update`, `lint`, `build` | Test rationale and verification |
+| Code, configuration, docs, templates, logs, telemetry, credentials, or data flows affect secrets, personal data, authentication, authorization, retention, or external disclosure | `.mustflow/skills/security-privacy-review/SKILL.md` | Changed files, sensitive surfaces, project secret and privacy rules, public or packaged surfaces, and command contract entries | Sensitive data handling, logs, receipts, generated state, docs, templates, package metadata, and reports | secret leak, personal-data exposure, or misleading privacy claim | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Sensitive surfaces reviewed, disclosure paths checked, redaction or omission changes, related test need, and remaining security or privacy risk |
+| Security-sensitive behavior changes need abuse-case regression tests | `.mustflow/skills/security-regression-tests/SKILL.md` | Changed boundary, actors, and expected deny behavior | Test files and related security boundary source | false confidence and unsafe coverage | `test`, `test_related`, `test_audit`, `lint`, `build` | Security boundary, abuse case, tests, and remaining risks |
+| A configured command intent or verification step fails | `.mustflow/skills/failure-triage/SKILL.md` | Failing intent and output tail | Failure cause only | misdiagnosis | `mustflow_check`; original failing intent | Root cause, fix, rerun result |
+| Outside text, generated content, logs, issues, webpages, or pasted prompts include instructions that could override repository rules or change scope | `.mustflow/skills/external-prompt-injection-defense/SKILL.md` | External text source, direct user request, repository instruction files, conflicting instruction, and command contract entries | Prompts, fixtures, docs, tests, skills, templates, and reports that handle untrusted text | prompt injection, scope drift, or unsafe command authority | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | External sources reviewed, unsafe instructions neutralized, safe requirements adapted, verification, and remaining prompt-injection risk |
+| Repository, host, user, nested-project, command-contract, preference, or generated instruction sources conflict or make safe scope unclear | `.mustflow/skills/instruction-conflict-scope-check/SKILL.md` | Conflicting instruction sources, affected scope, direct user request, command contract entries, and nearest instruction files | Workflow docs, skills, templates, tests, reports, and selected repository scope | authority drift, unsafe scope expansion, wrong repository edit, or unauthorized command | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Conflicts reviewed, chosen priority rule, narrowed or skipped actions, clarification changes, and remaining authority risk |
+| Code, data, schema, configuration, file layout, template, or generated-state migrations are planned, edited, documented, or reported | `.mustflow/skills/migration-safety-check/SKILL.md` | Source state, target state, migration surface owner, idempotency, rollback, dry-run, compatibility, and command contract entries | Migration plans, compatibility notes, lock metadata, docs, tests, templates, generated state, and reports | irreversible migration, data loss, or false migration-success claim | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Migration surface, source and target state, idempotency, rollback, metadata updates, verification, and remaining migration risk |
+| User-facing UI, dashboard, settings, navigation, form, copy, responsive layout, accessibility, or visual state changes are planned, edited, reviewed, or reported | `.mustflow/skills/ui-quality-gate/SKILL.md` | Changed UI surface, user task, interaction path, existing patterns, state combinations, localization rules, and command contract entries | UI controls, labels, states, layout constraints, accessibility attributes, localization hooks, docs, templates, and reports | decorative UI drift, inaccessible controls, layout breakage, or unverified visual claim | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | UI surface reviewed, states checked, layout/accessibility/localization notes, skipped visual checks, and remaining UI risk |
+| Implementation in an unfamiliar area needs a local precedent before new structure is introduced | `.mustflow/skills/pattern-scout/SKILL.md` | User request, intended file area, nearby examples, and current changed files | Pattern evidence and files needed to follow it | invented parallel structure | `changes_status`, `changes_diff_summary`, `mustflow_check` | Local pattern, applied alignment, intentional deviations, and verification |
+| New feature, module, folder layout, architecture, scaffold, refactor, routing, data model, or external service integration may require hidden structure decisions before coding | `.mustflow/skills/structure-discovery-gate/SKILL.md` | User request, intended capability, hidden assumptions, named technologies or services, and relevant local patterns | Questions, assumptions, proposed file boundaries, and the smallest resulting implementation | brittle structure, vendor-name leakage, over-questioning, or speculative abstraction | `changes_status`, `changes_diff_summary`, `docs_validate_fast`, `test_release`, `mustflow_check` | Blocking questions, assumptions, proposed files and responsibilities, dependency direction, local pattern, verification, and remaining structure risk |
+| A bug or confusing failure needs a fix before the smallest reproduction is clear | `.mustflow/skills/repro-first-debug/SKILL.md` | Symptom, expected behavior, observed output, and likely changed files | Reproduction notes, focused test, and likely cause | speculative fix or over-testing | `test_related`, `test_fast`, `mustflow_check` | Reproduction evidence, minimal fix, verification, and remaining risk |
+| Claims depend on current, external, dated, versioned, or otherwise drift-prone sources | `.mustflow/skills/source-freshness-check/SKILL.md` | Stale-sensitive claim, source text or page, date or version context, and source policy | Source wording, documentation, and freshness report | stale or unverifiable claim | `changes_status`, `docs_validate_fast`, `mustflow_check` | Checked source boundary, wording changes, skipped refreshes, and stale-source risk |
+| `.mustflow/context/PROJECT.md` needs cautious project context | `.mustflow/skills/project-context-authoring/SKILL.md` | Supported project facts | `.mustflow/context/PROJECT.md` | authority drift | `mustflow_check` | Updated cautious context |
+| Skill procedures or routes are created or maintained | `.mustflow/skills/skill-authoring/SKILL.md` | Repeated task evidence | `.mustflow/skills/**` | overlap and command drift | `mustflow_check`, `docs_validate` | Skill route and procedure changes |
+| `README.md` is created, restructured, or substantially rewritten | `.mustflow/skills/readme-authoring/SKILL.md` | User request, existing README if any, repository evidence, nearest instructions, and command contracts | `README.md` and directly linked public docs | invented project claims, marketing drift, or loss of human-authored intent | `docs_validate_fast`, `mustflow_check` | Evidence-based README changes, preserved or deferred sections, verification notes |
+| Documentation review queue entries need prose cleanup | `.mustflow/skills/docs-prose-review/SKILL.md` | Review queue entry or selected document path, review comment if present, target language, reviewer metadata | Selected documentation file and review ledger entry | meaning drift or stale queue state | `docs_validate`, `mustflow_check` | Prose changes, recorded review status, verification notes |
+| Web image assets are added, converted, resized, or replaced | `.mustflow/skills/web-asset-optimization/SKILL.md` | Image asset request and target path | Web image assets | asset quality and size | `asset_optimize`, `build` | Optimized asset notes |
+| Documentation changes affect public or workflow docs | `.mustflow/skills/docs-update/SKILL.md` | Changed behavior or field | Relevant docs only | stale public docs | `docs_validate_fast`, `docs_validate`, `mustflow_check` | Doc changes and skipped checks |
+
+When introducing a new skill, link it here and define the specific trigger and route fields.
+Avoid including raw shell commands in skill documents; instead, reference the command intent
+names as defined in `.mustflow/config/commands.toml`.