// Update user-facing documentation when code changes. Use when asked to update docs, review docs, handle documentation changes, run scheduled documentation tasks, or analyze recent commits for documentation needs.
Generate reproducible analysis artifacts — SQL queries, Python visualizations, and summary tables — as you work through a BigQuery data analysis. Use when asked to conduct a deep dive, exploratory analysis, or investigation that goes beyond a simple data lookup.
Provide a lookup index of dbt models (BigQuery tables) to guide query writing against a data warehouse. Use when you need to query, analyze, or look up data in a dbt-powered data warehouse, or when resolving a vague data question into the right BigQuery tables to query.
Diagnose and fix GitHub Actions CI failures. Inspects workflow runs and logs, identifies root causes, implements minimal fixes, and pushes to a fix branch. Use when CI is failing, red, broken, or needs diagnosis.
Create a GitHub pull request following project conventions. Use when the user asks to create a PR, submit changes for review, or open a pull request. Handles commit analysis, branch management, and PR creation using the gh CLI tool.
Triage GitHub bug reports for actionability. Use when evaluating whether a bug issue has sufficient detail and identifying missing information from the reporter.
Detect duplicate GitHub issues using semantic search and keyword matching. Use when asked to find duplicates, check for similar issues, or set up automated duplicate detection.
| name | docs-update |
| description | Update user-facing documentation when code changes. Use when asked to update docs, review docs, handle documentation changes, run scheduled documentation tasks, or analyze recent commits for documentation needs. |
| license | MIT |
Automatically review code changes and update user-facing documentation to keep it synchronized with the codebase. Works across documentation platforms (Mintlify, Docusaurus, GitBook, Fumadocs, etc.) and supports both monorepo and multi-repo setups.
Determine which commits need documentation updates:
Filter for significant changes:
Skip documentation for:
Be conservative: quality over quantity. When in doubt about significance, skip the update.
Locate documentation:
Identify documentation platform: Determine the platform by examining configuration files and directory structure (e.g., Mintlify, Docusaurus, GitBook, Fumadocs, or generic markdown).
Understand documentation style: Read several existing documentation files to identify tone, voice, structure, code example patterns, terminology, and formatting conventions. Check for style guides or contribution documentation.
Map code changes to documentation needs (new content, modifications, or additions to existing content).
Guidelines:
Match existing style:
Testing mode (when user asks to "see what would change"):
Output a text summary describing:
Execution mode (when running as automation):
Create a descriptive branch name (e.g., docs/auto-update-YYYYMMDD)
Make documentation changes to appropriate files
Commit with descriptive message listing the changes
Co-Authored-By: Warp <agent@warp.dev>Push branch and create PR with description linking to relevant commits:
When source code and documentation are in separate repositories, identify changes in the source repo, then switch to the docs repo and follow the workflow above. Reference source commits in the PR description.