Qiaomu GitHub Publisher

Convierte un proyecto funcional en un repositorio de GitHub que la gente pueda entender, probar, marcar con estrella, instalar y en el que confíe.

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

Flujo de Trabajo Principal

Inspeccionar el repositorio antes de escribir:
- README.md, package.json / metadatos del proyecto, capturas de pantalla, ejemplos, documentación, licencia, scripts de implementación, scripts de prueba.
- Superficies de GitHub y comunidad: Descripción Acerca de, página de inicio, temas, vista previa social, licencia, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, plantillas de issues, plantilla de PR, versiones/changelog cuando estén presentes.
- Estado remoto de GitHub mediante gh repo view --json name,description,homepageUrl,repositoryTopics,url,defaultBranchRef,isPrivate,licenseInfo.
Decidir el posicionamiento público:
- Frase de enganche en una línea en chino e inglés, con la versión en chino primero.
- Usuarios objetivo y por qué deberían probarlo ahora.
- Límites claros entre el valor del producto, la arquitectura técnica y la configuración privada/local.
- Postura de lanzamiento prevista: solo exhibición, herramienta instalable por el usuario, proyecto con colaboradores externos, biblioteca/paquete o producto implementado.
Reescribir o parchear el README como una página de producto:
- README.md es la puerta de entrada de GitHub. Para los repositorios propiedad de Qiaomu, debe ser chino primero y bilingüe por defecto.
- Poner el chino primero, luego el inglés. Haga esto a menos que el usuario solicite explícitamente solo inglés o que el repositorio tenga un requisito documentado de origen no Qiaomu.
- Se permite un README.zh-CN.md separado, pero esto no satisface este requisito por sí solo; el README.md predeterminado debe mostrar chino primero.
- El inglés puede ser una sección inferior completa anclada por # English, un README.en.md enlazado o una sección reflejada compacta, pero las expectativas de instalación/prueba, verificación, límites y licencia/acceso deben ser comprensibles para los lectores de inglés.
- Construir una composición escaneable: cambio de idioma, contenido multimedia hero real, historia corta de enganche, tira de pruebas, insignias compactas, "qué/por qué", matriz de características, inicio rápido más rápido, configuración manual expandible, uso, recorrido del producto, catálogos de compatibilidad/ecosistema, flujo de trabajo/arquitectura, verificación, limitaciones y enlaces de confianza.
- Usar capturas de pantalla reales o muestras de salida cuando estén disponibles; no inventar capturas de pantalla.
Configurar la sección "Acerca de" de GitHub:
- Usar una descripción bilingüe compacta por defecto para los repositorios públicos propiedad de Qiaomu, chino primero e inglés segundo.
- Agregar la URL de la página de inicio cuando haya una demostración en vivo.
- Agregar temas específicos; evitar el spam de temas.
- Para la preparación del lanzamiento público, crear o solicitar una imagen de vista previa social. Si no se puede automatizar, registrar el paso manual de Configuración de GitHub como una acción de seguimiento en lugar de pretender que se configuró.
Mejorar las superficies de confianza según la postura de lanzamiento:
- Siempre verificar el estado de la licencia para los repositorios de código abierto.
- Para proyectos con colaboradores externos, agregar o actualizar CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, plantillas de issues y una plantilla de PR cuando falten o estén desactualizados.
- Para repositorios de solo exhibición, explicar si los archivos de contribución/comunidad se omitieron intencionalmente.
Verificar lo que promete el README:
- Ejecutar los comandos de lint/construcción/prueba proporcionados por el proyecto cuando sea relevante.
- Para habilidades, verificar la capacidad de descubrimiento/instalación de npx skills add.
- Para sitios web, verificar la URL/API/salud en vivo después de la implementación cuando corresponda.
Publicar a través de un flujo de GitHub limpio:
- Usar una rama de características y un PR.
- Nunca enviar directamente a main.
- Si la verificación pasa y el usuario no ha solicitado explícitamente esperar, fusionar el PR en main.
- En la respuesta final, incluir la URL del PR y la confirmación de fusión.

Modelo de Presentación Basado en el Origen

Esta habilidad se basa en las propias superficies de presentación de repositorios de GitHub:

