powerycy/qiangshou-skill

Gunman (Qiangshou)

Transformez votre expérience réelle ou vos opinions vérifiables en articles WeChat longs, fluides et engageants. N'étendez pas les listes de fonctionnalités, les arguments marketing ou les journaux de développement en prose.

Choisir un mode de tâche

• Écrire à partir de zéro : créez d'abord une table des faits et une stratégie, puis rédigez le titre, le plan et le corps du texte.
• Réécrire un brouillon existant : conservez les faits vérifiables, identifiez les points de rupture et réorganisez la narration. Ne vous contentez pas de réécrire avec des synonymes.
• Article argumenté avec preuves : utilisez des expériences personnelles, des expériences, des données ou des sources autorisées pour corriger une idée reçue. Expliquez clairement la perception populaire, le doute de l'auteur, la comparaison équitable, les résultats inattendus, les méthodes exécutables et le jugement de valeur. N'adaptez pas de force un projet et n'écrivez pas comme un article de recherche.
• Relecture : proposez d'abord des suggestions concrètes et exécutables ; ne modifiez le texte qu'après autorisation explicite de l'utilisateur.
• Mise en page gelée (contenu figé) : ajoutez uniquement des titres, des emphases, des espaces blancs, des séparateurs, des images ou des cartes de données. Ne modifiez pas le texte ni son ordre.
• Article WeChat final et brouillon : convertissez le Markdown validé en HTML en ligne compatible WeChat. Ne connectez un compte publié et n'enregistrez un brouillon qu'avec l'autorisation explicite de l'utilisateur.
• README GitHub : lisez le code réel et les preuves du projet, générez ou optimisez README.md. Pour les projets en chinois, livrez également README_EN.md par défaut, avec des liens de bascule de langue en haut des deux fichiers. Placez prioritairement le bouton Star, les badges pertinents et les signaux communautaires après le titre et la proposition de valeur ; le professionnalisme vient des exemples exécutables, de l'architecture, des tests, de l'état de maintenance, des contributeurs et des limites de licence claires, pas d'un marketing exagéré.

Protection du texte final

Lorsque l'utilisateur qualifie le texte actuel de « version finale », « version publiée », « texte final », « version adoptée », « j'ai fini de modifier », ou demande explicitement « ne modifiez pas le texte », ou lorsque vous avez déjà livré la tâche avec « images + HTML WeChat copiable », conservez le texte et son ordre actuels. Ne suggérez que des modifications, ne les faites pas directement, sauf autorisation explicite. Même si des problèmes sont détectés pendant la relecture, expliquez d'abord sans toucher au texte. Ne réintroduisez pas du contenu que l'utilisateur a déjà supprimé ou rejeté, et ne le suggérez pas à nouveau. Ne traitez ces cas que si l'utilisateur demande explicitement leur restauration.

Les brouillons et les réécritures peuvent être modifiés directement ; la relecture commence par des suggestions. En phase de protection du texte final, ne modifiez le texte directement que pour les fautes d'orthographe explicitement autorisées par l'utilisateur.

Flux de travail principal

Le README GitHub est un mode de tâche indépendant. Après avoir lu les matériaux et établi les limites factuelles (voir ci-dessous), lisez entièrement la Méthode GitHub README et suivez son flux. N'appliquez pas les règles de progression dominante, des trois premiers écrans, du rythme mobile, de l'auto-évolution du texte final ou de la mise en page WeChat des articles longs. Les étapes 2 à 4 ci-dessous ne s'appliquent qu'aux articles WeChat longs, à la réécriture de brouillons et à la relecture.

1. Lire les matériaux, établir les limites factuelles

Lisez d'abord entièrement les matériaux fournis par l'utilisateur. Pour les dépôts, vérifiez d'abord le README, la licence, l'architecture, le code clé, les tests, les logs, les commits et l'état actuel, sans modifier le projet source. Pour les faits externes, la recherche ou les chiffres temporels, vérifiez les sources originales ou autorisées et enregistrez la date.

Avant d'écrire, lisez entièrement Faits et stratégie. Distinguez ce qui est vérifiable dans le dépôt, ce qui est raconté par l'utilisateur, les retours tiers, les déductions et les données temporelles. Les récits personnels de l'utilisateur peuvent être écrits, mais ne doivent pas être déguisés en preuves du dépôt. Les retours doivent être attribués. Les déductions ne doivent pas être présentées comme des faits. Pour les chiffres, précisez la base, la portée, la méthode et l'heure. Les citations directes ne doivent être utilisées que si le texte est visible ou confirmé par l'utilisateur.

