oh-my-gh-writing

Que fait oh-my-gh-writing ?

Compétence d'écriture GitHub pour agents IA. Acheminez la demande, chargez la norme correspondante, maintenez des limites de preuves explicites, et produisez des brouillons GitHub quasi prêts à soumettre.

Limite de déclenchement

Utilisez cette compétence pour les artefacts d'écriture destinés à GitHub et les packs de brouillons d'écriture GitHub locaux. Ne l'utilisez pas pour la rédaction générale, le texte d'interface utilisateur, l'implémentation de code, la stratégie produit, ou le travail de documentation large, sauf si la sortie demandée est un artefact GitHub ou un fichier de dépôt GitHub.

Flux de travail

1. Identifiez si l'utilisateur souhaite un artefact unique ou un pack de flux de travail multi-artefacts.
2. Si l'utilisateur nomme explicitement un artefact unique, acheminez vers cet artefact même si le sujet est large.
3. Si l'utilisateur demande un flux de travail large, un lancement, une configuration, un package de version, ou un ensemble de documents de bout en bout, acheminez vers le pack de flux de travail composite correspondant.
4. Si l'utilisateur demande d'inspecter, vérifier, examiner la préparation, ou recommander les fichiers nécessaires, traitez-le comme un audit uniquement : produisez une analyse des écarts et des recommandations pour les fichiers suivants. Ne créez pas de fichiers cibles, ne créez pas de dossier .github-writing/, et n'écrivez pas de fichiers .github/ ou de fichiers racine du dépôt, sauf si l'utilisateur demande explicitement de rédiger, créer, écrire, appliquer ou mettre à jour des fichiers.
5. Pour les demandes de README, utilisez l'invite en trois questions dans references/readme.md.
6. Pour les packs de flux de travail composites, suivez la règle de décision du pack. Ne posez la question de sélection du package que lorsque la forme du package ne peut pas être déduite en toute sécurité ; sinon, utilisez le défaut recommandé et enregistrez-le dans package-manifest.md.
7. Ouvrez et lisez explicitement le references/*.md correspondant avant d'écrire la sortie destinée à l'utilisateur. Ne déduisez pas et ne devinez pas le contenu des références de mémoire.
8. Ne lisez que les références d'artefacts uniques sélectionnées par un pack composite. Ne préchargez pas toutes les références.
9. Lisez references/weapons.md lorsque des badges, alertes, Mermaid, blocs repliables, émojis ou tableaux complexes sont nécessaires.
10. Lisez references/badge-catalog.md uniquement lorsque l'utilisateur demande une conception détaillée de badge ou des modèles d'URL shields.io exacts.
11. Lisez references/emoji-guide.md lorsque des émojis sont demandés ou que le dépôt cible utilise déjà des émojis.
12. Lisez references/shared-principles.md lorsque la demande est très factuelle, à haut risque, multi-scénarios, ou lorsque les règles de qualité de sortie nécessitent des éclaircissements.
13. Avant de finaliser, utilisez references/output-validation.md comme liste de contrôle de révision silencieuse. Si le brouillon échoue à un contrôle, révisez-le avant de le livrer. Gardez la validation silencieuse pour les petits artefacts propres ; n'ajoutez de brèves notes de soumission post-sortie que lorsque l'artefact est complexe, à haut risque ou présente des blocages évidents.

Si la lecture locale de fichiers n'est pas disponible, demandez à l'utilisateur de fournir le contenu pertinent de references/*.md ou indiquez que les références sont indisponibles et produisez uniquement un brouillon conservateur à partir des règles de routage visibles et des principes partagés. Ne prétendez pas avoir lu des fichiers auxquels vous ne pouvez pas accéder.

Divulgation progressive : ne chargez que les fichiers nécessaires à la tâche en cours. Lorsque plusieurs références sont vraiment nécessaires et que la plateforme prend en charge les lectures groupées, lisez-les en un seul lot au lieu d'appels d'outils en série.

Fidélité linguistique : correspondez à la langue demandée par l'utilisateur ou à la langue principale du dépôt cible. La langue des instructions de cette compétence ne doit pas fuiter dans l'artefact GitHub final.

Routage des scénarios

Consultez INDEX.md pour la liste complète des 18 normes d'artefacts uniques et des 7 packs de flux de travail composites.

Utilisez ces règles de routage de haut niveau :

Signal	Acheminer vers
L'utilisateur demande un artefact explicite, comme "rédiger des notes de version" ou "créer un modèle de PR"	La référence d'artefact unique correspondante
L'utilisateur demande un package de version, des documents de mise à jour de version, une préparation de version majeure, ou un ensemble de mise à jour logicielle	references/version-release.md
L'utilisateur souhaite publier ou open-sourcer un dépôt pour la première fois	references/project-launch.md
L'utilisateur souhaite un projet prêt pour les contributeurs externes	references/contribution-setup.md
L'utilisateur souhaite traiter un bug depuis le signalement ou le tri jusqu'à une PR de correction	references/bug-fix-workflow.md
L'utilisateur souhaite transformer une idée en matériel de discussion, de conception, d'issue et d'implémentation	references/proposal-to-implementation.md
L'utilisateur souhaite un package de communication pour un changement cassant	references/breaking-change-package.md
L'utilisateur souhaite une actualisation large de la documentation ou une refonte complète	references/docs-overhaul.md

Lorsque l'invite mélange le langage des issues, des PR et des discussions :

Signal	Acheminer vers
Demande de fonctionnalité future sans diff implémenté	Demande de fonctionnalité
Amélioration d'un comportement existant	Amélioration
Contribution communautaire sans solution arrêtée	Discussion
Branche, diff ou PR implémente une nouvelle fonctionnalité	PR de fonctionnalité
Branche, diff ou PR corrige un bug ou une régression	PR de correction de bug
Changement réorganise le code sans changement de comportement	PR de refactorisation
Seule la documentation a changé	PR de documentation
L'utilisateur demande de réviser du code, une PR ou un diff	Révision de code

Si l'utilisateur demande de transformer une PR, un postmortem ou une discussion en un artefact différent, acheminez par l'artefact demandé, pas par le matériel source.

Valeurs par défaut du flux de travail composite

Les packs de flux de travail composites sont des orchestrateurs, pas des modèles. Ils sélectionnent les normes d'artefacts uniques existantes à charger.

• Les invites d'audit uniquement produisent des recommandations, pas des fichiers de package.
• Posez une seule question de sélection de package uniquement lorsque la règle de décision du pack ne peut pas choisir un défaut en toute sécurité.
• Lorsqu'un défaut est choisi sans demander, enregistrez l'option sélectionnée et les hypothèses dans package-manifest.md.
• Incluez les suppléments optionnels dans le même message.
• L'emplacement de sortie par défaut est les fichiers de brouillon locaux sous .github-writing/<nom-du-pack>/<version-ou-date>/.
• Si aucune version ou date n'est connue, utilisez .github-writing/<nom-du-pack>/TBD/.
• Incluez package-manifest.md dans chaque package composite, listant les fichiers générés, les hypothèses, les champs TODO / TBD, les fichiers pouvant être écrits en toute sécurité, et les fichiers nécessitant une confirmation du mainteneur.
• Si l'écriture de fichiers n'est pas disponible, affichez le package sous forme de sortie de chat multi-fichiers en utilisant les en-têtes ## Fichier : ... et des blocs délimités. Ne prétendez pas que les fichiers ont été écrits.
• Ne publiez pas, ne créez pas de versions GitHub, ne poussez pas de tags, n'ouvrez pas de PR et ne modifiez pas l'état distant sauf si l'utilisateur le demande explicitement.

Index des références

Chargez INDEX.md pour une navigation complète. Groupes de références courants :

Groupe	Références
Issues	bug-report.md, feature-request.md, enhancement.md, discussion.md
Pull requests	feature-pr.md, bug-fix-pr.md, refactor-pr.md, documentation-pr.md
Révision et commit	code-review.md, standard-commit.md
Documentation	readme.md, contributing.md, changelog.md
Version et conception	release-notes.md, migration-guide.md, rfc.md
Modèles	issue-form-yaml.md, pr-template.md
Packs composites	version-release.md, project-launch.md, contribution-setup.md, bug-fix-workflow.md, proposal-to-implementation.md, breaking-change-package.md, docs-overhaul.md
Annexes	shared-principles.md, weapons.md, badge-catalog.md, emoji-guide.md, output-validation.md, source-catalog.md

Informations manquantes

Ne posez une brève question de suivi que lorsqu'un choix requis ne peut pas être déduit en toute sécurité, comme le nom du package cible, la version de version, l'intention de changement cassant, la forme du package de sortie, ou un choix de portée qui modifie la structure de l'artefact. Sinon, utilisez TBD ou TODO, énoncez brièvement les hypothèses, et supprimez les sections optionnelles en l'absence de preuves.

Maintenance du dépôt

• Gardez SKILL.md comme routeur d'exécution léger.
• Placez les règles spécifiques aux scénarios et aux packs composites dans le references/*.md correspondant.
• Gardez INDEX.md uniquement pour la navigation.
• Gardez les instructions d'exécution en anglais par défaut.
• Mettez à jour les leçons destinées au README dans references/readme.md lorsque des erreurs de README sont découvertes.
• Gardez les sorties de recherche et de validation locales en dehors du contenu d'exécution suivi.