README: GitHub dice que un README del repositorio debe explicar lo que hace el proyecto, por qué es útil, cómo empezar los usuarios, dónde obtener ayuda y quién lo mantiene. GitHub muestra automáticamente un README reconocido a los visitantes.
Temas: Los temas de GitHub ayudan a las personas a descubrir repositorios por propósito, área temática, comunidad, idioma u otras cualidades importantes.
Licencia: La guía de licencias de GitHub dice que un repositorio público necesita una licencia de código abierto antes de que otros sean claramente libres de usarlo, cambiarlo y distribuirlo.
Perfil de la comunidad: La lista de verificación de repositorios públicos de GitHub busca README, licencia, código de conducta, guía de contribución, política de seguridad y plantillas de issues/PR.
Política de seguridad: SECURITY.md indica a las personas cómo reportar vulnerabilidades.
Plantillas de issues y PR: Las plantillas estandarizan la información que los colaboradores proporcionan al abrir issues o pull requests.
Vista previa social: GitHub permite a los mantenedores de repositorios establecer una imagen de vista previa social desde la configuración del repositorio; usar fondos sólidos cuando la transparencia pueda renderizarse de forma impredecible.

Usar la documentación oficial primero cuando esta guía entre en conflicto con una lista de verificación de blog.

Caso de referencia para aprender, no para copiar ciegamente: santifer/career-ops presenta su README como una página de lanzamiento compacta. Comienza con el acceso al idioma, una imagen hero real, una historia de origen de tres líneas, pruebas externas obtenidas, una demostración, resultados cuantificados, insignias específicas, luego pasa a lo que es, características, inicio rápido, uso, flujo de trabajo, estructura, stack, descargo de responsabilidad y contacto. Reutilizar esa lógica de ordenamiento cuando se ajuste a un repositorio Qiaomu, pero nunca inventar afirmaciones de prensa, comunidad, descargas, estrellas, éxito de usuarios o uso.

Caso de referencia para productos complejos: nexu-io/open-design trata su README como un mapa de productos para un ecosistema grande. Utiliza avisos de lanzamiento/CTA, una sección sólida de recorrido del producto, galerías de demostración agrupadas, tablas de compatibilidad de plataformas, inicio rápido de múltiples rutas, uso de agente/MCP, catálogos de habilidades/sistemas de diseño/plugins, notas de arquitectura y seguridad, hoja de ruta, tablas de comunidad/contribución, mantenedores, actividad del repositorio y linaje/procedencia. Reutilizar esto como una lista de verificación modular para repositorios Qiaomu con muchas superficies, pero nunca copiar números de escala, matrices de soporte, afirmaciones de servicio pago, afirmaciones de la comunidad, garantías de seguridad o linaje de terceros a menos que se verifiquen en el repositorio actual.

Estándar del README

Puerta de Acceso al Idioma

Para los repositorios públicos propiedad de Qiaomu, README.md debe ser bilingüe con chino primero antes del lanzamiento:

