agent-readable-docs
Skill6 starsChanged 4 months agoApache-2.0View on GitHub
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.
In this repository116 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- skills/graphify/references/CLAUDE.mdCLAUDE.md
- agent-config-security-auditSkill
- agent-harness-designSkill
- agent-runtime-patternsSkill
- agent-session-forensicsSkill
- ai-regression-testingSkill
- ai-slop-cleanerSkill
- api-doc-reviewSkill
- architecture-decision-recordsSkill
- architecture-simplificationSkill
- ask-claudeSkill
- ask-codexSkill
- ask-geminiSkill
- autonomous-delivery-pipelineSkill
- baseline-comparison-reviewSkill
- bigquery-cost-auditSkill
- brainstormingSkill
- browser-automation-safetySkill
- bug-huntSkill
- build-fix-minimal-diffSkill
- canonical-advisor-routingSkill
- change-impact-checkSkill
- changelog-generatorSkill
- ci-failure-readoutSkill
- codebase-migration-batchesSkill
- context-compressionSkill
- context-docsSkill
- context-minimizationSkill
- context-retrieval-loopSkill
- data-qualitySkill
- dataset-split-reviewSkill
- dbt-incremental-strategy-auditSkill
- dbt-preflightSkill
- dbt-strategySkill
- dead-code-removalSkill
- defuddleSkill
- dependency-cleanupSkill
- deploy-pipeline-runbookSkill
- dispatching-parallel-agentsSkill
- doc-consistency-checkSkill
- environment-doctorSkill
- experiment-tracking-reviewSkill
- failure-triageSkill
- filesystem-mcp-guardrailsSkill
- finishing-a-development-branchSkill
- flaky-test-investigationSkill
- gh-address-commentsSkill
- github-ci-failure-triageSkill
- graphifySkill
- handoff-disciplineSkill
- hard-won-skill-extractorSkill
- hook-safety-reviewSkill
- incident-readoutSkill
- incremental-migrationSkill
- json-canvasSkill
- local-rag-mcpSkill
- log-driven-diagnosisSkill
- managed-codebase-contextSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. About 0 are common, 11 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Read all [SPEC] blocks before responding to any HADS-related request.
- Very specific: line 14
Read [NOTE] blocks if you need context on intent or edge cases.
- Distinctive: line 24
Every HADS document requires: H1 title, version declaration, AI manifest
- Distinctive: line 45
No nesting of blocks inside blocks
- Distinctive: line 83
When encountering a HADS document:
- Very specific: line 85
Read all [SPEC] blocks — these are ground truth
- Very specific: line 86
Read all [BUG] blocks — always, before generating any code or config
- Very specific: line 87
Read [NOTE] blocks only if [SPEC] is insufficient to answer the query
- Very specific: line 88
Treat [?] content as hypothesis — note uncertainty in response
- Distinctive: line 97
When asked to write documentation in HADS format:
- Distinctive: line 99
Start with header block (title, version, metadata)
- Distinctive: line 100
Add AI manifest — always include, never skip
- Distinctive: line 109
Prefer bullet lists over prose
- Distinctive: line 110
Prefer tables for multi-field facts
- Distinctive: line 111
Prefer code blocks for syntax, formats, examples
- Distinctive: line 115
Always include: symptom, cause, fix
- Very specific: line 120
When converting existing documentation to HADS: extract facts into [SPEC], move narrative and history to [NOTE], surface all known issues …
- Distinctive: line 131
All block tags bold
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Human-AI Document Standard (HADS)
AI READING INSTRUCTION
This skill teaches the agent 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 block in header
- AI manifest section before first content section
- Content sections (H2), subsections (H3)
4. HOW AI 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 TO GENERATE 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 in header
- AI manifest before first content section
- All block tags bold
[BUG]blocks contain at minimum symptom + fix
7. DESIGN INTENT
[NOTE] HADS exists because AI models increasingly read documentation before humans do. The format optimizes for this reality without sacrificing human readability.
Key insight: the AI manifest is the core innovation. It lets the model know what to read and what to skip — without requiring it to reason about document structure. Explicit is better than implicit for model consumption.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

