Revue de zcode-smart-skill : un protocole de manager écrit dans un seul fichier Markdown

REVUE APPROFONDIE · CODE SOURCE

Quatre fichiers, aucun runtime. C’est tout le dépôt, et c’est le but. L’artefact principal est un gros `SKILL.md` qui transforme un agent de code capable en gestionnaire de contextes de travail neufs. L’état circule dans un registre `.smart//` : tâche, plan, notes, tâches, tests, solution candidate, points de contrôle et journal de vérification. Rien ici ne s’importe comme une bibliothèque. C’est un protocole qu’on suit, et la revue demande si un protocole écrit en prose peut être audité comme du code.

Comment c’est assemblé

L’agent principal planifie et vérifie. Les subagents font idéation, tests ou une tâche. Le système de fichiers est le bus. `task.md` garde l’objectif, `plan.md` la stratégie, `tasks.json` borne, `notes.md` transmet, `tests_spec.md` précède le code et `verify.log` garde les exécutions. Les tâches dures peuvent faire courir des worktrees isolés.

Dix extensions, une seule boucle

V2 ajoute tests adversariaux, réflexion, course parallèle, scrutiny, budgets, modèles par rôle, backtracking, self-attack, mémoire de workflow et handoff strict. Chaque ajout change un fichier ou une décision concrète.

Ce que la revue de code peut et ne peut pas vérifier ici

Il existe peu de code exécutable. On peut inspecter le protocole et la licence. On ne peut pas vérifier les gains de benchmark de ce skill : aucun harness, corpus, résultat ou CI. Les recherches motivent les composants, pas la combinaison.

{"id":"implement-1","difficulty":"hard","status":"in_progress","done_when":"artifact exists and tests pass"}

Fragment de registre explicatif original, pas un fichier littéral du projet.

Sécurité et confiance

Le brief dit que le ledger est une donnée, pas une autorité. Les checkpoints ne sont pas destructifs et les limites sont explicites. Mais la tâche est copiée telle quelle et la défense dépend de l’obéissance de l’agent. Il faut sandbox, permissions, validation des chemins et isolation hors prompt.

Le design comme expérience développeur

Le diagramme ASCII explique manager, workers et ledger. Le README montre la boucle avant installation et deux chemins simples. L’audit trail rend visibles échecs et exécutions. Le changement de coût est annoncé.

Où il est faible

Il faut un host avec subagents, fichiers, commandes et parfois choix de modèle. L’adaptation entre permissions n’est pas triviale. Markdown ne garantit ni budgets, ni isolation, ni chemins sûrs, ni merge sériel, ni tests. Le pruning peut effacer des preuves, la course coûte cher et l’auto-trigger peut être trop large.

Comment le tester honnêtement

Créez une suite publique et un budget fixe. Comparez long-context, ledger de base et ablation de chaque extension. Publiez réussite, temps, tokens, faux done, conflits et réaction à une injection plantée avec tous les ledgers.

Idéal pour: hôtes d’agents qui offrent déjà un bac à sable, des contextes de travail neufs et une exécution de commandes fiable.

Verdict

C’est un bon manuel d’exploitation, pas un framework. Ses meilleures idées sont l’auteur de tests indépendant, l’exécution comme vérité, le handoff borné et l’abandon d’une piste morte. Sa faiblesse est l’enforcement en prose. Utilisez-le avec un sandbox et exigez des résultats reproductibles.

Démo et auteur

Aucune démo live distincte n’est indiquée. L’artefact est le dépôt et son `SKILL.md`.

Reviewed source at commit b847694 · No separate live demo listed