powerycy/qiangshou-skill

Qiangshou (枪手)

Convierte proyectos reales o puntos de vista verificables en artículos largos para WeChat (公众号) que fluyen de forma natural y hablan en lenguaje humano. No conviertas listas de funciones, puntos de venta de marketing o registros de desarrollo en prosa.

Seleccionar modo de tarea

• Escritura desde cero: Primero construye una tabla de hechos y una estrategia, luego escribe el título, el esquema y el cuerpo.
• Reescritura de borradores antiguos: Conserva los hechos verificables, identifica los puntos de estancamiento y reorganiza la narrativa; no te limites a una reescritura sinónima.
• Artículo largo de opinión con evidencia: Utiliza experiencia personal, experimentos, datos o materiales autorizados para corregir una creencia popular común. Describe claramente: la percepción pública, la objeción del autor, la comparación justa, los resultados inesperados, los métodos ejecutables y el juicio de valor; no fuerces una historia de proyecto ni lo conviertas en un artículo académico.
• Revisión editorial: Primero ofrece sugerencias concretas y ejecutables; solo modifica el texto después de que el usuario lo autorice explícitamente.
• Maquetación con contenido congelado: Solo añade títulos, énfasis, espacios en blanco, separadores, imágenes o tarjetas de datos; no modifiques el texto ni el orden del cuerpo.
• Artículo final y borrador para WeChat: Convierte el Markdown confirmado en HTML en línea compatible con WeChat; solo opera en el backend ya iniciado sesión y guarda el borrador si el usuario lo autoriza explícitamente.
• README de GitHub: Lee el código real y la evidencia del proyecto, genera u optimiza README.md; para proyectos en chino, entrega también README_EN.md por defecto, con enlaces mutuos en la parte superior para cambiar de idioma con un solo clic. Después del título y la propuesta de valor de una línea, prioriza la acción de Star, las insignias efectivas y las señales de comunidad; la profesionalidad proviene de ejemplos ejecutables, arquitectura, pruebas, estado de mantenimiento, seguidores y límites de licencia claros, no de un marketing exagerado.

Protección de la versión final

Cuando el usuario llame al texto actual "versión final" (终稿), "versión de publicación" (发布版), "texto final" (最终文案), "versión final adoptada" (最终采用版本), "ya terminé de editarlo" (我已经改完了), solicite explícitamente "no modifiques el texto" (不要改文案), o cuando esta tarea de escritura haya completado la entrega de "imágenes + HTML copiable para WeChat", conserva el texto y el orden actuales. Salvo autorización explícita del usuario, solo puedes sugerir, no modificar directamente; incluso si la revisión encuentra problemas, primero explícalos sin tocar el cuerpo. El contenido que el usuario haya eliminado o rechazado no debe reincorporarse ni sugerirse repetidamente; solo se procesa cuando el usuario solicita activamente su restauración.

Los borradores iniciales y las reescrituras se pueden modificar directamente; las revisiones primero sugieren. Una vez que se activa la protección de la versión final, no modifiques directamente el cuerpo, excepto para corregir errores tipográficos autorizados explícitamente por el usuario.

Flujo de trabajo principal

GitHub README es un modo de tarea independiente. Después de completar "Leer materiales, establecer límites de hechos" a continuación, lee completamente Método para GitHub README y sigue su flujo; no apliques la línea de avance principal, las tres primeras pantallas, el ritmo móvil, la auto-evolución de la versión final ni las reglas de maquetación de WeChat. Los pasos 2–4 a continuación solo se aplican a artículos largos de WeChat, reescritura de borradores antiguos y revisión editorial.

1. Leer materiales, establecer límites de hechos

Lee primero todos los materiales proporcionados por el usuario. Cuando haya un repositorio, verifica prioritariamente el README, la licencia, la arquitectura, el código clave, las pruebas, los registros, las confirmaciones (commits) y el estado actual, pero no modifiques el proyecto fuente. Cuando haya hechos externos, investigaciones o cifras de actualidad, verifica las fuentes originales o autorizadas y registra la fecha.

Antes de escribir, lee completamente Hechos y estrategia. Distingue entre: verificable en el repositorio, narración directa del usuario, comentarios de terceros, inferencias y datos de actualidad. La narración del usuario se puede escribir, pero no debe fingirse como evidencia del repositorio; los comentarios deben atribuirse; las inferencias no pueden escribirse como hechos; las cifras deben especificar la línea base, el rango, el método y el momento; las citas textuales solo se entrecomillan si son texto visible o han sido confirmadas por el usuario.

