Create Pr

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 ## 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-dashboard-plugins/issues/8760):
  • 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        # 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:

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, tests for touched plugins). 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-plugins): the changelog is CHANGELOG.md at the repo root. Group with an existing entry if the PR continues a previously merged feature.

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

Fill .github/pull_request_template.md verbatim (keep every heading exactly) — read it first, don't inline its sections here.

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 the issue at all (see "Issue source" above). UI changes require evidence under ### Results and Evidence.

That closing keyword is not just prose — it is what creates the actual GitHub "linked pull request" reference on the issue, for public issues, which is exactly what shows up in the PR's own "Development" section on the issue's GitHub UI page. Verified directly: a PR opened with Closes #9052 in its description showed up in issue #9052's timeline as a ConnectedEvent, and the PR's closingIssuesReferences listed the issue — both immediately on open, and independent of the PR's base branch (this repo's PRs target version branches like 5.0.0, not the default branch, and the link still forms). Internal-devel-requests issues intentionally get no link this way, since no issue reference is exposed in their PR body at all — that is the expected privacy trade-off, not a gap to fix.

There is no REST or GraphQL API to create or manage this link directly — a documented, still-open gap in GitHub's public API. The closing keyword above is the supported mechanism this skill uses. The only other way to populate the Development section is to link a branch to the issue before opening the PR (via the GitHub UI, or gh issue develop <issue-number>) — any PR later opened from that branch is auto-linked regardless of its description text. That's a heavier workflow change (branch creation, not just PR body text) and isn't what this skill does today; it's noted here only as the alternative to reach for if a closing keyword alone is ever insufficient (e.g. it gets edited out of the PR description later).

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
- Assignee: <user> (via --assignee @me)
- Command to open it: gh pr create --draft --base <base> --assignee @me ...

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 \
  --assignee @me

--assignee @me assigns the PR to the person doing the work. Don't rely on repo automation to do this implicitly — it may not exist in every repo this skill is reused in. If the PR was already created without it, fix it with gh pr edit <pr-number> --add-assignee @me.

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.