pulumi-neo-handoff

Par pulumi · agent-skills

Transférez le thread actuel vers une nouvelle tâche Pulumi Neo en tant que transfert à sens unique. À utiliser lorsque l'utilisateur demande explicitement de transférer, envoyer, déléguer ou continuer le travail en cours dans Pulumi Neo (ex. : « donne ça à Neo », « continuer dans Neo », `/neo-handoff`). Ne pas charger si l'utilisateur mentionne simplement Neo, demande ce que Neo peut faire, demande une PR rédigée par une IA ou une explication de preview, ou transfère vers un agent différent.

npx skills add https://github.com/pulumi/agent-skills --skill pulumi-neo-handoff

Pulumi Neo Handoff

Transférer le travail en cours vers une nouvelle tâche Pulumi Neo. Il s'agit d'un handoff unidirectionnel : le contrôle passe à Neo et ne revient pas à l'agent appelant.

Comportement de l'agent appelant

Quand cette skill s'active, agis comme coordinateur du handoff, pas comme opérateur :

  • Ne décris pas le handoff tour à tour. L'utilisateur a décidé ; exécute-le discrètement.
  • Ne colle pas le corps du prompt assemblé dans le chat. Affiche uniquement le chemin du fichier temporaire pour que l'utilisateur puisse l'inspecter à la demande.
  • Ne continue pas à travailler sur la tâche après le lancement. Quitte proprement une fois que l'URL de la tâche est retournée.

Ce qui est transféré

La tâche Neo reçoit un seul prompt d'ouverture avec trois sections :

  1. Goal — une phrase décrivant ce que Neo devrait faire ensuite.
  2. Repository pointers — racine du repo, branche, répertoire de travail, état du working tree, et 3 à 5 fichiers les plus pertinents pour le travail en cours.
  3. Conversation summary — un compte rendu compact de ce qui a été discuté, décidé et laissé ouvert.

N'inclus pas de diffs, de contenu de fichier complet, ou de sortie d'outil. Neo voit le working tree local directement (y compris les changements non commités) ; dupliquer ce contenu gaspille le contexte d'ouverture de Neo.

Workflow

0. Preflight

Vérifie que la CLI est disponible avant de rédiger quoi que ce soit :

command -v pulumi >/dev/null || { echo "pulumi CLI not installed"; exit 1; }
pulumi neo --help >/dev/null 2>&1 || { echo "pulumi neo unavailable — run 'pulumi login' or upgrade the CLI"; exit 1; }

Si le preflight échoue, surface l'erreur à l'utilisateur et arrête-toi. Ne n'assemble pas le prompt juste pour échouer au lancement.

1. Détermine l'objectif

L'objectif est une phrase décrivant ce que Neo devrait faire ensuite. Si le message de handoff de l'utilisateur le contient (« hand this off to Neo and apply the staging migration »), utilise-le directement. Sinon, pose la question une seule fois : « What would you like Neo to do next? »

Ne restate pas l'objectif pour confirmation — le handoff devrait sembler transparent, et si Neo reçoit un objectif mal lu, l'utilisateur peut rediriger à l'intérieur de la tâche Neo.

2. Rassemble le contexte du repository

Capture le pointeur canonique du repo et l'état de la branche :

git rev-parse --show-toplevel    # repo root (canonical pointer)
git rev-parse --abbrev-ref HEAD  # branch; returns "HEAD" if detached
git status --short               # working-tree summary

Si git rev-parse --show-toplevel échoue, le répertoire n'est pas un repo git — omets la section Repository et note uniquement le répertoire de travail. Neo peut toujours opérer, mais son contexte de repo sera limité.

Si la branche lit HEAD, enregistre le SHA du commit et étiquette l'entrée « detached at <sha> ».

Identifie 3 à 5 fichiers les plus pertinents pour le travail en cours à partir de la conversation (fichiers lus, modifiés, ou régulièrement discutés). Si la conversation n'identifie clairement pas de fichiers, n'en liste aucun plutôt que de deviner — les mauvais fichiers trompent Neo plus que les fichiers manquants.

