terminal-ops

Terminal Ops

Utilisez ceci lorsque l'utilisateur souhaite une exécution réelle de dépôt : exécuter des commandes, inspecter l'état git, déboguer la CI ou les builds, effectuer une correction ciblée, et rapporter exactement ce qui a changé et ce qui a été vérifié.

Ce skill est intentionnellement plus restrictif que les conseils de codage généraux. C'est un workflow opérateur pour l'exécution terminale basée sur les preuves.

Stack de compétences

Intégrez ces skills ECC natifs dans le workflow lorsque cela est pertinent :

• verification-loop pour les étapes de preuve exactes après les modifications
• tdd-workflow lorsque la correction nécessite une couverture de régression
• security-review lorsque des secrets, une authentification ou des entrées externes sont impliqués
• github-ops lorsque la tâche dépend des exécutions CI, de l'état des PR ou du statut de release
• knowledge-ops lorsque le résultat vérifié doit être capturé dans le contexte durable du projet

Quand l'utiliser

• l'utilisateur dit "corrige", "débogue", "exécute ceci", "vérifie le dépôt" ou "pousse-le"
• la tâche dépend de la sortie d'une commande, de l'état git, des résultats de test ou d'une correction locale vérifiée
• la réponse doit distinguer modifié localement, vérifié localement, commité et poussé

Garde-fous

• inspectez avant d'éditer
• restez en lecture seule si l'utilisateur a demandé uniquement un audit/examen
• privilégiez les scripts et aides locaux du dépôt plutôt que des wrappers ad hoc improvisés
• ne revendiquez pas une correction tant que la commande de preuve n'a pas été relancée
• ne revendiquez pas un push tant que la branche n'a pas réellement bougé en amont

Workflow

1. Résoudre la surface de travail

Établir :

• chemin exact du dépôt
• branche
• état du diff local
• mode demandé :
  • inspecter
  • corriger
  • vérifier
  • pousser

2. Lire d'abord la surface en échec

Avant de modifier quoi que ce soit :

• inspectez l'erreur
• inspectez le fichier ou le test
• inspectez l'état git
• utilisez les logs ou le contexte déjà fournis avant de relire aveuglément

3. Garder la correction ciblée

Résolvez un échec dominant à la fois :

• utilisez d'abord la plus petite commande de preuve utile
• ne passez à un build/test plus large qu'après avoir traité l'échec local
• si une commande échoue avec la même signature, arrêtez les tentatives larges et réduisez le périmètre

4. Rapporter l'état exact d'exécution

Utilisez des mots d'état exacts :

• inspecté
• modifié localement
• vérifié localement
• commité
• poussé
• bloqué

Format de sortie

SURFACE
- dépôt
- branche
- mode demandé

PREUVE
- commande / diff / test en échec

ACTION
- ce qui a changé

STATUT
- inspecté / modifié localement / vérifié localement / commité / poussé / bloqué

Pièges

• ne travaillez pas à partir d'une mémoire obsolète lorsque l'état du dépôt en direct peut être lu
• n'élargissez pas une correction ciblée en remaniement à l'échelle du dépôt
• n'utilisez pas de commandes git destructrices
• n'ignorez pas le travail local sans rapport

Vérification

• la réponse nomme la commande de preuve ou le test
• le travail lié à git nomme le chemin du dépôt et la branche
• toute revendication de push inclut la branche cible et le résultat exact