Communitygithub.com

PINKIIILQWQ/oh-my-gh-writing

Habilidade de escrita para GitHub vinculada a evidências, com 18 padrões de artefatos e 7 pacotes de fluxo de trabalho locais.

O que é oh-my-gh-writing?

Esta skill capacita agentes de IA a produzir rascunhos de alta qualidade para artefatos do GitHub, como issues, pull requests, READMEs e documentação. Ela utiliza um roteador de cenários baseado em padrões pré-definidos e referências de evidências armazenadas em `references/*.md`. A skill suporta tanto artefatos únicos quanto pacotes de fluxo de trabalho compostos (por exemplo, lançamentos de versões, configuração de projetos, tratamento de bugs). Uma característica principal é sua adesão estrita a limites: ela não gera arquivos a menos que o usuário solicite explicitamente e, em auditorias, produz apenas recomendações e análises de lacunas. Para garantir qualidade, a skill inclui validação de saída silenciosa e carregamento progressivo de referências para evitar inferências incorretas. É ideal para agentes AI que interagem com repositórios do GitHub como parte de fluxos de desenvolvimento ou manutenção de projetos.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add PINKIIILQWQ/oh-my-gh-writing

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

O que oh-my-gh-writing faz?

Habilidade de escrita para GitHub voltada para agentes de IA. Direcione a solicitação, carregue o padrão correspondente, mantenha os limites de evidência explícitos e produza rascunhos de GitHub quase prontos para submissão.

Limite de Acionamento

Use esta habilidade para artefatos de escrita voltados ao GitHub e pacotes de rascunhos locais do GitHub. Não a utilize para copywriting geral, texto de interface, implementação de código, estratégia de produto ou documentação ampla, a menos que a saída solicitada seja um artefato do GitHub ou arquivo de repositório do GitHub.