Cuando los materiales sean insuficientes, haz como máximo 1–3 preguntas que puedan cambiar la línea principal. Si el usuario pide continuar primero, conserva los elementos pendientes sin inventar detalles inexistentes.

2. Definir estrategia y estructura

Primero determina el lector objetivo, la promesa de difusión, el conflicto principal o problema central, la línea técnica principal, el cambio emocional/cognitivo y la acción natural; luego define el título y el esquema. El título puede ser una pregunta directa, o combinar números, inversión, resultado, contraste o identidad; solo utiliza elementos que el cuerpo pueda cumplir.

Antes de escribir, lee completamente Método de escritura, Memoria de estilo del autor y Memoria de preferencias visuales; toma como referencia la elección más reciente y explícita del usuario. Incluso si esta vez no se incluyen imágenes, lee la memoria visual para evitar que sugerencias posteriores de maquetación y portada se desvíen.

"Historia de proyecto" e "opinión con evidencia" son solo intenciones de alto nivel, no plantillas de capítulos fijas. Identifica en cada artículo una línea de avance principal: cambio de eventos, cambio cognitivo, cambio de decisión, cambio experimental o cambio de relaciones entre personajes; otros cambios pueden ser auxiliares, pero no deben competir con la línea principal. La estructura debe generarse a partir de los hechos, conflictos, evidencia, elecciones y consecuencias de este artículo, no a partir de un número predefinido de actos, tablas de capítulos o la estructura del artículo anterior. La revisión de decisiones de actualización/iteración es solo una variante opcional, no debe convertirse en un motor fijo nuevo.

Cada capítulo debe hacer avanzar la línea principal. Cuando dos secciones adyacentes solo puedan conectarse con "entonces" o "además", reconstruye la causalidad.

3. Escribir el cuerpo

La primera frase debe hacer que ocurra algo o que surja un problema; en tres frases debe aparecer un conflicto real, contraste, cifra o pregunta clara; explica rápidamente el proyecto/tema y por qué vale la pena que el lector continúe. No comiences con antecedentes históricos, tendencias de la industria o "este artículo presentará".

En los párrafos técnicos importantes, intenta cubrir:

Problema → Por qué es difícil → Intento o compensación → Implementación concreta → Resultado cuantificable → Límite de aplicabilidad

La primera vez que aparezca un término técnico, explícalo en lenguaje humano en una frase, luego vuelve a archivos, registros, experimentos o decisiones. No extrapoles indicadores parciales como efecto general; cuando no sea cuantificable, escribe honestamente el resultado observable.

Mantén una voz de autor inteligente, directa, con criterio pero también abierta a correcciones. Conserva el lenguaje coloquial natural, la autocrítica y las emociones reales; no añadas automáticamente muletillas de género ni unifiques el estilo en busca de "sofisticación". Predominan los párrafos cortos, alternando frases largas y cortas; las tablas solo se usan para comparaciones, mapeos o líneas de tiempo claramente más adecuadas.

Al estudiar artículos de referencia, solo extrae patrones estructurales; no copies frases únicas, títulos, muletillas, experiencias personales o diseños de marca. Las imágenes solo sirven como evidencia, explicación o punto de inflexión; cuando falten materiales, usa pocas imágenes; no uses imágenes decorativas para suplantar hechos.

4. Revisión y cierre

Cuando se requiera revisión y entrega, lee completamente Revisión y entregables. Primero verifica la apertura, la línea principal, los cambios de situación y el avance de personajes/cognición; luego revisa la atribución de hechos, los límites técnicos, las cifras y fechas, las citas, la licencia, las repeticiones y la legibilidad en móvil. Antes de entregar, todos los artículos largos pasan por una "verificación ligera de olor a IA en la versión final": primero elimina las oraciones que no añadan hechos, causalidad, juicio o cambio de personaje; luego realiza las reescrituras locales necesarias; no elimines mecánicamente palabras, prohibas estructuras gramaticales, cambies la estructura de este artículo ni lo reescribas como un comunicado de prensa estándar.

En tareas de borrador inicial y reescritura, si encuentras problemas, puedes modificarlos directamente; en revisión, primero da sugerencias. Una vez activada la protección de la versión final, no modifiques directamente el cuerpo, excepto para corregir errores tipográficos autorizados explícitamente por el usuario.

