readme-constructor

Constructeur de README

Construisez un README qui correspond au projet et à ses lecteurs. Considérez l'utilisateur comme le designer. Les préréglages sont des propositions ; la structure, le contenu et les visuels sont des choix indépendants. Utilisez les preuves du projet et les décisions déjà prises par l'utilisateur. N'inventez jamais de fonctionnalités, commandes, résultats, images ou affirmations.

Découvrir et proposer

Inspectez le référentiel pertinent, la documentation existante, la source de la documentation générée et les actifs avant de proposer une recette. Identifiez le but, le public cible, le titre, le ton et la cible de rendu du README lorsque ceux-ci affectent la conception. Respectez un chemin de sortie demandé ou un brouillon uniquement dans le chat. Modifiez la source de documentation lorsque la sortie est générée. Préservez les faits utiles et les actifs existants, en particulier pour un README existant.

Utilisez les menus ci-dessous de manière sélective. Leurs modèles offrent des choix que l'utilisateur peut adapter. Leurs exemples liés sont un sous-ensemble représentatif sélectionné à partir de l'index Awesome README, résumé en notes originales courtes. Aucun accès réseau n'est requis pour utiliser ce skill.

• Utilisez le menu de structure pour proposer un point de départ ordonné et des choix de sections.
• Utilisez le menu de contenu des sections pour choisir le format, la profondeur et les preuves pour chaque section sélectionnée.
• Utilisez le menu des visuels pour choisir des visuels individuels, leur emplacement et les actifs disponibles ou proposés.

Pour un nouveau README ou une refonte majeure, présentez une recette unique, adaptée et modifiable, montrant l'ordre des titres proposé, un choix de contenu pour chaque section et les visuels placés individuellement. Incluez des choix de contexte brefs uniquement là où ils restent importants. Dans un menu compact, utilisez des identifiants stables afin que l'utilisateur puisse ajouter, supprimer, renommer ou réorganiser les sections, choisir leur contenu indépendamment et opter pour des visuels individuels. Proposez none, keep, skip, recommend et des choix libres le cas échéant. Expliquez que recommend délègue le choix. Laissez l'utilisateur décider du contenu et des visuels indépendamment d'un préréglage.

Consommez les choix que l'utilisateur a déjà donnés et conservez-les lors de la révision de la recette. Lorsque keep sélectionne un élément existant dans une refonte, préservez et appliquez cet élément. Ne demandez que les choix de conception non résolus, regroupés dans un message gérable. Attendez ces choix avant de rédiger un nouveau README ou une refonte substantielle, sauf si l'utilisateur a délégué les décisions. Si l'utilisateur a donné des instructions suffisantes ou vous a demandé de décider, procédez avec des valeurs par défaut appropriées. Une fois les choix résolus, produisez la livrable demandée sans demander une nouvelle approbation. Pour les modifications étroites, exécutez directement la demande de l'utilisateur sans nouvelle session du constructeur.

Adaptez cet échange compact au projet.

L'ordre proposé est S1 Présentation → S2 Démarrage rapide → S3 Architecture. Les choix de contenu sont S1 problème + portée, S2 commandes minimales et S3 plan de composants en texte brut. Les choix visuels sont V1 capture d'écran après S1 (proposée, aucun actif disponible) et V2 schéma d'architecture après S3 (proposé). Choisissez les sections et l'ordre, modifiez le contenu de n'importe quelle section et choisissez les visuels individuellement. keep accepte la valeur spécifique proposée, none supprime une section ou un visuel, skip laisse de côté un choix facultatif et recommend délègue le choix. Le texte personnalisé est le bienvenu.

L'utilisateur choisit ordre S1, S3, S2 / S2 guidé / V1 none / V2 keep / keep le reste.

La recette résultante conserve le contenu de S1 et S3, utilise un démarrage rapide guidé pour S2, omet V1 et place V2 après S3. Résolvez toute incertitude matérielle restante sans rouvrir les choix acceptés. Distinguez les actifs proposés des actifs existants. Créez ou obtenez un actif proposé uniquement dans le cadre de la demande de l'utilisateur et des outils disponibles, ou omettez-le et expliquez l'écart.

Produire et vérifier

Rédigez les sections selon la recette choisie et étayez les spécificités du projet. Vérifiez les commandes en toute sécurité lorsque c'est pratique. Étiquetez les commandes non vérifiées ou les informations manquantes, et évitez d'exécuter des commandes destructrices ou ayant des effets secondaires uniquement pour tester la documentation. Vérifiez l'ordre des titres et les liens, les ancres, le rendu Markdown pour la plateforme choisie, les blocs de code et les balises de langage, ainsi que les chemins d'accès relatifs aux actifs. Donnez un texte alternatif informatif aux images significatives et vérifiez la lisibilité dans les thèmes clair et sombre lorsque des visuels sont utilisés. Préservez le contenu existant en dehors du champ demandé. Signalez les lacunes matérielles et les limites de vérification avec le résultat.