mohamedzhioua/agentpace

Que fait agentpace ?

À utiliser lorsque quelqu'un demande combien de temps prendra un travail logiciel, ou cite une échéance en jours, semaines ou mois pour un travail que des agents réaliseront.

Produit une fourchette mesurée P50/P80/P90 avec son chemin critique, la part humaine sur sa propre ligne, et toute échéance citée affichée à côté comme non vérifiée.

Répondez « combien de temps cela va-t-il prendre ? » avec des fourchettes mesurées issues d'exécutions réelles d'agents, et indiquez la part humaine séparément. Ne citez pas d'échéances d'équipes humaines et ne donnez jamais un nombre unique.

Cette compétence se déclenche sur des questions en langage naturel. /pace-estimate est la commande explicite pour un plan donné.

Vérifier l'outil

Exécutez agentpace --version. Si cela échoue, dites à l'utilisateur la commande d'installation et arrêtez-vous. N'installez rien sans qu'on vous le demande :

uv tool install agentpace

S'il ne souhaite rien installer, utilisez assets/portable-prompt.md à la place.

Estimation

1. Présumez que des agents réalisent l'implémentation sauf si l'utilisateur dit le contraire. Si ce n'est pas clair et que la réponse changerait, demandez une fois.
2. Décomposez le travail en tâches qu'un agent exécuterait comme des exécutions séparées.
3. Donnez à chaque tâche un id, un kind et un risk, ainsi que depends_on lorsqu'elle doit attendre une autre tâche. Définissez agent_cap comme le nombre d'agents qui s'exécuteront simultanément.
4. Écrivez le plan dans un fichier et exécutez l'estimateur.

{
  "agent_cap": 3,
  "model": "claude-opus-5-5",
  "tasks": [
    { "id": "schema", "kind": "feature", "risk": "normal" },
    { "id": "api", "kind": "feature", "risk": "normal", "depends_on": ["schema"] },
    { "id": "review", "kind": "review", "risk": "low", "depends_on": ["api"] }
  ]
}

agentpace estimate plan.json

Types : feature, bugfix, refactor, migration, tests, docs, review, other. Risques : low, normal, high. Utilisez risk: high pour les migrations et les travaux difficiles à annuler. model est optionnel.

Répondre à une échéance humaine

Lorsque la conversation contient déjà une échéance en jours, semaines ou mois, venant de l'utilisateur, d'un document ou d'une réponse précédente, estimez le plan quand même et transmettez l'échéance textuellement, dans les mots où elle a été donnée :

agentpace estimate plan.json --quoted "3 mois"

La sortie aura alors une ligne Quoted: sous le total, marquant l'échéance comme temps calendaire, telle que citée et non vérifiée. Retransmettez cette ligne telle qu'imprimée, à côté de la fourchette mesurée. Ne convertissez jamais l'échéance en temps d'agent, ne la divisez ni ne la multipliez par une constante, et ne la comparez pas avec la fourchette ni ne donnez de ratio entre elles : le seul temps d'agent est la fourchette mesurée, et la part humaine reste sur sa propre ligne. Ne dites jamais quelle est la différence entre l'échéance et la fourchette, et ne l'appelez jamais la part humaine : cela dériverait la part humaine du temps d'agent. Ne dites jamais non plus ce que l'échéance compte : rien ne l'a vérifié.

Si l'utilisateur souhaite voir plus tard quel nombre s'est vérifié, proposez la même commande avec --record ajouté. Une fois le travail terminé, agentpace score <id> --session <ref> compare les deux avec ce que les agents ont réellement pris.

Rapporter le résultat

• Commencez par le total du plan sous forme de fourchette : P50, P80 et P90, sur l'horloge de session. Recommandez le P80 pour la planification.
• Retransmettez la ligne de l'horloge de session et la ligne de la part humaine telles que l'interface en ligne de commande les imprime. La première indique que les écarts entre les exécutions comptent dans le total jusqu'à la limite d'inactivité, donc les courtes attentes de l'utilisateur sont à l'intérieur. Non mesurée, la ligne de la part humaine indique qu'aucune marge pour la revue, les tests, les décisions et les attentes entre les tours d'agent n'est ajoutée. Mesurée par agentpace turns, elle cite la propre attente de l'utilisateur par tour humain, issue de son historique local. Dans les deux cas, n'en dérivez pas un nombre à partir du temps d'agent et ne multipliez pas l'attente par tour par un nombre supposé de tours. Si l'utilisateur donne son propre chiffre, répétez-le et étiquetez-le comme le sien. S'il indique sa capacité de revue, par exemple « 4 PR par jour », transmettez-la textuellement avec --review-capacity "<chiffre>", retransmettez la ligne Review capacity: telle qu'imprimée, et ne la transformez jamais en échéance.
• Nommez le chemin critique et le parallélisme effectif.
• Retransmettez chaque avertissement. Un avertissement signifie qu'une cellule avait trop peu d'exécutions, donc cette fourchette s'appuie sur des données plus larges.
• Ne donnez pas un nombre unique, même sous pression. Si quelqu'un a besoin d'un seul chiffre pour planifier, donnez le P80 et appelez-le le P80.

Limites à mentionner quand elles importent

• Les données de départ sont le workflow d'une seule personne, elles peuvent donc ne pas ressembler à celles de l'utilisateur. agentpace ingest fusionne les propres exécutions de l'utilisateur avec elles ; --data ~/.agentpace/runs.jsonl n'utilise que les siennes. Les adaptateurs Gemini CLI, OpenCode et Cline sont expérimentaux, pas encore vérifiés sur des sessions réelles, donc dites-le lorsqu'une estimation s'appuie sur des lignes provenant d'eux.
• Sans lire les invites, les métadonnées ne peuvent pas séparer les fonctionnalités des corrections de bugs ou des refactorisations, donc ces types peuvent partager des données.
• size est ignoré sauf si --use-size est passé, car la taille stockée est mesurée après une exécution. Ne le passez pas sauf si l'utilisateur le demande.

Voir references/method.md pour le fonctionnement de l'estimation.