Qiaomu GitHub Publisher

Transforme um projeto funcional em um repositório GitHub que as pessoas possam entender, testar, favoritar, instalar e confiar.

X: https://x.com/vista8
GitHub: https://github.com/joeseesun/
Fonte do perfil: ~/.agents/skills/qiaomu-profile

Fluxo de Trabalho Principal

Inspecione o repositório antes de escrever:
- README.md, package.json / metadados do projeto, capturas de tela, exemplos, documentação, licença, scripts de implantação, scripts de teste.
- Superfícies do GitHub e da comunidade: descrição Sobre, homepage, tópicos, preview social, licença, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, templates de issue, template de PR, releases/changelog quando presentes.
- Estado remoto do GitHub via gh repo view --json name,description,homepageUrl,repositoryTopics,url,defaultBranchRef,isPrivate,licenseInfo.
Decida o posicionamento público:
- Frase de efeito em uma linha em chinês e inglês, com a versão em chinês primeiro.
- Usuários-alvo e por que devem testá-lo agora.
- Limite claro entre valor do produto, arquitetura técnica e configuração privada/local.
- Postura de lançamento pretendida: apenas vitrine, ferramenta instalável pelo usuário, projeto com contribuidores externos, biblioteca/pacote ou produto implantado.
Reescreva ou corrija o README como uma página de produto:
- README.md é a porta de entrada do GitHub. Para repositórios de propriedade do Qiaomu, deve ser bilíngue com prioridade para chinês por padrão.
- Coloque chinês primeiro, depois inglês. Faça isso a menos que o usuário peça explicitamente apenas inglês ou que o repositório tenha um requisito documentado de upstream não-Qiaomu.
- Um README.zh-CN.md separado é permitido, mas não satisfaz este requisito por si só; o README.md padrão deve mostrar chinês primeiro.
- O inglês pode ser uma seção inferior completa ancorada por # English, um README.en.md vinculado ou uma seção espelhada compacta, mas instalação/teste, verificação, limites e expectativas de licença/acesso devem ser compreensíveis para leitores de inglês.
- Construa uma composição amigável para escaneamento: troca de idioma, mídia principal real, história curta, faixa de prova, badges compactos, "o que/por quê", matriz de funcionalidades, início rápido mais rápido, configuração manual expansível, uso, tour do produto, compatibilidade/catálogos de ecossistema, fluxo de trabalho/arquitetura, verificação, limitações e links de confiança.
- Use capturas de tela reais ou amostras de saída quando disponíveis; não invente capturas de tela.
Configure o Sobre do GitHub:
- Use uma descrição bilíngue compacta por padrão para repositórios públicos de propriedade do Qiaomu, chinês primeiro e inglês depois.
- Adicione URL da homepage quando houver uma demonstração ao vivo.
- Adicione tópicos focados; evite spam de tópicos.
- Para polimento de lançamento público, crie ou solicite uma imagem de preview social. Se não puder ser automatizado, registre a etapa manual de Configurações do GitHub como acompanhamento, em vez de fingir que foi configurada.
Melhore as superfícies de confiança de acordo com a postura de lançamento:
- Sempre verifique o estado da licença para repositórios de código aberto.
- Para projetos com contribuidores externos, adicione ou atualize CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, templates de issue e um template de PR quando ausentes ou desatualizados.
- Para repositórios apenas de vitrine, explique se arquivos de contribuição/comunidade foram omitidos intencionalmente.
Verifique o que o README promete:
- Execute comandos de lint/build/teste fornecidos pelo projeto quando relevante.
- Para skills, verifique a descobribilidade/instalabilidade de npx skills add.
- Para websites, verifique URL/API/saúde ao vivo após a implantação, quando aplicável.
Publique através de um fluxo Git limpo:
- Use uma branch de funcionalidade e PR.
- Nunca faça push diretamente para main.
- Se a verificação passar e o usuário não tiver pedido explicitamente para segurar, faça merge do PR em main.
- Na resposta final, inclua a URL do PR e o commit de merge.

Modelo de Apresentação Baseado em Fonte