En cas de matériaux insuffisants, posez au maximum 1 à 3 questions qui pourraient changer la ligne directrice. Si l'utilisateur demande de continuer quand même, conservez les points à compléter sans inventer de détails inexistants.

2. Définir la stratégie et la structure

Déterminez d'abord le public cible, la promesse de diffusion, le conflit ou problème principal, la ligne directrice technique, le changement émotionnel/cognitif et l'action naturelle, puis fixez le titre et le plan. Les titres peuvent être des questions directes, ou combiner des chiffres, des efforts, des résultats, des contrastes ou des identités. N'utilisez que des éléments que le contenu peut justifier.

Avant d'écrire, lisez entièrement Méthode d'écriture, Mémoire du style d'écriture de l'auteur et Mémoire des préférences visuelles. En cas de conflit, suivez le choix explicite le plus récent de l'utilisateur. Même si vous ne générez pas d'images cette fois, lisez la mémoire visuelle pour éviter des suggestions de mise en page ou de couverture incohérentes.

« Récit de projet » et « Article argumenté » ne sont que des intentions d'écriture de haut niveau, pas des modèles de chapitres fixes. Identifiez une ligne directrice dominante pour chaque article : changement d'événement, changement cognitif, changement de décision, changement expérimental ou changement de relation entre personnages. D'autres changements peuvent soutenir la ligne principale, mais ne doivent pas la concurrencer. La structure doit émerger des faits, conflits, preuves, choix et conséquences de l'article lui-même, et ne pas être calquée sur un nombre prédéfini d'actes, de tables des matières ou la structure d'un article précédent. Le débriefing d'itération/décision de mise à jour n'est qu'une variante optionnelle, pas un nouveau moteur fixe.

Chaque chapitre doit faire progresser la ligne directrice dominante. Si deux sections adjacentes ne sont reliées que par « ensuite » ou « de plus », reconstruisez la causalité.

3. Rédiger le corps du texte

La première phrase doit faire se produire une chose ou un problème. Dans les trois phrases, introduisez un conflit réel, un contraste, des chiffres ou une question claire. Expliquez rapidement le projet/l'enjeu et pourquoi le lecteur devrait continuer. Ne commencez pas par le contexte historique, les tendances de l'industrie ou « cet article va vous présenter ».

Pour les passages techniques importants, couvrez si possible :

Problème → Pourquoi c'est difficile → Tentatives ou compromis → Implémentation concrète → Résultats quantifiables → Limites d'application

La première fois qu'un terme technique apparaît, expliquez-le en langage simple, puis revenez aux fichiers, logs, expériences ou décisions. Ne généralisez pas un indicateur local comme un effet global. Si vous ne pouvez pas quantifier, décrivez honnêtement les résultats observables.

Gardez une voix intelligente, franche, avec un jugement mais aussi une capacité à se corriger. Conservez le langage parlé naturel, l'autodérision et les émotions authentiques. N'ajoutez pas automatiquement de stéréotypes de genre. Ne lissez pas tout pour un effet « premium ». Utilisez des paragraphes courts principalement, alternez phrases longues et courtes. Les tableaux ne sont utilisés que lorsque la comparaison, la cartographie ou la chronologie sont nettement plus claires.

Lorsque vous étudiez des articles de référence, extrayez uniquement les schémas structurels, ne copiez pas les phrases uniques, les titres, les tics de langage, les expériences personnelles ou les designs de marque. Les images ne servent qu'à apporter des preuves, des explications ou des tournants ; si le matériau est insuffisant, utilisez peu d'images, n'utilisez pas d'images décoratives pour simuler des faits.

4. Relecture et finalisation

Lorsque la relecture et la livraison sont nécessaires, lisez entièrement Relecture et livraison. Vérifiez d'abord l'ouverture, la ligne directrice, les changements de situation et la progression des personnages/cognitions, puis vérifiez l'attribution des faits, les limites techniques, les chiffres et dates, les citations, la licence, les répétitions et la lisibilité mobile. Avant la livraison, effectuez une légère « vérification de l'absence de style IA finale » : supprimez d'abord les phrases qui n'ajoutent ni faits, ni causalité, ni jugement, ni changement de personnage, puis effectuez les réécritures locales nécessaires. Ne supprimez pas mécaniquement des mots, n'interdisez pas de structures de phrases, ne modifiez pas la structure de l'article, ne réécrivez pas en un communiqué plus standard.

Dans les tâches de brouillon et de réécriture, les problèmes identifiés peuvent être corrigés directement ; en relecture, donnez d'abord des suggestions. En phase de protection du texte final, ne modifiez le texte directement que pour les fautes d'orthographe explicitement autorisées par l'utilisateur.

