Stats
Actions
Tags
From agentdocs
Author and validate HTML-first, agent-readable documentation following The Source-Complete Standard. Use when creating or updating repository docs (architecture, subsystem contracts, API references, data models, UI/wireframe specs, runbooks, or the docs front-door index) that AI agents are meant to read, or when checking existing HTML docs for conformance. Triggers on intents like "write agent-readable docs", "document this for agents", "source-complete HTML docs", "validate these docs against the standard", "faceted data-* tags", "data-source/data-verified provenance", "CSS-only tabs", "front-door index".
How this skill is triggered — by the user, by Claude, or both
Slash command
/agentdocs:agentdocsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Author and validate documentation in **The Source-Complete Standard**: one static,
Author and validate documentation in The Source-Complete Standard: one static, HTML-first file that serves AI agents first and humans second, with no view-time JavaScript and no content duplication.
The full standard is bundled at reference/STANDARD.md. This
file is the operating manual; open the reference when you need exact rule text or the
governance model. Read reference/STANDARD.md once before
your first author or validate run in a session.
Hold these in mind for every operation — they are the whole standard in miniature:
.html source, never a
browser-rendered snapshot. State this in the front-door index.<script> executes at view time; nothing is fetched to reveal content. (Author-time
build tools are fine — "no-runtime" ≠ "no-build".)data-*/class facets at once (from a governed vocabulary), so it surfaces under many
views with no copy and no cross-link.data-source (the path#Lx-Ly a region shadows) +
data-verified (date last checked) is the single trust mechanism for freshness,
diagrams, and examples.Plus the structural rule: one shared toolkit + exactly one specialized construct per doc type.
Use when creating or updating a doc.
Identify which type you are writing and the single specialized construct it requires
(full matrix in reference/doc-type-constructs.md):
| Doc type | Reader-job | Specialized construct |
|---|---|---|
| Front-door index | Locate | Typed links with triage payload (summary + axis tags + data-job + data-cost) |
| Architecture overview | Locate→Comprehend | Inline SVG with <title>/<desc> |
| Subsystem contract | Comprehend | <details> regions + provenance primitive |
| API reference | Comprehend→Act | Schema table (data-field, data-type, data-calls) |
| Data model | Comprehend | Schema table (data-pk, data-fk) + inline SVG ER |
| UI / wireframe spec | Act | Annotated skeletal form (data-field, data-action, data-shows-when) |
| Ops / runbook | Act | Ordered landmarks + <details> per step + data-source to scripts |
| Canonical example | Act | Static example pinned via data-source to a CI-tested file |
Include the shared toolkit plus exactly one construct. Zero, or two, fails conformance.
Copy templates/standard.html and adapt it. It already
demonstrates: semantic landmarks, five faceted tags on one region, CSS-only <details name>
tabs, a schema table, an inline SVG with <title>/<desc>, a provenance-pinned example,
and an annotated skeletal form. Keep its <head> comment that tells agents how to read the file.
<nav>, <main>, <section>, <article>, real headings. One job per section.data-*/class from the governed vocabulary
(reference/facet-ontology.md). Use existing facets; extend
values, never invent new facets ad hoc. Tags go inline on the element, never in a
JSON-LD <script> block.data-source="path/to/file#Lx-Ly" and data-verified="YYYY-MM-DD" on
every trust-bearing region (anything that shadows code). Use today's date for
data-verified only when you actually checked the region against the source.<details name="view"> + a ::details-content
rule. CSS only. The content stays in the source whether collapsed or open.Pre-rendered inline SVG with authored <title> + <desc> and a data-source. Or ship
Mermaid source text in a <pre>. Never render Mermaid at view time.
Add or update the doc's entry in the front-door index (index.html): a one-line summary, its
axis tags, data-job, and a data-cost size hint. Ensure the index states the consumption
contract. If no index exists, create one (it is itself a doc type — see the matrix).
Run Workflow B on what you just wrote before declaring it done.
Use when checking an existing .html doc (or one you just authored).
Run the checklist in reference/conformance-checklist.md
against the file and report each item as PASS / FAIL / N-A with the offending line for any FAIL.
The hard gates:
<script> elements; no inline on*= handlers; no javascript: URLs.<details> content is present in source.data-*/class facets are from the governed vocabulary; values
controlled; carried inline (not JSON-LD).data-source and data-verified.<title>/<desc>, or shipped Mermaid source — never view-time rendered.Report format: a short table of gate → verdict → note, then a one-line overall verdict (CONFORMS / DOES NOT CONFORM) and the top fixes.
Carry these as TODO; do not silently invent answers:
reference/facet-ontology.md are
candidates. When a needed facet/value is missing, propose it and flag it, don't assume it.reference/STANDARD.md — the full standard (authoritative).reference/facet-ontology.md — facet governance + candidate vocabulary.reference/doc-type-constructs.md — toolkit + per-type construct matrix.reference/conformance-checklist.md — the validation checklist.templates/standard.html — the conforming exemplar to copy.npx claudepluginhub george4data/agentic_html_doc --plugin agentdocsProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.