09.03.04 — Skills Comprehend#

Skills qui aident l’IA à comprendre un projet ou un écosystème avant d’agir.

Listing (potentiellement non exhaustif)#

understand-ocarina#

input  : question de l'utilisateur — aiguillée selon sa classe :
            - "comment fait-on un match_page ?"   (référence : ce qu'est une primitive) → Holy Book
            - "pourquoi la suite est-elle bâtie sur Railway ?" (intention / cartographie / pourquoi) → le livre from-ocarina-to-igor
output : Claude charge, selon la classe de question :
            - référence    → les pages Holy Book pertinentes (https://mojo-molotov.github.io/ocarina-holy-book)
            - intention    → les chapitres pertinents du livre from-ocarina-to-igor (https://mojo-molotov.github.io/from-ocarina-to-igor/)
            - comportement → la source d'Ocarina (clone), si la doc ne le couvre pas
            - forme        → l'exemple correspondant à l'adaptateur du projet :
                              Selenium   → ocarina-example, ocarina-with-ai-example
                              Playwright → ocarina-with-playwright-example
         puis répond avec citations (tier + URL de page/chapitre ou file:line)

SKILL.md :

Tier 1 — Ocarina Holy Book (reference, public). What a primitive is — signature, contract, lifecycle. Reach via WebFetch for specific pages once the page-list is known.

Tier 1B — the from-ocarina-to-igor book (intent / cartography / philosophy, public). Why Ocarina is shaped this way and how the ecosystem repos relate. The two doc sites are routed by question class, not a fixed order; a question with both halves consults both.

Tier 2 — doc-site repos (cloned + built locally, per-site fallback). If a site is down (DNS / not-yet-published / offline / 404), clone + build that site locally. The fallback is per-site: a 404 on the Holy Book doesn’t mean the book is down too.

Tier 3 — Ocarina source clone. For behaviour the docs don’t cover.

Tier 4 — worked-example clones, matched to the driver adapter. Selenium: ocarina-example, ocarina-with-ai-example. Playwright: ocarina-with-playwright-example.

assess-test-base#

input  : le repo de tests actuel
output : catalogue :
            - liste exhaustive des tests (cycle / campaign / suite / test)
            - couverture par feature : mapping test ↔ Exigence ("requirement") SFD
            - tests gap (intentionally failing), tests cross-browser, tests explo
            - tests data-driven
            - tests en skipped

assess-ecosystem#

Skill qui fait de la recherche web avec limite de tokens.

input  : sujet à comprendre (par exemple "comment CURA est-il déployé sur Heroku ?")
output : findings synthétisés, sources citées
contrainte : budget de tokens — pas de recherche infinie

assess-impact#

input  : un changement (modif du SUT / refactor prévu / une cause partagée trouvée par un diagnose-*)
output : analyse de ce que le changement touche en aval :
            - suit le changement à travers le graphe de dépendances
            - classe chaque nœud touché :
                cassé / affirmation périmée / test-gap susceptible de basculer / trou de couverture / franchissement de smoke-gate

L’inverse de la paire diagnose-* : les diagnose-* partent du symptôme et remontent jusqu’à la cause ; assess-impact part du changement et trace ce qu’il touche en aval.

understand-sut-constraints#

input  : SUT (URLs, source si dispo)
output : contraintes qui cassent les tests parallèles :
            - rate-limits (`X requests / minute / IP`)
            - sessions partagées (`one session per user account`)
            - state global (`history accumulates across tests`)
            - dyno endormi (Heroku eco)
            - quota d'API tiers

Pour CURA :

• Heroku eco-dyno endormi → warm-up nécessaire.
• Sessions par user → si on lance 3 workers avec le même login, c’est OK, environnement bouchonné.
• Accumulation dans l’historique → un test qui assert « historique vide » pourrait fail si un autre test vient de réserver, mais c’est OK, environnement bouchonné.

→ L’IA flag ces contraintes pour que l’humain choisisse comment les gérer (saturate, multi-users, isolated runs, etc.).

Discipline transversale#

• Capter de l’information.
• Synthétiser en un rapport lisible.
• Ne pas modifier directement le code.