Antes de generar la versión final, las imágenes o el HTML para WeChat, utiliza cada una de las dos memorias para una autoverificación: la de texto verifica la longitud de las oraciones, el lenguaje coloquial, la eliminación, las listas y el olor a IA; la visual verifica el tipo de imagen, el recorte, el montaje, la composición de la portada y la maquetación. Si no hay una preferencia promocionada, no inventes una.

El cierre debe retomar la apertura y la motivación del autor, indicar la capacidad o conclusión actual, el ámbito de aplicabilidad e inaplicabilidad, los elementos aún no verificados y la acción natural. La llamada a la acción (CTA) debe ser como una invitación, no exijas "me gusta", "sígueme" o "comparte" de forma forzada.

Auto-evolución ligera

Cuando se cumpla alguna de las siguientes condiciones, considera la versión actual como final y ejecuta la auto-evolución ligera antes de que finalice esta tarea, sin esperar una nueva confirmación del usuario:

• El usuario la llama explícitamente "versión final", "versión de publicación", "texto final", "versión final adoptada" o "ya terminé de editarlo";
• Una tarea de escritura ha completado simultáneamente la entrega de imágenes y el HTML copiable para WeChat.

Lee completamente Reglas de auto-evolución antes de ejecutar. Solo aprende de las diferencias reales entre el borrador anterior del modelo y la versión final editada por el usuario; distingue secuencialmente entre eliminación, reescritura, adición y conservación tal cual; la conservación tal cual se considera fijamente como texto del asistente y no debe convertirse en evidencia de preferencia del usuario. Utiliza un script para generar un ID de versión final anónimo estable y actualiza la memoria a través de un registro de señales persistente; las reglas textuales solo se almacenan en Memoria de estilo del autor, las reglas visuales solo en Memoria de preferencias visuales. Cada vez, como máximo, añade o corrige 2 reglas abstractas; si el usuario dice "no aprendas esta vez", salta el paso.

Flujo de trabajo condicional

• Cuando el usuario solicite maquetación de versión final o "sin cambiar contenido", lee completamente Maquetación con contenido congelado. Solo ejecuta scripts/verify_content_preservation.py si el usuario solicita explícitamente "verificar que el contenido esté completamente sin cambios"; no conviertas la verificación en un paso predeterminado de cada entrega.
• Cuando el usuario necesite maquetación copiable para WeChat, vista previa o borrador en el backend, lee completamente Maquetación en línea y borrador para WeChat. Mantén los flujos de renderizado, verificación y backend existentes; detente después de guardar el borrador; la publicación, el envío masivo, la revisión o el envío programado requieren una autorización explícita adicional.
• Cuando el usuario necesite generar, reescribir, revisar o hacer bilingüe un README de GitHub, lee completamente Método para GitHub README. Si el chino es el idioma principal del repositorio, usa por defecto README.md + README_EN.md; ambas deben tener enlaces relativos en la parte superior para cambiar de idioma; la versión en inglés debe reescribirse según los hábitos de los desarrolladores de habla inglesa, no traducirse palabra por palabra. Después de generar los archivos, ejecuta scripts/validate_readme_pair.py; si solo se está revisando y no se modifican archivos, no lo ejecutes.

Principios de entrega

Entrega lo que el usuario solicite. La tabla de hechos, la tarjeta de estrategia, la tabla de avance narrativo y el plano de imágenes se pueden generar internamente para garantizar la calidad, pero no se muestran todos por defecto; solo entrega el cuerpo, el título, el resumen, el HTML, las imágenes u otros productos finales que el usuario haya solicitado, así como las explicaciones necesarias que afecten la seguridad de la publicación. El cuerpo no debe mezclarse con notas de revisión, etiquetas de hechos, recordatorios de elementos pendientes ni descripciones de imágenes; si se necesita una versión anotada, crea una copia aparte. Los comentarios de terceros se atribuyen de forma natural en el cuerpo.

No inventes hechos, datos, comentarios, experiencias, resultados ni citas; no conviertas consejos médicos, legales, psicológicos o de relaciones en garantías; la licencia se basa en el archivo real del repositorio. No generes, solicites, leas ni guardes credenciales de WeChat, ni extiendas "guardar borrador" a publicación.

Al modificar este Skill, lee completamente Escenarios de prueba y realiza pruebas ligeras según el alcance del cambio; no ejecutes por defecto pruebas de entrega de WeChat, Word, imágenes o backend.