jarvis-doc-author

Solid

Authoritative skill for writing internal Personal-Jarvis docs under ``docs/`` and sibling directories. Enforces a Diataxis-compliant classification (concept/how-to/tutorial/reference/troubleshooting/adr), a uniform YAML frontmatter schema, a style canon (active voice, imperative instructions, English prose), and hard anti-patterns (no quadrant mixing, no filler intros, no "Click here"). Use when writing or fundamentally reworking any Markdown doc under ``docs/``.

AI & Automation 30 stars 11 forks Updated today MIT

Install

View on GitHub

Quality Score: 88/100

Stars 20%
50
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Jarvis Doc Author When a Jarvis doc is written, the rule is: **classify first, then structure, then phrase, then self-check.** Not the other way around. This skill provides the scaffolding. It does not replace thinking — it enforces the discipline that separates a pile of internal Markdown files from a *real* doc layer (role models: Kubernetes doc site, Docker manuals, GitHub Docs). ## When to trigger Activate this skill when the user (via voice or chat) or a Sub-Jarvis explicitly or implicitly wants to write a **new doc** or **structurally** rework an existing doc. Concrete examples: - "Schreib ein Doc ueber den BrainManager-Routing-Discipline-Mechanismus." (Write a doc about the BrainManager routing discipline mechanism.) - "Leg ein ADR an fuer die Sub-Jarvis-Hard-Cap-Entscheidung." (Create an ADR for the Sub-Jarvis hard-cap decision.) - "Dokumentiere wie man einen neuen Brain-Provider hinzufuegt." (Document how to add a new brain provider.) - "Fass die Phase-6-Ergebnisse als Test-Report zusammen." (Summarize the Phase 6 results as a test report.) - "Mach mir eine How-To fuer das Voice-Bridge-Setup." (Create a how-to for the voice-bridge setup.) - A Sub-Jarvis receives the task from the main Jarvis "schreib das in ``docs/...`` rein" (write this into ``docs/...``) — then the Sub-Jarvis consults this skill before writing. Do NOT trigger on: - Code comments, docstrings, type hints — those follow the CLAUDE.md rule (code identifiers in English), but need no doc s...

Details

Author
PersonalJarvis
Repository
PersonalJarvis/PersonalJarvis
Created
2 months ago
Last Updated
today
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

skill-creator

Creates new Jarvis skills and iteratively improves existing ones. Activates when the user wants to build a new skill ("erstell einen skill fuer X" / "create a skill for X" / "mach aus diesem Workflow einen Skill"). No auto voice trigger — the Supervisor dispatches this skill on an intent basis.

30 Updated today
PersonalJarvis
AI & Automation Listed

doc-standards

Documentation writing-quality standards — controlled language (ASD-STE100), Google/Microsoft style guide rules, ISO 24495 plain language, AI/agent readability (llms.txt, self-contained sections), and a machine-checkable lint gate. Use whenever writing or reviewing ANY documentation prose — README, API reference, tutorial, how-to, changelog, error message, code comment blocks, llms.txt — even if the user only says "write docs", "document this", "improve the README", "docs smell like AI", or "make the docs clearer". Structure/coverage questions (which doc types exist) belong to a Diátaxis-structure skill if one is installed; THIS skill governs how each sentence and section is written, and provides the lint gate to verify it.

13 Updated 1 months ago
JuanMarchetto
AI & Automation Listed

writing-docs

Use when writing, restructuring, or reviewing any prose documentation — a tutorial, how-to guide, reference page, or explanation/conceptual doc — for a public docs site (e.g. Mintlify MDX, docs/, README material), a getting-started guide, an API/CLI reference page, or a "why we built it this way" conceptual page. Applies the Diátaxis framework (see https://diataxis.fr/) — every document belongs to exactly one of the four quadrants (tutorial / how-to guide / reference / explanation), and mixing quadrants inside one document is the single most common documentation failure. Covers the four-quadrant compass for picking the right form, per-quadrant structure templates, an anti-pattern list for quadrant drift, and generic voice/craft rules — repo-specific voice and target output format (e.g. Mintlify MDX) are resolved from the repo's docs-manifest (falling back to project-context), never hardcoded here.

3 Updated 1 weeks ago
whimzyLive