| name | create-pr |
| description | Prepare a standardized pull request for a Wazuh Dashboard repository (verify version base branch, DCO sign-off, CHANGELOG entry, run local checks, and produce a ready-to-paste PR body with a pre-flight report). By default it prepares and hands off; it only runs `gh pr create` when explicitly asked. Use when the user asks to create, open, draft, or prepare a PR, or to get work ready for review. |
Prepare a Wazuh Dashboard pull request
Standardized PR flow shared across all Wazuh Dashboard repositories. The body is
generic; blocks marked repo-specific are the only parts to adjust when reusing
this skill in another repo.
Default behavior: prepare and hand off. Do the full pre-flight (steps 1–5) and
output the ready-to-paste PR body plus a pre-flight report, so the human reviews
and opens the PR. Only run gh pr create (step 6) when the user explicitly asks
you to create/open/submit it.
Golden rules (do not skip)
- Open as Draft first. CI is configured to skip Draft PRs, so iterate freely
while in Draft and only trigger CI when the work is validated.
- Base branch = the version branch the work started from (e.g.
5.0.0,
6.0.0), which is not always main. Never guess — confirm it.
- Every commit must be DCO-signed (
git commit --signoff).
- Validate locally before "Ready for review" using the
check-standards skill.
- English everywhere. Describe the why, not just the what.
- Issues arrive as URLs and may live in a different repo. Read them with
gh issue view <url> and classify the source (see below) — it changes both
the PR's ## Description and the CHANGELOG.
Issue source: public vs internal
Detect the source repo from the issue URL:
- Internal — the URL/repo contains
internal-devel-request (e.g.
https://github.com/wazuh/internal-devel-requests/issues/5526):
- PR
## Description: do not reference the issue — never expose the
internal link.
- CHANGELOG: no entry for internal-devel-requests issues.
- Public — any other repo (e.g.
https://github.com/wazuh/wazuh-security-dashboards-plugin/issues/123):
- PR
## Description: Closes #<n> (same repo) or Closes <issue-url>
(another public repo).
- CHANGELOG: add an entry linking to the issue (see step 4).
repo-specific: the internal repo is wazuh/internal-devel-requests; match
it by the substring internal-devel-request in the URL.
Workflow
Copy this checklist and track progress:
- [ ] 1. Confirm branch, base branch, and clean/committed state
- [ ] 2. Verify commits are DCO-signed
- [ ] 3. Run check-standards (lint + format + tests) and fix failures
- [ ] 4. Add/confirm CHANGELOG entry (or justify the exception)
- [ ] 5. Fill the PR template body + emit the pre-flight report ← default stop here
- [ ] 6. (Only if explicitly asked) Create the PR as Draft with gh
- [ ] 7. (Only if explicitly asked) Mark Ready for review when everything passes
1. Confirm branch and base
git rev-parse --abbrev-ref HEAD
git log --oneline origin/main..HEAD 2>/dev/null | head
Feature branch naming: <type>/<issue#>-<kebab-description> where <type> ∈
fix, bug, enhancement, feat, feature, change, doc, documentation.
To find the base version branch, list candidates and pick the one the branch
diverged from; if ambiguous, ask the user rather than defaulting to main:
git branch -r | grep -E 'origin/(main|[0-9]+\.[0-9]+)'
2. Verify DCO sign-off
git log <base>..HEAD --format='%h %s%n%(trailers:key=Signed-off-by)'
Every commit needs a Signed-off-by: trailer. If missing, re-commit with
--signoff (or git rebase adding sign-off) before continuing.
3. Validate locally
Invoke the check-standards skill (prettier + eslint on changed files, then
yarn test:jest_ui). Do not proceed to "Ready for review" until it passes.
4. CHANGELOG entry
Add one entry under the upcoming version, in the correct section
(Added / Changed / Fixed / Removed). The link points to the issue, not
the PR.
repo-specific (wazuh-security-dashboards-plugin): the changelog is
CHANGELOG.md at the repo root, grouped under a
## [v<x>] heading with ### Added / ### Changed / ### Fixed / ### Removed
subsections. A "Prior versions" list links older tags. Group with an existing
entry if the PR continues a previously merged feature. (Many historical entries
link to PRs; for new work, prefer the issue link.)
Skip the entry entirely when:
- The issue is from internal-devel-requests (internal request → no changelog).
- The PR is internal-tooling / docs-only / test-only / dependency-bump with no
user-facing impact — add the
no changelog label to the PR instead.
When unsure (and the issue is public), add an entry.
5. Fill the PR body
Read .github/PULL_REQUEST_TEMPLATE.md
and fill it verbatim (keep every heading and checklist item exactly) — do
not inline or restate its sections here; that file is the single source of
truth. Screenshots/videos (REQUIRED for any UI change) go under
### Results and Evidence; test notes go under ### Tests Introduced /
### How to Test.
Fill each section with real content; check the boxes that genuinely apply. In
## Description: public issue → closing keyword (Closes, Fixes, Fix)
with #<n> or the full issue URL; internal-devel-requests issue → do not
reference it (see "Issue source" above).
Default deliverable — pre-flight report. Unless the user asked you to create the
PR, stop here and output the filled body plus this report for the human to act on:
PR pre-flight
- Feature branch: <name>
- Suggested base: <version-branch> (confirm before creating)
- Commits DCO-signed: yes / no (missing: <hashes>)
- check-standards: PASS / FAIL (<summary>)
- Issue source: public (<url>) / internal-devel-requests (link withheld)
- CHANGELOG: entry added (links to issue) / not needed (internal / `no changelog`)
- UI change: yes → evidence attached? / no
- Command to open it: gh pr create --draft --base <base> ...
6. Create as Draft — only when explicitly asked
Write the body filled in step 5 (not the blank template) to a temp file, then
pass that file — never point --body-file at the template path itself, or the
PR is created with the empty placeholder text.
gh pr create --draft \
--base <version-branch> \
--title "<Imperative, capitalized subject>" \
--body-file /tmp/pr-body.md
7. Mark Ready for review — only when explicitly asked
Only after check-standards passes and evidence is attached:
gh pr ready <pr-number-or-url>
Then move the linked issue to "Pending review". Prefer squash merge for
single-purpose PRs.
Notes
- Do not force-push shared branches; to address review feedback, push new commits
and re-request review.
- Do not weaken auth/CSP/security and never commit secrets.
