Livraison d'ingénierie
À utiliser pour cadrer, coordonner ou réaliser une initiative d'ingénierie. Il prend en charge un changement complet sur plusieurs dépôts, et non un gestionnaire par dépôt ou couche. Un petit travail peut rester dans une seule conversation ; une implémentation ou révision indépendante obtient un sous-élément natif délimité si utile.
Connaître l'intention avant de déléguer
Gardez visibles les résultats attendus, les critères d'acceptation, les contraintes et les changements de priorité de l'utilisateur. Lisez le contrat d'équipe une fois par contexte de travail et les legons de feedback du mainteneur pertinentes. Lisez sélectivement par ID de leçon/cas ; relisez lorsque le contexte manque ou que les directives changent. Le chef et le gestionnaire consultent frdel et ses questions de planification avant de choisir une approche ; les travailleurs reçoivent les critères pertinents et les références sources. Il s'agit d'un support de décision, pas d'un droit de veto pour un style historique.
Pour chaque dépôt concerné, découvrez sa racine, sa branche/diff actuelle, la chaîne AGENTS.md applicable et la DOX profonde. Dans Agent Zero, les fichiers *.py.dox.md adjacents décrivent le comportement des aides/outils. Suivez les index réels et les contrats référencés dans chaque dépôt ; ne supposez pas que tous les dépôts utilisent le même format de fichier. Lisez les appelants, les hooks d'extension, la configuration, les tests et les chemins d'installation avant de décider ce qui peut bouger. La DOX actuelle fait autorité ; ne gelez pas ses règles détaillées dans ce skill.
Enregistrez le choix et son coût : propriétaire/primitive existant réutilisé, alternative rejetée et pourquoi, comportement protégé, incertitudes et la vérification qui peut infirmer l'hypothèse. Une nouvelle structure nécessite une obligation concrète ; la simplicité n'excuse jamais le comportement demandé omis ou la compatibilité cassée.
Limites d'exécution
Ce flux de travail s'exécute via les outils, contextes et jobs natifs d'Agent Zero. Les skills et profils sont des fichiers installés ordinaires sous /a0/usr/. Un connecteur peut fournir un accès autorisé au dépôt hôte ; un rôle en lui-même n'accorde aucune capacité. Découvrez le checkout accessible réel et le mode lecture/écriture avant d'attribuer du travail à l'hôte. Un sondage d'hôte bloqué ne bloque pas le travail indépendant du serveur.
Suivez les règles de message de commit, de branche de staging et de sélection de cible du contrat d'équipe partagé. Utilisez une cible de développement/test explicitement configurée ; sinon, utilisez par défaut l'instance d'hébergement actuelle. Une configuration manquante permet un travail sur la même instance avec une autorisation normale. Signalez une cible explicite invalide ou inaccessible sans retomber silencieusement sur une autre. Enregistrez l'instance d'hébergement, la cible sélectionnée, le checkout/liens réels, la branche et le périmètre d'écriture. Tenez compte de l'interruption des travailleurs actifs lorsqu'un rechargement/redémarrage est nécessaire, en utilisant la coordination existante du cycle de vie/point de contrôle. Un fixture d'aide appartenant à une tâche prouve uniquement son comportement délimité ; aucun service de flotte n'est requis.
Rôles et passations
| ID du profil | Responsabilité |
|---|---|
chief-of-staff | Intention utilisateur, priorité et résultats pour des initiatives indépendantes. |
delivery-manager | Un changement complet, y compris l'intégration inter-dépôts. |
engineering-worker | Implémentation ou investigation délimitée avec une propriété d'écriture nommée. |
engineering-reviewer | Exactitude indépendante, contrats et décisions de développement. |
design-reviewer | Flux de travail indépendant, langage, composants, accessibilité et état véridique. |
engineering-verifier | Preuve de comportement indépendante dans l'artefact/exécution prévu. |
Les relecteurs et le vérificateur rendent compte au gestionnaire de livraison ; ils ne modifient pas silencieusement leurs conclusions. Le gestionnaire arbitre, retourne les conclusions acceptées au travailleur responsable et demande une revérification ciblée. Le chef reçoit les résultats intégrés des gestionnaires. N'ajoutez pas de gestionnaires intermédiaires par défaut et ne créez pas une cérémonie fixe à six agents pour de minuscules modifications.
Lisez délégation native pour l'API de continuation et parallèle réelle et un enregistrement de tâche minimal. Donnez aux travailleurs indépendants des périmètres d'écriture disjoints. Les contrats partagés, les modifications dépendantes, les changements de paramètres et l'intégration sont séquencés. Conservez les ID de contexte natif existants et les handles de job ; ne construisez pas de file d'attente, de registre, de démon ou de service d'orchestration.
Terminer le changement complet
- Établissez un défaut reproductible ou un comportement cible observable. Testez les hypothèses incertaines avant une modification étendue.
- Implémentez dans les limites de propriété, en couvrant les appelants, la configuration, les migrations, les tests et la DOX affectés par le changement. Lors de la suppression/révocation de quelque chose, tracez également ses consommateurs indirects et ses données persistées.
- Demandez une revue indépendante proportionnée à la conséquence. Utilisez
engineering-reviewpour l'exactitude/conception/vérification, et les skillsa0-development, plugin authoring eta0-e2e-testingexistants pour leurs procédures natives. - Vérifiez l'exécution/artefact exact modifié et le flux utilisateur réel. Distinguez les contrôles automatisés, l'observation UI et le comportement piloté par modèle ; aucun ne remplace silencieusement l'autre. Préservez les données utilisateur et restaurez les paramètres temporaires appartenant à la tâche.
- Terminez avec le résultat, les décisions significatives, les preuves, le travail restant et les risques. Un appel de modèle bloqué est bloqué, pas une réussite. Continuez le travail autorisé de manière autonome ; l'approbation n'est nécessaire que pour une réelle frontière de permission, pas pour des étapes réversibles de routine.
Aucune permission d'installer, commiter, pousser, publier, envoyer des messages externes ou modifier l'accès n'est implicite par un rôle. Lisez les permissions de chaque dépôt et l'autorisation existante de l'utilisateur. N'exposez pas de secrets ou d'historique de chat brut dans les enregistrements de tâches ou la DOX suivie.
Utiliser l'équipe
Choisissez le Chief of Staff pour plusieurs initiatives, ou le Delivery Manager pour un résultat. Un gestionnaire peut démarrer plusieurs conversations de travailleur/relecteur indépendants en utilisant les mêmes profils réutilisables. La sélection d'un profil dans une nouvelle conversation ou un sous-élément engendre son rôle ; les conversations/paramètres existants non liés ne sont pas migrés. Les préréglages d'enfant non par défaut l'emportent sur une substitution de conversation parent ; seuls les enfants par défaut peuvent l'hériter. Enregistrez le préréglage/fournisseur/modèle effectif pour les enfants importants sans modifier les valeurs par défaut de l'utilisateur. Aucun modèle/fournisseur n'est prescrit ici.