Este skill é fundamentado nas próprias superfícies de apresentação de repositórios do GitHub:

README: GitHub diz que um README de repositório deve explicar o que o projeto faz, por que é útil, como os usuários começam, onde obter ajuda e quem o mantém. O GitHub automaticamente exibe um README reconhecido para visitantes.
Tópicos: Os tópicos do GitHub ajudam as pessoas a descobrir repositórios por propósito, área temática, comunidade, idioma ou outras qualidades importantes.
Licença: A orientação de licença do GitHub diz que um repositório público precisa de uma licença de código aberto antes que outros estejam claramente livres para usar, modificar e distribuir.
Perfil da comunidade: A lista de verificação de repositório público do GitHub procura README, licença, código de conduta, guia de contribuição, política de segurança e templates de issue/PR.
Política de segurança: SECURITY.md informa às pessoas como relatar vulnerabilidades.
Templates de issue e PR: templates padronizam as informações que os contribuidores fornecem ao abrir issues ou pull requests.
Preview social: GitHub permite que mantenedores de repositório definam uma imagem de preview social nas configurações do repositório; use fundos sólidos quando a transparência pode renderizar de forma imprevisível.

Use a documentação oficial primeiro quando esta orientação entrar em conflito com uma lista de verificação de blog.

Caso de referência para aprender, não copiar cegamente: santifer/career-ops apresenta seu README como uma página de lançamento compacta. Ele começa com acesso ao idioma, uma imagem principal real, uma história de origem de três linhas, prova externa obtida, uma demonstração, resultados quantificados, badges focados, então passa para o que é, funcionalidades, início rápido, uso, fluxo de trabalho, estrutura, pilha, aviso legal e contato. Reutilize essa lógica de ordenação quando se adequar a um repositório Qiaomu, mas nunca invente alegações de imprensa, comunidade, downloads, estrelas, sucesso do usuário ou uso.

Caso de referência para produtos complexos: nexu-io/open-design trata seu README como um mapa de produto para um grande ecossistema. Ele usa avisos de release/CTA, uma seção forte de tour do produto, galerias de demonstração agrupadas, tabelas de compatibilidade de plataforma, início rápido de múltiplos caminhos, uso de agente/MCP, catálogos de skills/design-system/plugins, notas de arquitetura e segurança, roadmap, tabelas de comunidade/contribuição, mantenedores, atividade do repositório e linhagem/proveniência. Reutilize isso como uma lista de verificação modular para repositórios Qiaomu com muitas superfícies, mas nunca copie números de escala, matrizes de suporte, alegações de serviço pago, alegações de comunidade, garantias de segurança ou linhagem de terceiros, a menos que verificado no repositório atual.

Padrão de README

Portão de Idioma

Para repositórios públicos de propriedade do Qiaomu, README.md deve ser bilíngue com prioridade para chinês antes do lançamento:

Primeiro viewport: nome do projeto, proposta de valor em chinês, proposta de valor em inglês, badges/links e uma troca de idioma visível como **中文** | [English](#english).
Corpo principal: seções em chinês primeiro, escritas como a experiência de leitura padrão.
Acesso em inglês: forneça uma seção substancial em inglês ou um README em inglês vinculado. No mínimo, leitores de inglês devem entender o que faz, como testar/instalar, o que é verificado e os principais limites/pré-requisitos.
Arquivos de tradução como README.zh-CN.md e README.en.md podem existir, mas o README.md padrão do GitHub ainda deve abrir com chinês primeiro, a menos que o usuário tenha aprovado explicitamente um público diferente.
Se README.md for apenas inglês, inglês primeiro ou depender de um arquivo chinês separado para a experiência em chinês, pare e corrija antes de abrir/fazer merge do PR de lançamento.

Portão de Primeiro Viewport

O topo do README.md deve passar em um teste de estranho de 60 segundos:

O que é isso, em uma frase concreta?
Para quem é e que dor remove?
O que posso clicar, instalar ou testar imediatamente?
Que prova posso ver: captura de tela, demonstração, saída de exemplo, badge de CI ou comando verificado?
Em que devo confiar: licença, mantenedor, segurança/privacidade e status da última verificação?

Evite paredes de badges, slogans abstratos e aberturas focadas em arquitetura. A arquitetura pertence depois que o usuário entende o valor do produto.

O README público deve responder cinco perguntas rapidamente:

Que dor isso resolve?
O que obtenho depois de instalar/executar?
Posso ver prova em uma captura de tela, demonstração ou saída de exemplo?
Como testar em menos de cinco minutos?
Quais são os limites, custos ou pré-requisitos?

Portão de Composição

Use um layout de README que funcione como página de produto e documento técnico:

Comece com resultado e prova antes dos detalhes internos: nome do projeto, troca de idioma, mídia de produto real, uma ou duas linhas de valor concretas, links de ação principais e uma linha de prova confiável.
Torne a prova específica e verificável: demonstração ao vivo, comando de instalação, badge de pacote/release, resultado de CI, captura de tela, saída de exemplo, benchmark, estudo de caso, resultado do usuário, menção na imprensa ou gráfico de estrelas. Se não foi verificado ou obtido, omita.
Use uma tabela de funcionalidades quando houver 4+ capacidades. Cada linha deve mapear uma capacidade nomeada para o resultado visível ao usuário, não apenas listar módulos.
Coloque o caminho de sucesso mais rápido antes da configuração manual. Use um comando ou o caminho mais curto comprovado primeiro, depois esconda a configuração manual mais longa em <details> quando ela puder sobrecarregar a página.
Após o início rápido, adicione comandos de uso, fluxo de trabalho/como funciona, estrutura do projeto e pilha técnica. Essas seções devem ajudar um usuário sério a inspecionar o sistema sem atrasar a primeira tentativa.
Coloque privacidade, propriedade de dados, custos, termos de terceiros, "não é um serviço hospedado" e limites "não faz X" em uma seção visível de limitações/aviso legal quando relevante.
Mantenha ativos visuais propositais. Uma imagem principal, GIF de demonstração, logotipos, badges e gráficos devem provar o produto ou status; não devem se tornar decoração ou autoridade emprestada.

Portão de Catálogo de Produto Complexo

Use quando o repositório for mais que um único aplicativo/biblioteca: aplicativos multiplataforma, ecossistemas de agentes, catálogos de plugins/templates, sistemas de design, pipelines de mídia, servidores MCP, pilhas auto-hospedadas ou projetos com superfícies substanciais de comunidade/contribuição.

Adicione um tour do produto antes dos detalhes internos profundos. Agrupe capturas de tela/demonstrações por superfície de usuário ou tipo de artefato, e dê a cada item um resultado de uma linha: aplicativo de entrada, estúdio/editor, dashboard, mercado de plugins, saída gerada, API, CLI, MCP, visualização móvel/desktop, etc.
Adicione uma matriz de compatibilidade quando o produto executa em múltiplas plataformas, agentes, provedores, sistemas operacionais, modos de implantação ou gerenciadores de pacotes. As colunas devem ser concretas: alvo, status, comando de instalação, comando de verificação e limites conhecidos.
Adicione catálogos de ecossistema para skills, plugins, templates, sistemas de design, provedores, exemplos ou integrações. Use contagens apenas quando geradas a partir do repositório ou recém-verificadas; caso contrário, diga "muitos" ou aponte para o diretório. Boas colunas: item, categoria/modo, público, saída, caminho de origem.
Ofereça inícios rápidos por persona/caminho: aplicativo desktop ou hospedado, apenas CLI/agente, Docker/auto-hospedado, caminho de desenvolvedor a partir da fonte. Coloque o caminho recomendado primeiro e dê a cada caminho uma verificação de sucesso.
Mostre arquitetura e segurança juntas quando o repositório tiver um daemon, servidor MCP, proxy, banco de dados local, credenciais, artefatos gerados ou limite de rede. Prefira um diagrama/tabela compacto, aponte para o documento profundo autoritativo e evite duplicar detalhes de armazenamento ou manuseio de segredos sujeitos a desvios.
Inclua seções de roadmap, comunidade, contribuição, mantenedor e proveniência quando o repositório convidar trabalho externo ou agrupar ativos de terceiros. Proveniência deve nomear projetos upstream, limites de licença e o que foi adaptado ou agrupado.
Mantenha a densidade do catálogo sob controle: use tabelas para escaneamento, <details> para inventários longos e documentos profundos para listas exaustivas. O README deve orientar um recém-chegado, não se tornar o manual inteiro.

Estrutura recomendada:

# Nome do Projeto

**中文** | [English](#english)

![Captura de tela do produto ou hero](docs/assets/product-screenshot.png)

> Proposta de valor em chinês
> Proposta de valor em inglês

[Demo ao vivo] [Instalar] [Docs] [Licença] [CI]

**Verificado:** `npm test` / `npx skills add ...` / verificação de saúde ao vivo / saída de exemplo

## O que é isso
## Por que vale a pena
## Capacidades principais

| Capacidade | O que o usuário obtém |
|---|---|
| ... | ... |

## Saída de exemplo
## Início rápido

### Caminho mais rápido

```bash
...

...

Modo de usar

Tour do produto / Demo

Compatibilidade de plataforma / Catálogo do ecossistema

Fluxo de trabalho / Princípios

Arquitetura e modelo de segurança

Estrutura do projeto

Implantação / API / Skill

Roadmap / Comunidade / Contribuição

Linhagem de origem / Limites de licença

Verificação prática

Limitações, privacidade e limites

Solução de problemas

Sobre 向阳乔木

Seção em inglês


### Prova e Mídia

- Prefira uma captura de tela real, GIF de demonstração, transcrição de terminal, resposta de API, artefato gerado ou demonstração hospedada perto do topo.
- Cada captura de tela ou amostra deve corresponder a um estado verificado atual. Não use imagens mock a menos que claramente rotuladas como maquetes de design.
- Alegações quantificadas devem ser atuais e com fonte: exemplos incluem número de itens processados, artefatos gerados, versões instaladas, alvos de compatibilidade, contagens de catálogo, resultados de benchmark ou estudos de caso publicados. Se o repositório não puder provar um número a partir de código, metadados gerados, testes, artefatos de release ou documentação, use um comando/saída verificado em vez disso.
- Para CLI/ferramentas, inclua uma transcrição curta de comando bem-sucedido e um exemplo de falha/solução de problemas.
- Para websites/aplicativos, inclua URL ao vivo, alvo de implantação, verificação de saúde/API e uma captura de tela de desktop/mobile quando viável.
- Mantenha o README confortavelmente abaixo do limite de truncamento de renderização de 500 KiB do GitHub; se a documentação crescer muito, divida material mais profundo em `docs/` e aponte para ele.

## Padrão de Superfície do GitHub

### Padrão Sobre do GitHub

Use um formato bilíngue compacto por padrão para repositórios públicos de propriedade do Qiaomu:

```text
Descrição curta em chinês | Descrição curta em inglês.

Mantenha concreto. Exemplos bons:

把 App Store 评价变成产品研究证据，发现痛点、机会和版本风险 | Turn App Store reviews into product research evidence: pain points, opportunities, and version risks.
把任意资料整理成 NotebookLM 可用知识包 | Turn messy sources into NotebookLM-ready knowledge packs.

Tópicos devem ser estreitos e úteis:

domínio: app-store, app-reviews, notebooklm, geo
pilha: nextjs, agent-skill, deepseek
público/fluxo de trabalho: product-management, ai-workflow

Evite tópicos genéricos como tool, website, ai a menos que adicionem descobribilidade.

Homepage, Badges e Preview Social

Defina a homepage para a demonstração ao vivo, documentação, página de instalação ou página inicial do produto. Se nenhum existir, deixe em branco em vez de apontar para uma página não relacionada.
Use uma pequena linha de badges: CI/build, licença, pacote...

joeseesun/qiaomu-github-publisher

O que é qiaomu-github-publisher?

Perguntar na sua IA favorita

Prévia

Documentação