arbe-documentation

Writes and restructures user-facing documentation using the Diátaxis four-mode framework.

Updated May 16, 2026
One-click install
npx skills add https://github.com/oskarrough/robots --skill arbe-documentation-oskarrough
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: arbe-documentation
Source: https://github.com/oskarrough/robots/tree/main/skills/documentation
Command: npx skills add https://github.com/oskarrough/robots --skill arbe-documentation-oskarrough

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Documentation often mixes tutorials, how-tos, references, and explanations into one confusing page, or drifts out of sync with the code it describes. This Skill enforces the Diátaxis four-mode separation and provides concrete rules for keeping docs accurate, terse, and maintainable. ## Core Features & Use Cases - Four-mode separation: Keeps tutorials, how-tos, references, and explanations distinct so each doc serves one reader need. - Altitude rules: Docs map the code's wiring and rationale instead of duplicating signatures, flags, and constants that the source already owns. - Design doc skeleton: Provides a reusable template (problem, requirements, invariants, non-goals) for concepts shared across tasks. - Cut patterns: Identifies and fixes common doc smells like migration narration, task IDs in prose, and self-defending paragraphs. - Use Case: When restructuring a project's docs folder, apply this Skill to split a bloated guide into a tutorial, a how-to, and a reference page, then prune stale claims that no longer match the code. ## Quick Start Rewrite the attached onboarding guide as a Diátaxis tutorial, moving theory into a linked explanation doc and cutting any stale claims.

Frequently Asked Questions about arbe-documentation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure documentation using the Diátaxis framework?▼

Diátaxis splits docs into four modes: tutorials for learning by doing, how-tos for solving problems, references for describing what exists, and explanations for building understanding. Keep each doc in one mode and link between them instead of mixing.

What is the difference between a tutorial and a how-to guide?▼

A tutorial teaches through doing with one guaranteed path and visible progress, aimed at learners. A how-to solves a specific problem for a competent reader, titled from their point of view, and links to explanation docs for theory.

Should documentation duplicate function signatures and CLI flags?▼

No. Docs should map how pieces wire together and why, while naming the code paths that own the detail. Signatures, flags, and constants live in the source; copying them into docs creates drift when code changes.

When should I write a design doc instead of a regular doc?▼

Write a design doc when a concept needs shared reference across multiple tasks. Cover one concept per doc with problem, requirements, invariants, and explicit non-goals, concrete enough to implement without clarification.

What should I do when documentation and code disagree?▼

Fix the code or update the doc, but never silently drift the doc to match reality. Read the current doc and the code it covers, update only what changed, and remove stale claims while keeping structure that still works.