// 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.
| name | commit |
| description | 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. |
Creates a clean, well-formed commit following the docs-builder project conventions.
Run these in parallel:
git status
git diff
git diff --staged
git log --oneline -5
Stage specific files by name — never git add -A or git add . blindly. Exclude:
.env files or anything with secrets/credentialsRules:
Add async timeout handling to assembler)Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>Always pass the message via HEREDOC to avoid shell escaping issues:
git commit -m "$(cat <<'EOF'
Title here
Optional body explaining why.
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
EOF
)"
This project uses Husky.Net git hooks:
If a hook fails:
/lint if it's a formatting problem)git commit --amend for a failed commit, and never use --no-verifyRun git status after the commit to confirm a clean working tree.
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.
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.
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.
