blog

Par chorus-aidlc · chorus

Rédigez des billets de blog de lancement pour Chorus — narration axée sur le problème, bilingue (zh/en), en suivant le style éditorial du projet.

npx skills add https://github.com/chorus-aidlc/chorus --skill blog

Article de Blog Chorus

Rédigez des articles de blog bilingues (zh/en) pour le site de destination Chorus.

Prérequis

  • Vous savez quelle version / fonctionnalité documenter (l'utilisateur vous le dira, ou vérifiez le CHANGELOG / git log récent)
  • Les articles existants se trouvent dans packages/landing/src/content/blog/
  • Convention de nommage : zh-chorus-vX.Y.Z-release.md (Chinois), chorus-vX.Y.Z-release.md (Anglais)

Style éditorial

Ces règles viennent du propriétaire du projet. Respectez-les strictement.

Structure narrative

  1. Ouvrez par le problème du lecteur, pas par la fonctionnalité. Ne commencez pas par « nous avons lancé X ». Commencez par le problème que le lecteur vit. Décrivez le scénario de manière vivante pour qu'il se reconnaisse dedans.
  2. Une ligne pour présenter la solution. Une fois que le problème est posé, dites en une phrase ce que cette version fait.
  3. Détaillez les mécanismes de soutien. Expliquez les couches / briques de base qui font fonctionner la solution. Ordonnez-les par le flux que l'utilisateur vit, pas par importance.
  4. Le contexte industriel comme preuve à l'appui, pas en ouverture. S'il y a des tendances industrielles pertinentes (par exemple, nouveaux outils d'Anthropic, fonctionnalités concurrentes), référencez-les pour valider la direction. Mais ils viennent au milieu ou en fin de section, jamais en tête.
  5. Convergez vers une conclusion. Remettez les pièces ensemble. La chute doit reprendre le problème d'ouverture : « c'est pourquoi vous pouvez maintenant faire X ».

Ton et voix

  • Ne parlez pas pour le lecteur. N'écrivez jamais « vous pensez probablement X » ou « vous ressentez certainement Y ». Décrivez la situation, laissez les lecteurs s'y identifier d'eux-mêmes.
  • Décontracté, pas corporate. Écrivez comme vous l'expliqueriez à un collègue avisé, pas comme un communiqué de presse. Pas de langage marketing, pas d'adjectifs de remplissage.
  • Pas de tirets cadratin (——) en chinois. Utilisez plutôt des virgules, des points ou des ruptures de phrase.
  • Le chinois doit sonner comme du chinois. Pas comme du texte traduit de l'anglais. Rythme parlé, tournures naturelles.
  • L'anglais doit sonner comme de l'anglais. Pas comme du texte traduit du chinois. Préférez les phrases courtes et percutantes. Évitez « materialize », « leverage », « utilize » — utilisez des mots simples.
  • La cohérence logique compte. Le propriétaire détectera immédiatement les contradictions. Si vous dites « nous avions X dès le départ », assurez-vous que c'est vrai. Si quelque chose a été ajouté dans une version spécifique, dites-le.
  • Pas de remplissage. Si une phrase suffit, ne l'étirez pas sur trois.

Titre

  • Incluez le numéro de version : Chorus vX.Y.Z : <hook>
  • Le hook est le vrai titre. Il devrait donner envie de cliquer.
  • Peut mélanger chinois et anglais, utiliser l'argot, être ludique.
  • Exemples :
    • « Chorus v0.6.1 : 你的时间比 Token 贵,/yolo it! »
    • « Chorus v0.6.0 : 给你的 Agent 团队派个监工 »

Frontmatter

---
title: "Chorus vX.Y.Z: <hook>"
description: "<1-2 phrases, formulées comme une question ou une provocation, pas un résumé>"
date: YYYY-MM-DD
lang: zh  # ou en
postSlug: chorus-vX.Y.Z-release
---
  • description doit accrocher le lecteur, pas résumer l'article. Une question ou un défi fonctionne bien.
  • postSlug doit être identique pour les versions zh et en afin qu'elles se lient ensemble.

Étapes

1. Rassemblez le contexte

# Trouvez l'entrée CHANGELOG de la version
# Lisez les commits récents si nécessaire
# Lisez le code de la fonctionnalité pertinente / docs des skills pour comprendre ce qui a été construit

Comprenez la fonctionnalité en profondeur avant d'écrire. Lisez le code, la documentation des skills, les descriptions de PR. N'écrivez pas à partir de résumés seuls.

2. Rédigez d'abord la version chinoise

Écrivez zh-chorus-vX.Y.Z-release.md. Le chinois est la version primaire, pas une traduction.

Présentez le brouillon à l'utilisateur pour examen. Attendez-vous à plusieurs cycles de retours sur :

  • La structure narrative (ce qui vient en premier, ce à couper)
  • Le ton (trop raide, trop corporate, trop présomptueux)
  • La cohérence logique
  • Le titre et la description

NE PROCÉDEZ PAS à la version anglaise tant que la version chinoise n'est pas approuvée.

3. Rédigez la version anglaise

Écrivez chorus-vX.Y.Z-release.md. Ce n'est PAS une traduction littérale. Réécrivez pour un public anglophone :

  • Même structure et arguments
  • Formulation naturelle en anglais et rythme
  • Adaptez les métaphores et références qui ne franchissent pas les frontières linguistiques

4. Checklist d'auto-révision

Avant de présenter chaque version :

  • [ ] S'ouvre par le problème, pas par l'annonce de fonctionnalité
  • [ ] Ne parle pas pour le lecteur (« vous pensez probablement... »)
  • [ ] Pas de tirets cadratin dans la version chinoise
  • [ ] Pas de relent de traduction dans aucune des deux langues
  • [ ] Le titre a un numéro de version + hook
  • [ ] La description est un hook, pas un résumé
  • [ ] Tous les faits sont exacts (quelle version a introduit quoi)
  • [ ] Pas de contradictions logiques entre les sections
  • [ ] Pas de paragraphes de remplissage — chaque section mérite sa place
  • [ ] postSlug correspond entre les versions zh et en

Skills similaires