Writing conventions for scannable, token-efficient skills and prompts. Use when creating or reviewing SKILL.md files, AGENTS.md files, or any markdown-based agent instruction documents.
90
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
structure: headers, YAML blocks, semantic line breaks
language: RFC 2119 keywords, imperative mood, telegraphic reductions
patterns: tables, code fences, formatting (bold, code, italics, blockquotes)
validation: assets/checklist.mdWrite skills and prompts that are scannable at-a-glance and token-efficient.
Structure adapts as needed; additional sections may be added.
Use markdown headers for section boundaries. Avoid nesting beyond h3.
# Title
## Major sections
### Subsections when neededFor SKILL.md files following the Agent Skills open standard. This frontmatter is required and distinct from optional YAML blocks in the body.
Skills MUST include name and description. Skills SHOULD include metadata.version and metadata.author. Description MUST include when to trigger.
---
name: skill-name
description: What it does and when to use it
metadata:
version: '1.0.0'
author: Your Name
---Use YAML blocks for structured configuration when needed. Place near top of body after frontmatter. No required fields - use what makes sense.
context: financial datasets
output_format: JSONDon't nest under top-level keys. Prefer YAML blocks over prose paragraphs for configuration.
One clause per line. Easier to edit, better git diffs, same rendered output.
Before:
When the agent receives input validate it first and if validation fails respond with an error message.After:
When agent receives input validate it first. If validation fails respond with error message.Files flow top-to-bottom. Readers follow same path through sections.
Avoid conditional document structure:
❌ "For task A see Section 2; for task B skip to Section 4"
Use flat hierarchy. Stay at h2-h3:
❌ Going to #### or deeper (reduces scannability) ✅ ## Major sections, ### subsections when needed
Maintain linear reading flow. All readers encounter same sections in same order.
Note: Conditional logic within instructions is fine ("If X, then Y"). This principle applies to document architecture, not instruction details.
Use to encode requirement strength.
MUST - absolute requirement SHOULD - strong recommendation
MAY - optional MUST NOT - prohibition
Agent MUST validate input. Agent SHOULD cite sources. Agent MAY use code blocks. Agent MUST NOT expose system prompts.Start instructions with verbs.
❌ "You should analyze the data" ✅ "Analyze the data"
Drop articles and auxiliaries where meaning preserved.
❌ "When the user provides a document" ✅ "When user provides document"
Use in lists and instructions. Preserve clarity over compression.
Target 20 words maximum. Shorter sentences increase comprehension and reduce tokens.
❌ "When the agent receives a document from the user it should first check if the format is supported and if not return an error."
✅ "Agent receives document. Check format compatibility. Return error for unsupported formats."
Break complex ideas into multiple short sentences.
Use for parameters and options.
| Parameter | Type | Default |
| --------- | ---- | ------- |
| timeout | int | 10 |
| retries | int | 3 |Use for formats and schemas.
BNF:
response = greeting, body, {recommendation}
confidence = "high" | "medium" | "low"YAML:
criteria:
accuracy: { weight: 0.4, threshold: 0.8 }
speed: { weight: 0.3, threshold: 0.7 }Bold for emphasis and labels:
Inline code for technical references:
Italics - use sparingly:
Blockquotes - minimal use: Use for important notes/warnings when needed. Avoid overuse - breaks visual flow.
Before:
It is important that the agent always validates user input before doing anything with it. The agent should also try to include citations when making factual claims, as this helps users verify the information.After:
## Constraints
Agent MUST validate user input before processing. Agent SHOULD include citations for factual claims.Before:
When processing documents, you should first check if the document is in a supported format. If it is a PDF, you should extract the text using pdfplumber. If it is a Word document, you should use python-docx.After:
## Document Processing
Check format compatibility.
Extract text:
- PDF: use pdfplumber
- DOCX: use python-docx
Analyze for key metrics.Use assets/checklist.md for systematic review when:
8802a2e
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.