oh-my-gh-writing

¿Qué hace oh-my-gh-writing?

Habilidad de escritura para GitHub, diseñada para agentes de IA. Enruta la solicitud, carga el estándar correspondiente, mantiene los límites de evidencia explícitos y produce borradores de GitHub casi listos para su envío.

Límite de activación

Usa esta habilidad para artefactos de escritura orientados a GitHub y paquetes de borradores de escritura local de GitHub. No la uses para redacción general, textos de interfaz de usuario, implementación de código, estrategia de producto o trabajo de documentación amplio, a menos que el resultado solicitado sea un artefacto de GitHub o un archivo de repositorio de GitHub.

Flujo de trabajo

1. Identifica si el usuario quiere un artefacto individual o un paquete de flujo de trabajo con múltiples artefactos.
2. Si el usuario menciona explícitamente un solo artefacto, enruta a ese artefacto incluso si el tema es amplio.
3. Si el usuario solicita un flujo de trabajo amplio, lanzamiento, configuración, paquete de versión o conjunto de materiales de principio a fin, enruta al paquete de flujo de trabajo compuesto correspondiente.
4. Si el usuario pide inspeccionar, verificar, revisar la preparación o recomendar qué archivos se necesitan, trátalo como solo auditoría: genera un análisis de brechas y recomendaciones del siguiente archivo. No crees archivos de destino, no crees .github-writing/ ni escribas archivos .github/ o raíz del repositorio a menos que el usuario pida explícitamente redactar, crear, escribir, aplicar o actualizar archivos.
5. Para solicitudes de README, usa las tres preguntas guía en references/readme.md.
6. Para paquetes de flujo de trabajo compuestos, sigue la Regla de Decisión del paquete. Pregunta la cuestión de selección del paquete solo cuando no se pueda inferir la forma del paquete de manera segura; de lo contrario, usa la opción predeterminada recomendada y regístrala en package-manifest.md.
7. Abre y lee explícitamente el references/*.md correspondiente antes de escribir la salida para el usuario. No infieras ni adivines el contenido de las referencias de memoria.
8. Lee solo las referencias de artefacto individual seleccionadas por un paquete compuesto. No precargues todas las referencias.
9. Lee references/weapons.md cuando se necesiten badges, alertas, diagramas Mermaid, bloques plegables, emojis o tablas complejas.
10. Lee references/badge-catalog.md solo cuando el usuario solicite un diseño detallado de badges o patrones exactos de URL de shields.io.
11. Lee references/emoji-guide.md cuando se soliciten emojis o el repositorio de destino ya los use.
12. Lee references/shared-principles.md cuando la solicitud tenga muchos datos, sea de alto riesgo, abarque varios escenarios o cuando se necesite aclarar reglas de calidad de salida.
13. Antes de finalizar, usa references/output-validation.md como lista de verificación de revisión silenciosa. Si el borrador no supera una verificación, revísalo antes de entregarlo. Mantén la validación silenciosa para artefactos pequeños y limpios; añade notas breves de envío posterior solo cuando el artefacto sea complejo, de alto riesgo o tenga bloqueos evidentes.

Si la lectura de archivos locales no está disponible, pide al usuario que proporcione el contenido relevante de references/*.md o indica que las referencias no están disponibles y produce solo un borrador conservador a partir de las reglas de enrutamiento visibles y los principios compartidos. No finjas haber leído archivos a los que no puedes acceder.

Divulgación progresiva: carga solo los archivos necesarios para la tarea actual. Cuando se necesiten varias referencias y la plataforma admita lecturas por lotes, léelas en un solo lote en lugar de llamadas seriales a herramientas.

Fidelidad del idioma: usa el idioma solicitado por el usuario o el idioma principal del repositorio de destino. El idioma de las instrucciones de esta habilidad no debe filtrarse al artefacto final de GitHub.

Enrutamiento de escenarios

Consulta INDEX.md para la lista completa de 18 estándares de artefacto individual y 7 paquetes de flujo de trabajo compuestos.

Usa estas reglas de enrutamiento de nivel superior:

Señal	Enrutar a
El usuario pide un artefacto explícito, como "escribe notas de versión" o "crea una plantilla de PR"	La referencia de artefacto individual correspondiente
El usuario pide un paquete de versión, materiales de actualización de versión, preparación de versión importante o un paquete de actualización de software	references/version-release.md
El usuario quiere publicar o abrir un repositorio por primera vez	references/project-launch.md
El usuario quiere que un proyecto esté listo para colaboradores externos	references/contribution-setup.md
El usuario quiere manejar un error desde el informe o el triaje hasta un PR de corrección	references/bug-fix-workflow.md
El usuario quiere convertir una idea en materiales de discusión, diseño, issue e implementación	references/proposal-to-implementation.md
El usuario quiere un paquete de comunicación de cambio disruptivo	references/breaking-change-package.md
El usuario quiere una actualización o revisión amplia de documentación	references/docs-overhaul.md

Cuando la solicitud mezcle lenguaje de issues, PRs y discusiones:

Señal	Enrutar a
Solicitud de funcionalidad futura sin diff implementado	Feature Request
Mejora a un comportamiento existente	Enhancement
Aporte de la comunidad con solución no decidida	Discussion
Rama, diff o PR que implementa una nueva funcionalidad	Feature PR
Rama, diff o PR que corrige un error o regresión	Bug Fix PR
Cambio que reorganiza código sin cambiar comportamiento	Refactor PR
Solo documentación modificada	Documentation PR
El usuario pide revisar código, un PR o un diff	Code Review

Si el usuario pide convertir un PR, una autopsia o una discusión en un artefacto diferente, enruta según el artefacto solicitado, no según el material de origen.

Valores predeterminados de flujos de trabajo compuestos

Los paquetes de flujo de trabajo compuestos son orquestadores, no plantillas. Seleccionan qué estándares de artefacto individual existentes cargar.

• Las solicitudes de solo auditoría producen recomendaciones, no archivos de paquete.
• Pregunta una cuestión de selección de paquete solo cuando la Regla de Decisión del paquete no pueda elegir un valor predeterminado de manera segura.
• Cuando se elige un valor predeterminado sin preguntar, registra la opción seleccionada y las suposiciones en package-manifest.md.
• Incluye suplementos opcionales en el mismo mensaje.
• La ubicación de salida predeterminada son archivos de borrador locales bajo .github-writing/<nombre-del-paquete>/<versión-o-fecha>/.
• Si no se conoce versión ni fecha, usa .github-writing/<nombre-del-paquete>/TBD/.
• Incluye package-manifest.md en cada paquete compuesto, enumerando archivos generados, suposiciones, campos TODO / TBD, archivos seguros para escribir y archivos que requieren confirmación del mantenedor.
• Si la escritura de archivos no está disponible, muestra el paquete como salida de chat de varios archivos usando encabezados ## File: ... y bloques con delimitadores. No afirmes que los archivos se escribieron.
• No publiques, crees lanzamientos de GitHub, empujes etiquetas, abras PRs ni modifiques el estado remoto a menos que el usuario lo solicite explícitamente.

Índice de referencias

Carga INDEX.md para navegación completa. Grupos de referencias comunes:

Grupo	Referencias
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
Revisión y commits	code-review.md, standard-commit.md
Documentación	readme.md, contributing.md, changelog.md
Versión y diseño	release-notes.md, migration-guide.md, rfc.md
Plantillas	issue-form-yaml.md, pr-template.md
Paquetes compuestos	version-release.md, project-launch.md, contribution-setup.md, bug-fix-workflow.md, proposal-to-implementation.md, breaking-change-package.md, docs-overhaul.md
Apéndices	shared-principles.md, weapons.md, badge-catalog.md, emoji-guide.md, output-validation.md, source-catalog.md

Información faltante

Haz una pregunta breve de seguimiento solo cuando una elección necesaria no se pueda inferir de manera segura, como el nombre del paquete de destino, la versión del lanzamiento, la intención de cambio disruptivo, la forma del paquete de salida o una elección de alcance que cambie la estructura del artefacto. De lo contrario, usa TBD o TODO, indica las suposiciones brevemente y elimina las secciones opcionales cuando no haya evidencia.

Mantenimiento del repositorio

• Mantén SKILL.md como el enrutador de tiempo de ejecución ligero.
• Coloca las reglas específicas de escenario y de paquetes compuestos en el references/*.md correspondiente.
• Mantén INDEX.md solo como navegación.
• Mantén las instrucciones de tiempo de ejecución en inglés de forma predeterminada.
• Actualiza las lecciones orientadas al README en references/readme.md cuando se descubran errores en el README.
• Mantén las salidas de investigación y validación local fuera del contenido de tiempo de ejecución rastreado.