// Create a GitHub pull request for the current branch with a focused why/what body and exactly one release-drafter label. Use when the user asks to open a PR, create a pull request, or ship a branch.
| name | pr |
| description | Create a GitHub pull request for the current branch with a focused why/what body and exactly one release-drafter label. Use when the user asks to open a PR, create a pull request, or ship a branch. |
Creates a GitHub PR with a body focused on why and what, labeled for the release changelog.
Run these to see what the PR contains:
git log main..HEAD --oneline
git diff main...HEAD --stat
git push -u origin HEAD
Use this structure:
## Why
<One or two sentences: the problem, gap, or need this addresses. What would go wrong without this change?>
## What
<What changed, at a meaningful level — not a file list. Think: what does a reviewer need to understand to evaluate this?>
## How (optional)
<Only include this section if a completely new architectural mechanism was introduced that future contributors need to understand at a big-picture level. Skip for normal feature additions, fixes, or refactors — those belong in code comments, not here.>
Do not include bullet lists of changed files. Do not summarize what's already obvious from the diff.
Pick the single best-fit label. Apply it with --label <label>.
| Label | Use when |
|---|---|
breaking | Existing behavior or public API breaks |
feature | New capability that did not exist before |
enhancement | Improves or extends an existing feature |
bug | Fixes a defect in existing behavior |
fix | Alias for bug fix (use bug by preference) |
documentation | Docs-only change (markdown, /docs/ pages) |
chore | Cleanup, refactor, internal restructure — no user-visible change |
dependencies | Dependency version bumps |
automation | CI/CD, GitHub Actions, scripts, build tooling |
ci | Alias for automation (use automation by preference) |
redesign | Frontend visual/structural redesign work |
changelog:skip | Housekeeping with no changelog entry (e.g. typo fixes, config tweaks) |
When in doubt between feature and enhancement: feature = didn't exist, enhancement = existed but got better.
gh pr create --title "<title>" --label "<label>" --body "$(cat <<'EOF'
## Why
...
## What
...
EOF
)"
Always print the PR URL so the user can open it directly.
Stage relevant files and create a well-formed git commit for the docs-builder repo. Use this when the user asks to commit changes, save work, or create a commit.
Auto-fix all formatting issues in the docs-builder repo — runs dotnet format for C# and npm fmt:write for TypeScript/JS. Use when the user asks to fix formatting, lint the code, or when a pre-commit hook fails due to formatting.
Review changed or staged C# code against the docs-builder coding standards and flag violations. Use when the user asks to review code style, check for standards violations, or audit a diff before committing.
Run the relevant tests for what changed — detects whether to run C# unit tests, specific test projects, integration tests, or JS/TS tests based on changed files. Use when the user asks to run tests, verify changes, or check if something is broken.
Search, analyze, and author Elastic documentation using the remote MCP server. Use this when the user asks about Elastic product documentation, features, or APIs; wants to find, read, or verify existing docs pages; is writing or editing documentation; mentions cross-links between repos; asks about documentation structure, coherence, or consistency; wants to generate templates following Elastic content type guidelines; or references elastic.co/docs URLs or Elastic product names.