docs

Detect new platform error codes in warp-server that are missing documentation pages in the docs repo. Creates doc pages, astro.config.mjs (sidebar config) entries, and redirects for any gaps. Use on a weekly schedule or when error codes change.

Sync the public Oz Agent API OpenAPI spec from warp-server into the docs repo, regenerating `developers/agent-api-openapi.yaml` (the file that powers the Scalar API reference at `docs.warp.dev/api`). Use when the warp-server public API has changed, when the Scalar reference looks stale, or on a scheduled cadence to keep the public API docs aligned with the canonical spec.

Sync the Warp terminology glossary from the Notion Dictionary to the repo. Fetches the Notion Dictionary page, compares with .warp/references/terminology.md, and opens a PR for any additions or changes. Flags repo-only terms that are missing from Notion. Use on a weekly schedule or manually when terminology changes.

Update the public changelog at docs.warp.dev/changelog with the latest stable release. Fetches changelog data from channel-versions, formats a new entry, and opens a PR. Use after a stable release ships (typically Fridays).

Audit docs.warp.dev for agent-friendly documentation issues using the AFDocs scorecard. Checks llms.txt, markdown availability, content negotiation, page size, URL stability, and content structure. Use when asked to check agent readiness, run an AFDocs audit, improve the docs score, or verify llms.txt and markdown support.

Run weekly release docs updates with standalone scripts for changelog, licenses, and telemetry, plus Linux/Oz Warp artifact preparation. Defaults to running all tasks in order, and supports running only selected tasks.

Find and fill documentation gaps in Warp's Astro Starlight docs by auditing coverage against code surfaces in the public warp client repo and warp-server, then drafting missing pages. Use when asked to find missing docs, audit documentation coverage, identify undocumented features, draft docs for new features, detect doc-impacting code changes since the last audit, or do a docs coverage check. Runs a Python audit script (coverage + snapshot-based change detection), then researches source code and writes first-pass doc pages. Can run audit-only, draft-only, drift-watch (recurring agent), or end-to-end.

Monthly outer loop agent that reads accumulated signal logs from agent-authored PRs and proposes targeted improvements to the drafting skills and templates. Part of the docs self-improvement loop architecture. Use when asked to run the drafting improvement loop, or as a scheduled monthly cloud agent.

Run a narrow AEO cross-link audit for Warp docs using Peec, Google Search Console, and existing docs. Use for recurring or scheduled agents that should identify high-confidence internal cross-linking improvements for agents, cloud agents, and orchestration docs.

Check the Warp Astro Starlight documentation for broken links by scanning source markdown files. Run the diagnostic script, review the output, fix broken links, and optionally notify Slack.

Monthly outer loop agent that reads the aeo_crosslink_audit run log and proposes targeted improvements to the aeo_crosslink_audit skill itself. Part of the docs self-improvement loop architecture. Deploy after at least 8 entries exist in the run log (roughly month 3 of aeo_crosslink_audit operation).

Scan Warp Astro Starlight documentation for style guide violations including formatting issues (Settings path format, UI element format, link quality, VideoEmbed titles, header case, missing frontmatter, image alt text, standardized screenshot widths, callout syntax) and terminology issues (product name casing, Oz terms to avoid, deprecated terms). Run with --changed for PR workflows or --all for periodic audits. Optionally auto-fix high-confidence issues with --fix.

Scan Warp Astro Starlight documentation for UI menu paths and Command Palette command names, then validate them against the warp-internal codebase for accuracy. Catch and surface outdated steps automatically.

Weekly recurring agent that surfaces broken docs.warp.dev URLs by querying the docs_404 Rudderstack track event, diffing against existing vercel.json redirects, and posting a summary to Slack. Use for the Monday 9am PT scheduled Oz agent that monitors 404 gaps and supports the ongoing redirect-fix workflow.

Draft a new guide page for the Guides section (src/content/docs/guides/). Use for practical, task-oriented walkthroughs that help developers accomplish a specific goal — like setting up a tool, completing a workflow, or learning a technique. Guides focus on the "how" with real prompts and reproducible results, targeting non-branded search queries.

Create a pull request in the docs repository for the current branch. Use when the user mentions opening a PR, creating a pull request, submitting changes for review, or preparing documentation for merge.

Draft new Warp documentation pages or update existing ones using established style conventions, with optional source code context from warp-internal and warp-server.

Reviews documentation pull requests for the Warp docs repository. Checks for broken links, style guide compliance, content quality, AEO/source-data fit, and Astro Starlight structure. Use when reviewing documentation PRs or when you need to provide feedback on markdown documentation changes.

Answer questions about Warp, Oz, agents, terminal features, billing, pricing, troubleshooting, privacy, skills, MCP, integrations, or any other Warp-related topic. Use when a user, support person, or engineer asks a question that can be answered from Warp's documentation. Searches the docs, synthesizes a comprehensive answer, and provides links to relevant doc pages.

Audit docs.warp.dev for SEO issues like duplicate titles, missing meta descriptions, title length problems, and H1 tag issues. Crawls the live sitemap, generates a report, and fixes issues in the source files. Use when asked to check SEO, fix duplicate titles, audit meta tags, improve search rankings, or run an SEO check on the docs site.

Draft a new conceptual documentation page or update an existing one. Use for pages that explain what something is, why it exists, and how it works — without step-by-step procedures. Examples include product overviews, architecture explanations, and design philosophy pages.

Draft a new feature documentation page or update an existing one. This is the most common page type in Warp's docs (~75+ pages). Feature docs combine conceptual content (what a feature is and how it works) with procedural content (step-by-step usage instructions) in one page.

Draft a new procedural documentation page or update an existing one. Use for task-oriented, step-by-step instructions that help a reader accomplish a specific goal. Examples include configuring an integration, creating an API key, or setting up an environment.

Draft a new quickstart documentation page or update an existing one. Use for first-time experiences that get the reader to a working result fast (~10 minutes). Quickstarts focus on the critical path with minimal prerequisites and link to deeper guides for edge cases.

Build a source-grounded AEO brief for Warp docs using Peec data, existing docs, and product terminology. Use whenever a docs request mentions AEO, answer-engine optimization, SEO visibility, Peec recommendations, AI search prompts, content gaps, search-query vocabulary, or deciding whether to create new docs versus update existing docs.

Repo-specific triage guidance for the Warp docs repo. Only the categories declared overridable by the core triage-issue skill may be specialized here.

Fix agent-friendly documentation issues found by the afdocs-audit skill. Reads the AFDocs audit report and applies automated fixes for failing checks. Use after running the afdocs-audit skill, or when asked to fix AFDocs issues, improve the agent-ready score, or remediate llms.txt / markdown availability problems.

Draft a new FAQ documentation page or update an existing one. Use for pages that collect frequently asked questions about a topic area. Questions are written in the user's voice and grouped by theme.

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 a new troubleshooting documentation page or update an existing one. Use for known issues, common errors, and diagnostic guides. Troubleshooting pages follow a problem → cause → solution format, leading with the symptom the user sees.