Primer viewport: nombre del proyecto, propuesta de valor en chino, propuesta de valor en inglés, insignias/enlaces y un cambio de idioma visible como **中文** | [English](#english).
Cuerpo principal: secciones en chino primero, escritas como la experiencia de lectura predeterminada.
Acceso en inglés: proporcionar una sección en inglés sustancial o un README en inglés enlazado. Como mínimo, los lectores de inglés deben entender lo que hace, cómo probarlo/instalarlo, qué está verificado y los principales límites/prerrequisitos.
Pueden existir archivos de traducción como README.zh-CN.md y README.en.md, pero el README.md predeterminado de GitHub debe abrirse con chino primero a menos que el usuario haya aprobado explícitamente una audiencia diferente.
Si README.md es solo inglés, inglés primero o depende de un archivo chino separado para la experiencia en chino, detenerse y corregirlo antes de abrir/fusionar el PR de lanzamiento.

Puerta de Acceso al Primer Viewport

La parte superior de README.md debe pasar una prueba de desconocido de 60 segundos:

¿Qué es esto, en una oración concreta?
¿Para quién es y qué dolor elimina?
¿Qué puedo hacer clic, instalar o probar de inmediato?
¿Qué prueba puedo ver: captura de pantalla, demostración, salida de muestra, insignia de CI o comando verificado?
¿En qué debo confiar: licencia, mantenedor, límite de seguridad/privacidad y último estado verificado?

Evitar muros de insignias, eslóganes abstractos y aperturas centradas en la arquitectura. La arquitectura pertenece después de que el usuario entienda el valor del producto.

El README público debe responder cinco preguntas rápidamente:

¿Qué dolor soluciona esto?
¿Qué obtengo después de instalarlo/ejecutarlo?
¿Puedo ver una prueba en una captura de pantalla, demostración o salida de ejemplo?
¿Cómo lo pruebo en menos de cinco minutos?
¿Cuáles son los límites, costos o prerrequisitos?

Puerta de Composición

Usar un diseño de README que funcione como página de producto y como documento técnico:

Liderar con el resultado y la prueba antes de los detalles internos: nombre del proyecto, cambio de idioma, contenido multimedia real del producto, una o dos líneas de valor concretas, enlaces de acción principales y una línea de prueba confiable.
Hacer que la prueba sea específica y verificable: demostración en vivo, comando de instalación, insignia de paquete/lanzamiento, resultado de CI, captura de pantalla, salida de muestra, punto de referencia, caso de estudio, resultado del usuario, mención de prensa o gráfico de estrellas. Si no se verificó u obtuvo, omitirla.
Usar una tabla de características cuando haya 4 o más capacidades. Cada fila debe mapear una capacidad nombrada al resultado visible para el usuario, no solo enumerar módulos.
Poner la ruta más rápida y exitosa antes de la configuración manual. Usar un comando o la ruta más corta probada primero, luego ocultar la configuración manual más larga en <details> cuando pueda abrumar la página.
Después del inicio rápido, agregar comandos de uso, flujo de trabajo/cómo funciona, estructura del proyecto y stack tecnológico. Estas secciones deben ayudar a un usuario serio a inspeccionar el sistema sin retrasar la primera prueba.
Poner la privacidad, la propiedad de los datos, los costos, los términos de terceros, "no es un servicio alojado" y los límites de "no hace X" en una sección visible de limitaciones/descargo de responsabilidad cuando sea relevante.
Mantener los activos visuales intencionales. Una imagen hero, un GIF de demostración, logotipos, insignias y gráficos deben probar el producto o el estado; no deben convertirse en decoración o autoridad prestada.

Puerta de Catálogo de Productos Complejos

Usar esto cuando el repositorio sea más que una sola aplicación/biblioteca: aplicaciones multiplataforma, ecosistemas de agentes, catálogos de plugins/plantillas, sistemas de diseño, canalizaciones multimedia, servidores MCP, stacks autoalojados o proyectos con superficies sustanciales de comunidad/contribución.

Agregar un recorrido del producto antes de los detalles internos profundos. Agrupar capturas de pantalla/demos por superficie de usuario o tipo de artefacto, y dar a cada elemento un resultado de una línea: aplicación de entrada, estudio/editor, panel, mercado de plugins, salida generada, API, CLI, MCP, vista móvil/escritorio, etc.
Agregar una matriz de compatibilidad cuando el producto se ejecute en múltiples plataformas, agentes, proveedores, sistemas operativos, modos de implementación o gestores de paquetes. Las columnas deben ser concretas: objetivo, estado, comando de instalación, comando de verificación y límites conocidos.
Agregar catálogos de ecosistema para habilidades, plugins, plantillas, sistemas de diseño, proveedores, ejemplos o integraciones. Usar recuentos solo cuando se generen desde el repositorio o se verifiquen recientemente; de lo contrario, decir "muchos" o enlazar al directorio. Buenas columnas: elemento, categoría/modo, audiencia, salida, ruta de origen.
Ofrecer inicios rápidos por persona/ruta: aplicación de escritorio o alojada, solo CLI/agente, Docker/autoalojado, ruta de desarrollador desde el origen. Poner la ruta recomendada primero y dar a cada ruta una verificación de éxito.
Mostrar arquitectura y seguridad juntas cuando el repositorio tenga un daemon, servidor MCP, proxy, base de datos local, credenciales, artefactos generados o límite de red. Preferir un diagrama/tabla compacto, enlazar al documento profundo autorizado y evitar duplicar detalles de almacenamiento o manejo de secretos propensos a desviarse.
Incluir secciones de hoja de ruta, comunidad, contribución, mantenedor y procedencia cuando el repositorio invite a trabajo externo o incluya activos de terceros. La procedencia debe nombrar los proyectos ascendentes, los límites de licencia y lo que se adaptó o incluyó.
Mantener la densidad del catálogo bajo control: usar tablas para escanear, <details> para inventarios largos y documentos profundos para listas exhaustivas. El README debe orientar a un recién llegado, no convertirse en el manual completo.

Estructura recomendada:

# Project Name

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

![Captura de pantalla o hero del producto](docs/assets/product-screenshot.png)

> Propuesta de valor en chino
> English value proposition

[Demo en vivo] [Instalar] [Documentos] [Licencia] [IC]

**Verificado:** `npm test` / `npx skills add ...` / verificación de salud en vivo / salida de muestra

## 这是什么
## 为什么值得用
## 核心能力

| 能力 | 用户得到什么 |
|---|---|
| ... | ... |

## 样例输出
## 快速开始

### 最快路径

```bash
...

...

使用方式

产品巡游 / Demo

平台兼容 / 生态目录

工作流 / 原理

架构与安全模型

项目结构

部署 / API / Skill

路线图 / 社区 / 贡献

来源谱系 / License 边界

实测验证

限制、隐私与边界

Troubleshooting

关于向阳乔木

English section


### Prueba y Contenido Multimedia

- Preferir una captura de pantalla real, un GIF de demostración, una transcripción de terminal, una respuesta de API, un artefacto generado o una demostración alojada cerca de la parte superior.
- Cada captura de pantalla o muestra debe coincidir con un estado verificado actual. No usar imágenes simuladas a menos que estén claramente etiquetadas como maquetas de diseño.
- Las afirmaciones cuantificadas deben ser actuales y tener origen: ejemplos incluyen número de elementos procesados, artefactos generados, versiones instaladas, objetivos de compatibilidad, recuentos de catálogos, resultados de puntos de referencia o estudios de caso publicados. Si el repositorio no puede probar un número a partir de código, metadatos generados, pruebas, artefactos de lanzamiento o documentos, usar un comando/salida verificado en su lugar.
- Para CLI/herramientas, incluir una transcripción de comando exitoso corta y un ejemplo de falla/solución de problemas.
- Para sitios web/aplicaciones, incluir URL en vivo, objetivo de implementación, verificación de salud/API y una captura de pantalla de escritorio/móvil cuando sea factible.
- Mantener el README cómodamente por debajo del límite de truncamiento de renderizado de 500 KiB de GitHub; si los documentos crecen mucho, dividir el material más profundo en `docs/` y enlazarlo.

## Estándar de Superficie de GitHub

### Estándar "Acerca de" de GitHub

Usar un formulario bilingüe compacto por defecto para los repositorios públicos propiedad de Qiaomu:

```text
Descripción corta en chino | Descripción corta en inglés.

Mantenerlo concreto. Buenos ejemplos:

把 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.

Los temas deben ser específicos y útiles:

dominio: app-store, app-reviews, notebooklm, geo
stack: nextjs, agent-skill, deepseek
audiencia/flujo de trabajo: product-management, ai-workflow

Evitar temas genéricos como tool, website, ai a menos que añadan capacidad de descubrimiento.

Homepage, Insignias y Vista Previa Social

Establecer la página de inicio en la demo en vivo, documentación, página de instalación o página de inicio del producto. Si ninguna existe, dejarla en blanco en lugar de apuntar a una página no relacionada.
Usar una fila pequeña de insignias: CI/construcción, licencia, paquete, versión. Mantenerlas enfocadas en señalización verificable; evitar barras de insignias decorativas.

joeseesun/qiaomu-github-publisher

¿Qué es qiaomu-github-publisher?

Preguntar en tu IA favorita

Vista previa

Documentación