Xhuk/skillgram

skillgram-report

Contrat d'activation

Utilisez cette compétence lorsque l'une des conditions suivantes est vraie :

• skillgram a affiché ok:false, s'est terminé avec le code 1/2, a planté, ou a dit quelque chose que le disque contredit (registered sans entrée dans la configuration du harnais, un lien qui ne mène nulle part, un montage qui a signalé zéro compétence alors que le manifeste en contient).
• un agent avait besoin d'une capacité et skillgram missing "<query>" a répondu found:false.
• une installation ou un enregistrement n'a pas pris effet dans le harnais après le redémarrage documenté.

Pas pour : « comment exécuter X » (lisez INSTALL.md), ou une idée de fonctionnalité sans lacune observée.

Règles strictes

1. Un bug n'est jamais déposé comme une compétence. N'exécutez jamais propose pour masquer un comportement cassé.
2. Une lacune n'est jamais déposée comme un bug. L'absence d'une capacité dans le hub est une demande.
3. Aucune preuve inventée : chaque code de sortie, chemin et ligne JSON provient d'une commande que vous venez d'exécuter.
4. Rédigez avant de coller : jetons, mots de passe, hôtes privés, noms de clients. Conservez la structure, modifiez les valeurs.
5. Ne « réparez » jamais skillgram en modifiant manuellement la configuration du harnais (config.toml, config.yaml, .claude.json, .cursor/mcp.json) pour compenser. Cela cache le bug.
6. Relisez la configuration avant de déclarer le succès : <harness> mcp get skillgram (ou mcp list) et skillgram status. Un code de sortie n'est pas une preuve.

Portes de décision

Observation	Canal
ok:false, code de sortie non nul, mauvais lien, mensonge dans la sortie, plantage	bug → bug_report.yml
found:false pour une capacité dont vous aviez réellement besoin	demande de compétence → skill_request.yml
L'élément manquant est une commande, un indicateur ou un comportement de skillgram, pas une compétence	bug (dites « fonctionnalité » dans le titre)
Fonctionne sur une autre machine ou harnais	notez-le comme preuve ; ce n'est pas une correction
Incertain	rassemblez les deux preuves et laissez l'utilisateur choisir le canal

Étapes d'exécution

1. Reproduisez une fois, en conservant la ligne de commande exacte. Utilisez la CLI (skillgram <command> --json, ou python <repo>/skillgram.py <command> --json quand elle n'est pas installée) et enregistrez le code de sortie ($LASTEXITCODE sur PowerShell, $? sur POSIX).
2. Capturez l'environnement :
   • skillgram status --json
   • skillgram doctor --json (lecture seule ; supprimez les chemins que vous ne souhaitez pas rendre publics)
   • OS, version Python, version skillgram, le harnais, et le lanceur que vous avez utilisé (SKILLGRAM_MCP_CLI_<HARNESS> quand celui dans PATH n'est pas le bon).
3. Pour toute affirmation d'enregistrement, capturez <harness> mcp get skillgram (ou mcp list) après la commande qui a prétendu avoir réussi.
4. Pour une lacune, capturez skillgram missing "<query>" --json et skillgram demand --limit 20 (il classe les requêtes auxquelles personne n'a pu répondre, afin que le ticket et le journal de demande correspondent).
5. Composez le ticket à partir du modèle et montrez-le à l'utilisateur avant de le publier. Publiez avec gh issue create --repo Xhuk/skillgram --template bug_report.yml (ou --body-file <file> si vous remplissez le formulaire vous-même), ou remettez le texte à l'utilisateur.

Contrat de sortie

Répondez exactement avec :

• canal : bug ou skill-request
• preuves : la commande, le code de sortie, une ligne JSON
• environnement : OS / Python / skillgram / harnais / lanceur
• attendu à la place : une phrase, sans spéculation
• disposition : publié (avec l'URL du ticket) ou laissé en texte pour l'utilisateur