# Create Pr > 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. - Skill: `wazuh/create-pr-3` (Agent Skill) - Install (CLI): `npx skillmds@latest add wazuh/create-pr-3` - Raw SKILL.md: https://api.skillmd.com/api/skills/wazuh/create-pr-3/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: wazuh (https://skillmd.com/u/wazuh) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/wazuh/create-pr-3 --- # 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 ` 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 #` (same repo) or `Closes ` (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 ```bash 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: `/-` where `` ∈ `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`: ```bash git branch -r | grep -E 'origin/(main|[0-9]+\.[0-9]+)' ``` ### 2. Verify DCO sign-off ```bash git log ..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`](../../../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`](../../../.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 `#` 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 `) — > 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: - Suggested base: (confirm before creating) - Commits DCO-signed: yes / no (missing: ) - check-standards: PASS / FAIL () - Issue source: public () / internal-devel-requests (link withheld) - CHANGELOG: entry added (links to issue) / not needed (internal / `no-changelog`) - UI change: yes → evidence attached? / no - Assignee: (via --assignee @me) - Command to open it: gh pr create --draft --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. ```bash gh pr create --draft \ --base \ --title "" \ --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 --add-assignee @me`. ### 7. Mark Ready for review — only when explicitly asked Only after check-standards passes and evidence is attached: ```bash gh pr ready ``` 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.