Fluxo de Trabalho

  1. Identifique se o usuário deseja um artefato único ou um pacote de fluxo de trabalho com vários artefatos.
  2. Se o usuário nomear explicitamente um artefato único, direcione para aquele artefato, mesmo que o tópico seja amplo.
  3. Se o usuário solicitar um fluxo de trabalho amplo, lançamento, configuração, pacote de lançamento ou conjunto de materiais de ponta a ponta, direcione para o pacote de fluxo de trabalho composto correspondente.
  4. Se o usuário pedir para inspecionar, verificar, revisar a prontidão ou recomendar quais arquivos são necessários, trate como apenas auditoria: produza uma análise de lacunas e recomendações para os próximos arquivos. Não crie arquivos de destino, não crie .github-writing/ e não escreva arquivos .github/ ou raiz do repositório, a menos que o usuário peça explicitamente para rascunhar, criar, escrever, aplicar ou atualizar arquivos.
  5. Para solicitações de README, use o prompt de três perguntas em references/readme.md.
  6. Para pacotes de fluxo de trabalho compostos, siga a Regra de Decisão do pacote. Faça a pergunta de seleção do pacote apenas quando a forma do pacote não puder ser inferida com segurança; caso contrário, use o padrão recomendado e registre-o em package-manifest.md.
  7. Abra e leia explicitamente o references/*.md correspondente antes de escrever a saída voltada ao usuário. Não infira ou adivinhe o conteúdo das referências a partir da memória.
  8. Leia apenas as referências de artefato único selecionadas por um pacote composto. Não pré-carregue todas as referências.
  9. Leia references/weapons.md quando emblemas, alertas, Mermaid, blocos recolhíveis, emoji ou tabelas complexas forem necessários.
  10. Leia references/badge-catalog.md apenas quando o usuário solicitar design detalhado de emblemas ou padrões exatos de URL do shields.io.
  11. Leia references/emoji-guide.md quando emoji for solicitado ou o repositório de destino já usar emoji.
  12. Leia references/shared-principles.md quando a solicitação for pesada em fatos, de alto risco, entre cenários ou quando regras de qualidade de saída precisarem de esclarecimento.
  13. Antes de finalizar, use references/output-validation.md como uma lista de verificação de revisão silenciosa. Se o rascunho falhar em uma verificação, revise-o antes de entregar. Mantenha a validação silenciosa para artefatos pequenos e limpos; adicione notas curtas de submissão pós-saída apenas quando o artefato for complexo, de alto risco ou tiver bloqueadores óbvios.

Se a leitura de arquivos locais não estiver disponível, peça ao usuário para fornecer o conteúdo relevante de references/*.md ou indique que as referências estão indisponíveis e produza apenas um rascunho conservador a partir das regras de roteamento visíveis e princípios compartilhados. Não finja ter lido arquivos que você não pode acessar.

Divulgação progressiva: carregue apenas os arquivos necessários para a tarefa atual. Quando várias referências forem realmente necessárias e a plataforma suportar leituras em lote, leia-as em um único lote em vez de chamadas de ferramentas seriais.

Fidelidade de idioma: corresponda ao idioma solicitado pelo usuário ou ao idioma principal do repositório de destino. O idioma das instruções desta habilidade não deve vazar para o artefato final do GitHub.

Roteamento de Cenários

Consulte INDEX.md para a lista completa de 18 padrões de artefato único e 7 pacotes de fluxo de trabalho compostos.

Use estas regras de roteamento de nível superior:

SinalRota para
O usuário pede um artefato explícito, como "escreva notas de versão" ou "crie um template de PR"A referência de artefato único correspondente
O usuário pede um pacote de lançamento, materiais de atualização de versão, preparação para versão principal ou pacote de atualização de softwarereferences/version-release.md
O usuário quer publicar ou tornar um repositório open-source pela primeira vezreferences/project-launch.md
O usuário quer um projeto pronto para contribuidores externosreferences/contribution-setup.md
O usuário quer lidar com um bug desde o relato ou triagem até um PR de correçãoreferences/bug-fix-workflow.md
O usuário quer transformar uma ideia em discussão, design, issue e materiais de implementaçãoreferences/proposal-to-implementation.md
O usuário quer um pacote de comunicação de mudança breakingreferences/breaking-change-package.md
O usuário quer uma atualização ampla de documentação ou revisão de docsreferences/docs-overhaul.md

Quando o prompt mistura linguagem de issue, PR e discussão:

SinalRota para
Solicitação de funcionalidade futura sem diff implementadoFeature Request
Melhoria em comportamento existenteEnhancement
Contribuição da comunidade com solução não decididaDiscussion
Branch, diff ou PR implementa uma nova funcionalidadeFeature PR
Branch, diff ou PR corrige um bug ou regressãoBug Fix PR
Mudança reorganiza código sem alteração de comportamentoRefactor PR
Apenas documentação alteradaDocumentation PR
Usuário pede para revisar código, um PR ou um diffCode Review

Se o usuário pedir para transformar um PR, postmortem ou discussão em um artefato diferente, direcione pelo artefato solicitado, não pelo material de origem.

Padrões Padrão de Fluxo de Trabalho Composto

Pacotes de fluxo de trabalho compostos são orquestradores, não templates. Eles selecionam quais padrões de artefato único existentes carregar.

  • Prompts de apenas auditoria produzem recomendações, não arquivos de pacote.
  • Faça uma pergunta de seleção de pacote apenas quando a Regra de Decisão do pacote não puder escolher um padrão com segurança.
  • Quando um padrão for escolhido sem perguntar, registre a opção selecionada e as suposições em package-manifest.md.
  • Inclua suplementos opcionais na mesma mensagem.
  • Local de saída padrão são arquivos de rascunho locais sob .github-writing/<nome-do-pacote>/<versão-ou-data>/.
  • Se nenhuma versão ou data for conhecida, use .github-writing/<nome-do-pacote>/TBD/.
  • Inclua package-manifest.md em cada pacote composto, listando arquivos gerados, suposições, campos TODO / TBD, arquivos seguros para escrever e arquivos que exigem confirmação do mantenedor.
  • Se a escrita de arquivos não estiver disponível, exiba o pacote como saída de chat multiarquivo usando cabeçalhos ## File: ... e blocos cercados. Não afirme que os arquivos foram escritos.
  • Não publique, crie releases no GitHub, envie tags, abra PRs ou modifique estado remoto, a menos que o usuário peça explicitamente.

Índice de Referências

Carregue INDEX.md para navegação completa. Grupos de referência comuns:

GrupoReferências
Issuesbug-report.md, feature-request.md, enhancement.md, discussion.md
Pull requestsfeature-pr.md, bug-fix-pr.md, refactor-pr.md, documentation-pr.md
Revisão e commitcode-review.md, standard-commit.md
Documentaçãoreadme.md, contributing.md, changelog.md
Lançamento e designrelease-notes.md, migration-guide.md, rfc.md
Templatesissue-form-yaml.md, pr-template.md
Pacotes compostosversion-release.md, project-launch.md, contribution-setup.md, bug-fix-workflow.md, proposal-to-implementation.md, breaking-change-package.md, docs-overhaul.md
Apêndicesshared-principles.md, weapons.md, badge-catalog.md, emoji-guide.md, output-validation.md, source-catalog.md

Informações Faltantes

Faça uma rápida pergunta de acompanhamento apenas quando uma escolha necessária não puder ser inferida com segurança, como nome do pacote de destino, versão de lançamento, intenção de mudança breaking, forma do pacote de saída ou uma escolha de escopo que altere a estrutura do artefato. Caso contrário, use TBD ou TODO, declare as suposições brevemente e remova seções opcionais quando não houver evidência.

Manutenção do Repositório

  • Mantenha SKILL.md como o roteador de tempo de execução enxuto.
  • Coloque regras específicas de cenário e pacote composto no references/*.md correspondente.
  • Mantenha INDEX.md apenas para navegação.
  • Mantenha instruções de tempo de execução em inglês por padrão.
  • Atualize lições voltadas ao README em references/readme.md quando erros de README forem descobertos.
  • Mantenha pesquisas locais e saídas de validação fora do conteúdo rastreado em tempo de execução.

Habilidades Relacionadas