create-pr

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 closing reference 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 closing reference: leave empty — never expose the internal link.
  • CHANGELOG: no entry for internal-devel-requests issues.
• Public — any other repo (e.g. https://github.com/wazuh/wazuh-dashboard/issues/1434):
  • PR ## Description closing reference: 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 + typecheck + 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        # current (feature) branch
git log --oneline origin/main..HEAD 2>/dev/null | head   # sanity: what's new

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:

repo-specific (wazuh-dashboard): live version bases include main, the 4.14.x line, 5.0.0, 5.0.1, and 6.0.0.

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 + typecheck on changed files, tests for touched code). 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-dashboard): the Wazuh user-facing changelog is CHANGELOG.md at the repo root — maintain it by hand. The changelogs/fragments/*.yml system is inherited upstream OSD tooling (fragments there track upstream OpenSearch PRs, not Wazuh changes). For a Wazuh change, add the CHANGELOG.md entry.

Entry style — keep it short and user-facing: one line, phrased from the user's perspective (e.g. "Fixed X causing Y", "Added support for Z"). Never a paragraph, and never internal implementation detail, file names, or jargon.

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.

When unsure (and the issue is public), add an entry.

5. Fill the PR body

Read .github/pull_request_template.md and fill it in verbatim — every section and checklist item lives in that file; this skill does not restate them here. Fill each section with real content and check the boxes that genuinely apply. For the ## Description closing reference, follow the "Issue source" rule above (public issue → Closes #<n>; internal-devel-requests → leave it out).

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 user impact)
- 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.