w3c-technical-reports
SolidDraft, restructure, or audit specification-style technical reports using an independently expressed reference-only interpretation of W3C editorial guidance. Use for protocols, standards, interoperability documents, conformance requirements, and technical specifications that must separate normative requirements from explanation and define precise, testable behavior without inventing requirements.
Install
Quality Score: 83/100
Skill Content
Details
- Author
- Neeeophytee
- Repository
- Neeeophytee/agent-stylebooks
- Created
- 3 weeks ago
- Last Updated
- 2 weeks ago
- Language
- Python
- License
- MIT
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
technical-writing
Write, revise, or review substantial technical documentation and design artifacts for a defined reader and task. Use for READMEs, guides, tutorials, how-to documentation, reference material, runbooks, RFCs, ADRs, technical specifications, and implementation plans. Use a design workflow first when future behavior or architecture needs exploration. Use unslop, when available, for small style-only edits. Do not use for code-only work, routine messages, release notes, PR descriptions, commit messages, or verbatim text.
longform-document-design
Design prose-first technical documents — RFCs, design docs, architecture decision records, specifications, postmortems, runbooks, and technical proposals — as self-contained HTML with clear structure, cross-references, footnotes, and clean print output. Use when writing or restructuring a design doc, RFC, ADR, spec, postmortem, or proposal; when a long technical document is hard to navigate or review; or when prose needs a consistent hierarchy, citation, and print treatment. Do not use for metric-led or data-driven reports (use analytical-document-design), for slides (use presentation-design), for standalone charts or diagrams, or for end-user product documentation and tutorials.
create-technical-design-document
Use to turn product and system understanding into a technical design document - context, detailed design per component, data and API design, cross-cutting concerns, environments (preview/development/production), alternatives considered, and ADR candidates.