Avinava
UserA design system for documents — analytical reports, diagrams, charts, decks, and long-form specs as self-contained HTML. Five Claude Code skills over one semantic token contract.
Categories
Indexed Skills (7)
brand-theme-design
Turn a brand into a working theme for this design system — from a screenshot, a website, a PDF brand guide, a style guide, or a handful of hex values. Use when asked to match a company's brand, apply brand colors or brand guidelines to documents, make reports look like an existing site or product, build a theme from a logo or screenshot, or fill in the brand-template slot; and when an existing theme needs its contrast, accent, or print behavior audited. Do not use for choosing between the themes that already ship (that is a one-line answer in core/tokens.md), for restyling a single document rather than creating a reusable theme, or for general visual design of a report, diagram, chart, or deck — those belong to the skill for that artifact.
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.
analytical-document-design
Design evidence-led analytical documents from structured data — executive reports, portfolio reviews, operational audits, inventory analyses, compliance summaries, metric dashboards, and standalone self-contained HTML reports. Use when turning a CSV, inventory, export, or metric set into a professional document; when asked to show where usage, cost, or risk is concentrated; when a report needs clear metric semantics, reconciled totals, accessible charts, and clean print/PDF output; or when an existing dashboard needs to be made defensible rather than merely decorated. Do not use for a single standalone chart (use chart-design), a slide deck (use presentation-design), a prose-first document such as an RFC or spec (use writing-documents), an application UI, or a transactional product dashboard.
chart-design
Design honest, accessible charts of quantitative data as inline SVG — bar and column charts, line and time series, limit ledgers, distributions, scatter plots, and small multiples. Use when visualizing measured values, choosing a chart type, picking or fixing chart colors, building a categorical palette from design tokens, setting axes and scales, labelling series, or making an existing chart readable in grayscale and in print. Do not use for diagrams of structure or process such as architecture or flows (use diagram-design), for the surrounding report narrative and metric semantics (use analytical-document-design), or for interactive dashboards that require a client-side charting library.
diagram-design
Design editorial-quality diagrams as self-contained inline SVG — architecture diagrams, flows, sequences, state machines, data models, timelines, layer stacks, quadrants, comparisons, and system maps. Use when explaining how a system is arranged, how a process moves, how components depend on each other, or how options compare; when a Mermaid or draw.io diagram needs to be converted into a document's design system; or when an existing diagram looks auto-generated and needs editorial judgment. Do not use for quantitative charts of measured data (use chart-design), for the surrounding report structure (use analytical-document-design), for UI mockups or wireframes, or for producing editable .drawio files.
presentation-design
Design presentation decks as self-contained 16:9 HTML slides that export cleanly to PDF — board updates, project reviews, findings readouts, proposals, and conference talks. Use when building a deck, slides, a presentation, or a leadership readout; when converting a report or a set of findings into slides; or when an existing deck needs a coherent visual system and a clean PDF export. Do not use for documents meant to be read rather than presented (use analytical-document-design or writing-documents), for a single standalone chart or diagram, or when the user specifically needs an editable .pptx file.
writing-documents
Write structured technical documents — design-doc, adr, spec, api-contract, architecture, handoff, design-handoff, discovery, test-report, postmortem, proposal, runbook, onboarding, tutorial, how-to, reference, explanation, mulesoft — as Markdown in the repo by default. Use when asked to write or restructure one of those types, including RFCs, ADRs, developer handoffs, API writeups, test summaries, discovery briefs, or MuleSoft project docs. Produce designed HTML or PDF only when asked. Do not use for casual edits to existing markdown, metric-led reports (analytical-document-design), slides (presentation-design), standalone charts or diagrams, restyling a file into HTML unprompted, or Mule markdown refresh when mule-docs is installed.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.