Alfredv2/alfred/app/skills/alfred-developer/SKILL.md

name, description, version

name	description	version
alfred-developer	Pour les demandes de modification de l'interface, du code Python, HTML, CSS, JavaScript, de l'ergonomie ou de fonctionnalités de Dona/Alfred ; préparer et tester dans une copie, puis soumettre une proposition à valider sur /maintenance.	1.0.0

Alfred Developer — modifications du propre programme de l'assistant

Lorsque l'utilisateur demande à Dona/Alfred de modifier son programme, exploiter exclusivement le MCP alfred_developer pour préparer les modifications. Le projet de production se trouve sous /opt/alfred/app et ne doit jamais être modifié directement.

Méthode obligatoire

1. Appeler create_task avec une description exacte de la demande, puis noter l'ID.
2. Examiner les fichiers utiles avec list_source puis read_source ; ne pas supposer leur organisation.
3. Préparer des modifications minimales avec modify_source : copier le contenu intégral du fichier voulu, modifier uniquement le nécessaire et préserver le reste.
4. Appeler run_checks, résoudre les erreurs de syntaxe et relancer les contrôles.
5. Appeler preview_changes pour examiner les différences ; éviter les régressions.
6. Si les contrôles passent, appeler submit_proposal.
7. Annoncer l'ID et inviter l'utilisateur à examiner la proposition sur /maintenance.

Règles de sécurité et de vérité

• Jamais utiliser Terminal, sed, cp, git, Python direct ou d'autres MCP pour modifier /opt/alfred/app, redémarrer le service ou déployer.
• Les outils MCP de développement ne permettent ni déploiement ni restauration.
• Ne modifier aucun .env, secret, token, mot de passe, base SQLite ou configuration de sécurité.
• La validation humaine et le déploiement CLI sont séparés. Une approbation Web ne déploie pas le code.
• Les contrôles V1 sont des vérifications statiques, pas des tests de fonctionnement en situation réelle : le dire clairement.
• Si des tests complémentaires, une modification de fichier protégé ou l'exécution du code sont nécessaires, demander l'intervention de l'administrateur.
• Ne pas inventer de statut, d'aperçu ni de résultat d'installation.
• Cette version n'est pas un agent de développement en arrière-plan indépendant : la session Hermes conduit le travail, et les propositions restent persistées dans l'espace Git.

Exemple

« Dona, rends la carte météo plus transparente » → create_task, inspecter CSS, modify_source, run_checks, submit_proposal, répondre : « Proposition 12caractères prête à valider sur /maintenance. »