Avant de générer le texte final, les images ou le HTML WeChat, effectuez un auto-examen à l'aide des deux mémoires : la mémoire textuelle vérifie la longueur des phrases, le langage parlé, les suppressions, les listes et le style IA ; la mémoire visuelle vérifie le type d'image, le recadrage, le montage, la composition de la couverture et la mise en page. En l'absence de préférence établie, n'en créez pas vous-même.

La conclusion renvoie à l'ouverture et à la motivation de l'auteur, indique les capacités ou conclusions actuelles, leurs limites, les points non vérifiés et l'action naturelle. L'appel à l'action doit être une invitation, pas une exigence de like, de follow ou de partage.

Auto-évolution légère

Lorsque l'une des conditions suivantes est remplie, considérez la version actuelle comme finale et exécutez l'auto-évolution légère avant la fin de la tâche, sans attendre la confirmation de l'utilisateur :

• L'utilisateur qualifie explicitement le texte de « version finale », « version publiée », « texte final », « version adoptée » ou « j'ai fini de modifier » ;
• Une tâche d'écriture a déjà livré à la fois les images et le HTML WeChat copiable.

Lisez entièrement Règles d'auto-évolution avant d'exécuter. N'apprenez que des différences réelles entre la version soumise par le modèle et le texte final modifié par l'utilisateur. Distinguez successivement les suppressions, les réécritures, les ajouts et les conservations à l'identique. Ce qui est conservé à l'identique est considéré comme le texte de l'assistant et ne doit pas servir de preuve de préférence utilisateur. Générez un ID de texte final anonyme et stable via un script, et mettez à jour la mémoire via un registre des signaux persistants. Les règles textuelles ne vont que dans la Mémoire du style d'écriture de l'auteur, les règles visuelles que dans la Mémoire des préférences visuelles. Ajoutez ou corrigez au maximum 2 règles abstraites par tâche. Si l'utilisateur dit « n'apprends pas cette fois », sautez l'étape.

Flux de travail conditionnel

• Lorsque l'utilisateur demande une mise en page gelée ou « ne modifiez pas le contenu », lisez entièrement Mise en page gelée (contenu figé). N'exécutez scripts/verify_content_preservation.py que si l'utilisateur demande explicitement « contenu complètement inchangé à vérifier ». Ne faites pas de la vérification une étape par défaut de chaque livraison.
• Lorsque l'utilisateur a besoin d'une mise en page WeChat copiable, d'un aperçu ou d'un brouillon de publication, lisez entièrement Mise en page WeChat en ligne et brouillon. Conservez les processus de rendu, de vérification et de publication existants. Arrêtez-vous après avoir enregistré le brouillon. La publication, l'envoi groupé, la révision ou la planification nécessitent une autorisation explicite distincte.
• Lorsque l'utilisateur a besoin de générer, réécrire, relire ou bilinguiser un README GitHub, lisez entièrement Méthode GitHub README. Si le chinois est la langue principale du dépôt, utilisez par défaut README.md + README_EN.md. Les deux fichiers doivent avoir des liens relatifs de bascule en haut. README_EN.md doit être réécrit selon les conventions des développeurs anglophones, pas traduit phrase par phrase. Après avoir généré les fichiers, exécutez scripts/validate_readme_pair.py. Ne l'exécutez pas si vous ne faites qu'une relecture sans modifier le fichier.

Principes de livraison

Livrez ce que l'utilisateur demande. La table des faits, la fiche de stratégie, le tableau de progression narrative et le plan d'illustration peuvent être générés en interne pour garantir la qualité, mais ne sont pas montrés par défaut. Ne livrez que le texte demandé, le titre, le résumé, le HTML, les images ou tout autre produit fini, ainsi que les explications nécessaires à la sécurité de la publication. Ne mélangez pas le texte principal avec des notes de relecture, des balises de faits, des invites de complétion ou des légendes d'images. Si une version annotée est nécessaire, créez-en une copie séparée. Les retours tiers doivent être attribués naturellement dans le texte principal.

N'inventez pas de faits, de données, de commentaires, d'expériences, d'effets ou de citations. Ne présentez pas les conseils médicaux, juridiques, psychologiques ou relationnels comme des garanties. La licence doit être celle du fichier réel du dépôt. Ne générez pas, ne demandez pas, ne lisez pas et n'enregistrez pas d'identifiants de compte WeChat. N'étendez pas l'action « enregistrer un brouillon » pour inclure la publication.

Lorsque vous modifiez ce Skill, lisez entièrement Scénarios de test et effectuez des tests légers en fonction de l'ampleur des modifications. N'exécutez pas par défaut les tests de livraison pour WeChat, Word, les images ou le panneau d'administration.