Open Source

aSPARK transforme Claude Code en un outil doté d'un processus: une équipe produit composée d'un Product Owner, d'un Designer, d'un Engineering Manager, d'un Reviewer, d'un testeur QA et d'un Release Manager. Chaque fonctionnalité traverse la boucle SPARK et doit franchir chaque gate avant de poursuivre.

Les décisions ne disparaissent pas dans l'historique de conversation: elles deviennent des artefacts du projet — spec.md, plan.md, review.md, qa.md. Des identifiants stables pour les user stories, les critères d'acceptation et les exigences non fonctionnelles assurent la traçabilité entre les phases. La QA n'est pas déclarée, elle est exécutée dans un vrai navigateur.

1. S Specify Préciser l'idée, définir user stories et critères d'acceptation
2. P Plan Décider l'architecture, découper les tâches
3. A Act Construire l'incrément en suivant strictement le plan
4. R Review Revue de code et QA dans un vrai navigateur
5. K Keep Livrer, documenter et consigner les enseignements

/plugin marketplace add a-lottes/aSPARK
/plugin install aspark@aspark

aspark-graph lit un dépôt — son code source et sa piste de livraison aSPARK sous .spark/ avec specs, plans, revues et rapports QA — et en construit un graphe unique interrogeable, exposé via une CLI et un serveur MCP. Il répond à deux questions sans grep: quel code implémente cette user story, et quelles stories se trouvent dans le rayon d'impact d'une modification?

Le graphe est déterministe — tree-sitter et liens d'artefacts déclarés, sans LLM ni réseau: deux builds d'un dépôt inchangé produisent des résultats identiques au byte près. Et il est volontairement jetable: un read model reconstructible à tout moment, jamais une source de vérité.

pip install aspark-graph
claude mcp add aspark-graph -- uvx aspark-graph serve

aSPARK-policy transforme les guides d'architecture, les standards de codage sécurisé, les conventions de nommage et les checklists de revue en une couche de politique lisible par machine. Des fichiers Markdown expliquent les standards, un fichier policy.yaml les active, et chaque agent aSPARK consomme la même politique — sans prompts dupliqués ni agents modifiés.

Une politique ne s'installe pas, elle se monte: l'organisation conserve ses standards dans son propre dépôt, et chaque projet l'intègre en sous-module Git sous .spark/policy. État actuel: un format documenté, un JSON Schema testé, un paquet Python installable et huit packs de catalogue. L'application via CLI et l'intégration du Facilitator restent à venir — le projet est en début de développement.

La plupart des starters Eleventy réduisent le multilingue à une table de correspondance pour les libellés de boutons — c'est la partie facile. Le difficile, c'est ce qui se passe quand un lecteur change de langue sur une page quelconque: une page de tag, la page 4 du blog, la politique de confidentialité. eleventy-rosetta y répond partout, avec des routes traduites (/de/impressum/, /en/legal/ et /fr/mentions-legales/ sont la même page), des tags traduits et un sélecteur de langue qui se désactive plutôt que de mener à un 404.

Allemand, anglais et français d'origine, du CSS maison sans framework et aucun service externe à l'exécution: la recherche plein texte via Pagefind est générée au déploiement, les images responsives en AVIF et WebP au build. Le paquet a deux moitiés — le plugin reste actualisable via npm, tandis que eleventy-rosetta init copie une fois pour toutes layouts, CSS, contenus de démonstration et configuration dans le projet, puis s'efface. Ajouter une langue, c'est ajouter un répertoire sous _data/i18n/, pas modifier un registre. Le thème est né du code de ce site.

npx eleventy-rosetta init
npm install && npm start