3. Rédige le résumé de la conversation

Écris un résumé compact selon la structure ci-dessous. Les sections sans contenu utile doivent être omises, pas rembourrées.

## What's been done
<bullets: decisions made, code changed, dead ends ruled out>

## Open questions
<bullets: things the user has not resolved>

## Next step
<one or two sentences describing what Neo should do first>

Cible ~400 mots pour le résumé. Compresse agressivement. L'objectif est de donner à Neo assez pour continuer proprement, pas de rejouer la conversation.

4. Assemble le prompt et écris-le dans un fichier temporaire

Combine les trois sections en un seul document markdown. Utilise mktemp pour un chemin temporaire portable :

PROMPT_FILE="$(mktemp -t neo-handoff.XXXXXX.md)"

Forme :

# Goal
<one-sentence goal>

# Repository
- Root: <repo root>
- Branch: <branch or "detached at <sha>">
- Working directory: <cwd>
- Working tree: <clean | dirty>
- Files in play:
  - <file 1>
  - <file 2>

# Conversation summary
<summary from step 3>

5. Lance

Affiche le chemin du fichier temporaire avec un résumé de taille sur une ligne pour que l'utilisateur puisse inspecter à la demande :

Prompt written to <PROMPT_FILE> (<line count> lines, <byte count> bytes).
Launching Neo task...

Invoque la CLI :

pulumi neo "$(cat "$PROMPT_FILE")"

pulumi neo accepte le prompt comme un seul argument positionnel ; il n'a pas de drapeau --file, et la redirection stdin lance la TUI au lieu de consommer le prompt. La forme "$(cat ...)" capture les octets du fichier comme données (le shell ne réivalue pas $, les backticks, ou \ à l'intérieur de la substitution de commande) et les passe comme un seul argument. Ne « corriges » pas ceci en pulumi neo --file ... ou pulumi neo < ... — les deux formes sont cassées contre la CLI actuelle.

Si la CLI quitte avec un code non zéro, surface son stderr verbatim et laisse le fichier de prompt en place pour que l'utilisateur puisse réessayer. Ne prétends pas que le handoff a réussi.

6. Surface l'URL de la tâche

La CLI affiche une URL de tâche en cas de succès. L'affiche verbatim. Puis arrête-toi.

Ce qu'il ne faut pas faire

  • N'invoque pas cette skill sans intention de handoff explicite. Détecter du travail en forme d'infrastructure n'est pas un déclencheur ; les questions de capacité comme « can Neo do X » ne sont pas des handoffs. Activer sur celles-ci rendrait la skill bruyante et incorrecte.
  • N'inclus pas de diffs, contenu de fichier, ou sortie de commande dans le prompt. Neo voit le working tree local directement, donc dupliquer ce contenu gaspille son contexte d'ouverture.
  • Ne colle pas le prompt assemblé dans le chat pour confirmation. Les résumés peuvent être longs ; le chemin du fichier est suffisant pour que l'utilisateur inspecte quand il le souhaite.
  • Ne commite, ne pousse, ou ne modifie pas le working tree au nom de l'utilisateur. L'utilisateur possède son état git — la skill est un handoff de contexte, pas un contrôleur de workflow.

Notes

  • Handoff unidirectionnel. Le contrôle passe à la tâche Neo et ne revient pas à l'agent appelant.
  • Les tâches Neo sont interruptibles. Si le résumé s'avère incorrect, l'utilisateur peut rediriger à l'intérieur de la tâche Neo ; la skill n'a pas besoin de garder contre les erreurs de résumé au moment du lancement.
  • Afficher l'URL de la tâche est le critère de succès de la skill, pas l'achèvement réussi du travail sous-jacent. Neo peut décliner ou rediriger la demande à l'intérieur de la tâche.

Skills similaires