docs-setup

Bootstrap the _docs directory for: $ARGUMENTS

$ARGUMENTS can include:

• Project name / author name (e.g. "Alan Hirsch", "non-profit-dashboard")
• Audience description — who the _public docs ultimately serve (e.g. "board of directors", "ministry leaders", "course participants")
• Voice reference — the author skill to use for _public content (e.g. "alan-voice", "custom") — defaults to checking for a local alan-voice skill
• "audit" — scan an existing _docs directory and report which files should move where, without writing anything
• "migrate" — run the audit, then move files into the correct structure
• Empty — ask the user for project name and audience before proceeding

Purpose

Every project in this environment produces two fundamentally different kinds of documentation. This skill makes that distinction structural and permanent from day one.

_docs/_build/ is the agent's workbench. It contains everything a Claude agent or developer needs to build and maintain the project: the type safety chain, design system docs, engineering runbooks, agent architecture, and generated prompts. This directory is finite — it grows only when the architecture grows, not when research accumulates. Files here are precise and technical. They are not written for an outside audience.

_docs/_public/ is the project's intellectual capital. It captures everything discovered, synthesized, or proposed during the build: research facts, analytical insights, and concrete proposals. This directory grows throughout the project's life. Files here are written for three simultaneous audiences: the Claude agent (precise and queryable), the human developer (actionable and contextual), and the core project audience (narrative and in the author's voice). The goal is that any document in _public/ could — with minimal formatting — become a published article, board briefing, or resource page.