hads
Helps your agent create documentation readable by humans and AI. It's useful for optimizing technical texts and ensuring AI models understand the content.
What it does
This tool helps organize technical documents so both humans and artificial intelligence (AI) can understand them easily. It uses a special format called HADS to separate important facts, context, and known issues.
When to use it
- ✓When writing technical documentation that needs to be clear for humans and AIs.
- ✓When converting existing documents to the HADS format.
- ✓When optimizing documents for AI to read more efficiently.
Example of what to ask your AI
“Convert this manual into HADS format, separating facts, context, and known bugs.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
The AI reads the document and identifies specific blocks marked with [SPEC] for facts, [NOTE] for context, and [BUG] for issues. It uses these markers to understand and process the information in an organized way.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add wshobson/agents --skill hadsOr download just the file:
curl -L https://raw.githubusercontent.com/wshobson/agents/main/plugins/documentation-standards/skills/hads/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
HADS Claude Skill
Version 1.0.0 · Human-AI Document Standard · 2026 · HADS 1.0.0
AI READING INSTRUCTION
This skill teaches Claude how to read, generate, and validate HADS documents.
Read all [SPEC] blocks before responding to any HADS-related request.
Read [NOTE] blocks if you need context on intent or edge cases.
1. WHAT IS HADS
[SPEC]
- HADS = Human-AI Document Standard
- Convention for Markdown technical documentation
- Four block types:
**[SPEC]**,**[NOTE]**,**[BUG]**,**[?]** - Every HADS document requires: H1 title, version declaration, AI manifest
- AI manifest appears before first content section, tells AI what to read/skip
- File extension:
.md— standard Markdown, no tooling required
2. BLOCK TYPES
[SPEC]
**[SPEC]** Authoritative fact. Terse. Bullet lists, tables, code. AI reads always.
**[NOTE]** Human context, history, examples. AI may skip.
**[BUG]** Verified failure + fix. Required fields: symptom, cause, fix. Always read.
**[?]** Unverified / inferred. Lower confidence. Always flagged.
Block tag rules:
- Bold, on its own line:
**[SPEC]** - Content follows immediately (no blank line between tag and content)
- Multiple blocks of different types allowed per section
- Titled BUG blocks allowed:
**[BUG] Short description** - No nesting of blocks inside blocks
3. REQUIRED DOCUMENT STRUCTURE
[SPEC]
# Document Title
**Version X.Y.Z** · Author · Date · [metadata]
---
## AI READING INSTRUCTION
Read `[SPEC]` and `[BUG]` blocks for authoritative facts.
Read `[NOTE]` only if additional context is needed.
`[?]` blocks are unverified — treat with lower confidence.
---
## 1. First Section
**[SPEC]**
...
Required elements in order:
- H1 title
**Version X.Y.Z**in header (first 20 lines)- AI manifest section before first content section
- Content sections (H2), subsections (H3)
4. HOW CLAUDE READS HADS
[SPEC] When encountering a HADS document:
- Find and read the AI manifest first
- Read all
[SPEC]blocks — these are ground truth - Read all
[BUG]blocks — always, before generating any code or config - Read
[NOTE]blocks only if[SPEC]is insufficient to answer the query - Treat
[?]content as hypothesis — note uncertainty in response
Token optimization: for large documents, scan section headings first, then read only [SPEC] and [BUG] blocks in relevant sections.
5. HOW CLAUDE GENERATES HADS
[SPEC] When asked to write documentation in HADS format:
- Start with header block (title, version, metadata)
- Add AI manifest — always include, never skip
- Organize content into numbered H2 sections
- For each fact: write as
[SPEC]— terse, bullet or table or code - For each "why" or context: write as
[NOTE] - For each known failure mode with confirmed fix: write as
[BUG] - For each unverified claim: write as
[?] - End with changelog section
Content rules for [SPEC]:
- Prefer bullet lists over prose
- Prefer tables for multi-field facts
- Prefer code blocks for syntax, formats, examples
- Maximum 2 sentences of prose — if more needed, move to
[NOTE]
Content rules for [BUG]:
- Always include: symptom, cause, fix
- Optional: affected versions, workaround
- Title on same line:
**[BUG] Short description**
[NOTE]
When converting existing documentation to HADS: extract facts into [SPEC], move narrative and history to [NOTE], surface all known issues as [BUG]. Do not duplicate content between block types.
6. VALIDATION RULES
[SPEC] A valid HADS document must have:
- H1 title
**Version X.Y.Z**in first 20 lines- AI manifest before first content section
- All block tags bold:
**[SPEC]**not[SPEC]not [SPEC] [BUG]blocks contain at minimum symptom + fix
Validator: (planned — not yet included in this release)
7. EXAMPLE INTERACTIONS
[SPEC]
User: "Write HADS documentation for this REST API" → Generate full HADS document: header, manifest, sections with [SPEC]/[NOTE]/[BUG] blocks
User: "Convert this README to HADS format" → Restructure existing content into HADS blocks, preserve all facts, add manifest
User: "Is this document valid HADS?" → Check: H1 title, version, manifest, block tag formatting, BUG block completeness
User: "Summarize this HADS document" → Read only [SPEC] and [BUG] blocks, return structured summary
User: "What does this API do?" (HADS doc provided)
…
FAQ
What are the [SPEC], [NOTE], and [BUG] blocks?
[SPEC] contains important, direct facts. [NOTE] provides additional context, like examples or history. [BUG] describes known failures and how to fix them.
Why use the HADS format?
HADS makes documentation clearer for AIs, which often read it before humans do. This ensures the AI understands essential information without getting lost in details.
What is the 'AI manifest'?
It's an instruction at the beginning of the document that tells the AI exactly which parts to read (like [SPEC] and [BUG]) and which it can skip (like [NOTE], unless more context is needed).
Details
Original description by the author
Use when writing technical documentation that needs to be readable by both humans and AI models, converting existing docs to HADS format, validating a HADS document, or optimizing documentation for token-efficient AI consumption.
repo: wshobson/agents
Popularity
- GitHub stars
- 41k
- Ranking position
- #4859
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
screen-reader-testing
Has your agent test websites using screen readers to ensure they are accessible.
wshobson/agents
wcag-audit-patterns
Helps your agent audit websites for accessibility and fix issues according to WCAG guidelines.
wshobson/agents
multi-reviewer-patterns
Enables your agent to coordinate parallel code reviews, deduplicating findings and consolidating reports.
wshobson/agents
parallel-debugging
Allows the agent to debug complex issues with parallel investigations and root cause analysis.
wshobson/agents
Similar skills
architecture-decision-records
Has your agent record important project structure decisions. It helps to understand the reasoning behind choices and maintain a clear history of changes.
affaan-m/ECC
code-tour
Lets your agent create step-by-step code walkthroughs with exact file and line anchors. It's useful for project introductions, code explanations, or change reviews. Helps understand how a system works.
affaan-m/ECC
codebase-onboarding
Helps your agent analyze unfamiliar code and create an onboarding guide. It includes an architecture map, entry points, and conventions. Ideal for starting on a new project.
affaan-m/ECC