メニュー
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.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/elastic/docs-builder --skill prコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
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.
SOC 職業分類に基づく
SKILL.md を表示中
| 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.