Skip to main content

draft-reference

Draft a new reference documentation page or update an existing one. Use for structured factual information meant for lookup — CLI commands, API endpoints, configuration options, keyboard shortcuts, error codes. Reference pages describe and only describe.

Datos de origen

Repositorio
warpdotdev/docs
Última actividad en el origen
6 de octubre de 2026 a las 05:43
Idioma detectado de SKILL.md
inglés
Estrellas
44
Forks
27

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
draft_reference
description
Draft a new reference documentation page or update an existing one. Use for structured factual information meant for lookup — CLI commands, API endpoints, configuration options, keyboard shortcuts, error codes. Reference pages describe and only describe.
# Draft reference page Draft a reference documentation page with structured, exhaustive information for developer lookup. ## Workflow Follow the workflow in `.agents/skills/draft_docs/SKILL.md`, using the **reference template** at `.agents/templates/reference.md`. ## Frontmatter description One to two sentences, 50-160 characters, saying what the reader can look up. Name the artifacts, not the genre. - ✅ `Look up Warp Agent CLI flags, environment variables, slash commands, and keyboard shortcuts.` - ❌ `Reference documentation for the Warp Agent CLI.` See "Descriptions by content type" under Frontmatter in `AGENTS.md` for the full rules. ## Content type rules These rules are specific to reference pages (from the "Drafting by content type" section of `AGENTS.md`): - Be exhaustive — document every option, flag, and configuration value. - Use consistent formatting for parameters (e.g., `--flag` in backticks, description as a dash-separated list item). - Alphabetize entries where ordering doesn't matter. - Keep descriptions factual and concise — this is for lookup, not learning. - Include at least one practical example for each command or endpoint. - **Adopt standard patterns ruthlessly** — consistency is more important than style. Every entry must follow the same structure. - Structure should mirror the structure of the product it describes. - Use H2 for sections, H3 for subsections. Tables for multiple elements, lists for single. - Title convention: noun describing contents ("Keyboard shortcuts", "CLI commands") ## Heading case All headings (H1–H4) must use **sentence case**: capitalize only the first word and proper feature names. - ✅ `# CLI commands` - ✅ `## Running agents` - ❌ `# CLI Commands` - ❌ `## Running Agents` ## Existing examples Read 2-3 of these strong examples to match the existing pattern: - `agents/cli/oz-cli/index.mdx` - `factories/api-and-sdk/index.mdx`
Ver en GitHub