markdown-drafts

Utilisez le format Markdown lors de la rédaction de contenu destiné à des systèmes externes (issues/PR GitHub, tickets Jira, pages wiki, documents de conception, etc.) afin que le formatage soit…

npx skills add https://github.com/cloudflare/workerd --skill markdown-drafts

Markdown Drafts

When the user asks you to draft, write, or compose content that will be copied into an external system — GitHub issues, pull request descriptions, Jira tickets, wiki pages, design documents, RFCs, or similar — always use markdown syntax so that formatting survives the copy-paste.

When This Applies

  • GitHub issues and pull request descriptions
  • Jira ticket descriptions and comments
  • Confluence / wiki page drafts
  • Design documents and RFCs
  • Slack messages (Slack renders a subset of markdown)
  • Any content the user explicitly says will be copied elsewhere

Formatting Rules

  • Use #, ##, ### headers to create structure
  • Use - or * for unordered lists, 1. for ordered lists
  • Use triple-backtick fenced code blocks with language tags (e.g., ```cpp) for code
  • Use inline code backticks for identifiers, file paths, commands, and config values
  • Use **bold** for emphasis on key points and _italic_ for secondary emphasis
  • Use markdown tables when presenting structured comparisons or data
  • Use > blockquotes for callouts, quoted text, or important notes
  • Use [link text](url) for references — never bare URLs in running prose
  • Use --- horizontal rules to separate major sections when appropriate
  • Use task lists (- [ ] / - [x]) when drafting action items or checklists
  • Keep line lengths reasonable (e.g., 80-120 characters)

Structure Guidelines

  • Start with a concise summary paragraph before diving into details
  • Use headers to break content into scannable sections
  • Keep paragraphs short — walls of text are hard to scan in issue trackers
  • Put the most important information first (inverted pyramid)
  • End with next steps, open questions, or action items when relevant

Rendering: Always Emit Raw Markdown

The chat interface renders markdown, which strips the raw syntax (###, **, `, etc.) from the output. Since these drafts are meant to be copied and pasted into external systems, the user needs the raw markup characters preserved.

Always wrap the entire draft in a fenced code block so the chat interface displays it as literal text. Use a plain triple-backtick fence (no language tag):

```
## My Heading

- bullet one
- **bold text** and `code`
```

This ensures the user sees and can copy the exact markdown source. Never render the draft as formatted text outside a code fence — the markup will be silently consumed by the chat UI.

What NOT To Do

  • Do not render the draft as formatted markdown outside a code fence — the user will lose the syntax
  • Do not use plain text formatting (e.g., ALL CAPS for headers, ==== underlines, manual indentation)
  • Do not use HTML tags unless the target system requires them and markdown is insufficient
  • Do not add emoji unless the user's draft style includes them or they explicitly request it
  • Do not use common cliche AI-generated phrases, tropes, or filler content like tricolons, or generic intros/outros. Be concise and to the point.
  • Do not include editorial comments or unsubstantiated claims. Stick to the facts and the user's instructions precisely. If you need to ask clarifying questions, do so instead of making assumptions.

Plus de skills de cloudflare

workerd-api-review
cloudflare
Optimisation des performances, conception et compatibilité des API, vulnérabilités de sécurité et conformité aux spécifications des normes pour la revue de code workerd. Couvre la prise en compte de tcmalloc…
official
workerd-safety-review
cloudflare
Sécurité mémoire, sécurité des threads, concurrence et motifs de détection critiques pour la revue de code workerd. Couvre les risques liés à la frontière V8/KJ, la gestion de la durée de vie,…
official
module-registry
cloudflare
Charger lorsque vous travaillez avec le registre de modules dans workerd — lecture, modification, débogage ou révision de la résolution, compilation, évaluation ou enregistrement de modules…
official
reproduce
cloudflare
Reproduire un problème GitHub cloudflare/agents en créant un projet minimal Agents/Worker et en le déployant sur un compte Cloudflare temporaire, puis signaler…
official
local-explorer
cloudflare
Comment ajouter des produits/ressources à l'explorateur local ou à l'API locale. À utiliser lors de l'implémentation de nouvelles API locales ou de routes d'interface utilisateur sous…
official
commit-categories
cloudflare
Règles de catégorisation des commits pour les journaux de modifications et les résumés "nouveautés". DOIT être chargé avant de catégoriser les commits dans les commandes de journal de modifications ou de nouveautés. Fournit…
official
architecture
cloudflare
Utiliser lors de la première navigation dans la base de code, de l'ajout d'une nouvelle méthode client, de l'ajout d'un nouveau gestionnaire/service de conteneur, ou de la compréhension du flux d'une requête…
official
changesets
cloudflare
À utiliser lors de la création d'un changeset, de la préparation d'une version ou de l'incrémentation des versions. Couvre les packages à référencer, la manière de rédiger les descriptions de changeset destinées aux utilisateurs,…
official