Issue Creation

Create a Wazuh Dashboard issue

Pick the right issue template, check for duplicates first, then fill the template verbatim and hand off a ready-to-file body.

Workflow

Copy this checklist and track progress:

- [ ] 1. Classify intent → choose issue template (ask only if ambiguous)
- [ ] 2. Issue-first check: search existing issues for duplicates
- [ ] 3. Fill the chosen .github/ISSUE_TEMPLATE/*.md verbatim
- [ ] 4. Apply the real Wazuh label for the intent (`type/bug` / `type/enhancement` / `level/task`) + `untriaged`; ignore stale frontmatter labels
- [ ] 5. Emit the ready-to-file body + report (default stop; gh issue create only if asked)
- [ ] 6. Add to a project board (team board, not the release board) if asked, or ask first if the issue has no linked project

1. Classify intent → choose template

Map the user's intent to a template. Ask the user only when genuinely ambiguous between two rows.

2. Issue-first duplicate check

Before drafting, search for an existing issue covering the same problem:

gh issue list --search "<keywords>"
gh search issues "<keywords>" --repo wazuh/wazuh-dashboard-plugins

On a likely match, surface it to the user and ask whether to proceed with a new issue or comment on the existing one instead.

3. Fill the template

Reference the chosen file under .github/ISSUE_TEMPLATE — read it first and fill it verbatim; do not inline template bodies in this skill.

repo-specific (wazuh-dashboard-plugins): label frontmatter is stale for bug_report.md and feature_request.md (bare bug / enhancement don't exist here — see step 4 for the real labels to apply). new_release.md also declares bare enhancement, same caveat. compatibility_request.md, objective_delivery.md, regression_testing.md, and task_template.md all reference labels that do exist as declared (request/operational, level/task, type/maintenance, type/test). There is also a revision-manual_test.md file in .github/ISSUE_TEMPLATE with no YAML frontmatter at all — it won't appear in GitHub's template chooser and has no default labels; only use it if the user explicitly points to it (e.g. a Python/footprint test report), and copy its body manually. There is no config.yml in this repo, so there is no blank_issues_enabled override and no contact_links — blank issues are allowed by default and there are no extra support links to surface. No workflow in .github/workflows auto-labels new issues (e.g. no untriaged-on-open action) — unlike some sibling repos, whatever labels you apply here are the only labels the issue gets; there is no auto-added triage label to account for.

4. Labels

Several issue templates in this repo were inherited from the upstream OpenSearch Dashboards fork and still declare stale labels in their frontmatter (bare bug, enhancement) that don't exist as real labels here — GitHub silently drops any label that doesn't exist instead of erroring, so filing the template as-is can result in no type label at all. Standardize on the real Wazuh label set instead of trusting the frontmatter verbatim:

Do not invent labels beyond this set, and do not invent an approval workflow.

5. Emit the ready-to-file body + report

Default deliverable — stop here. Output the filled issue body plus a short report for the human to review:

Issue pre-flight
- Template: <file>
- Labels: <label list>
- Duplicate check: no matches found / possible match: <issue-url>
- Command to open it: gh issue create --template <file> --label "<labels>"

Only run gh issue create when the user explicitly asks you to open the issue.

6. Optional: add the issue to a project board

Only do this if the user explicitly asks — like step 5, this skill does not touch project boards by default. The one proactive exception: if you check the issue's existing project links (e.g. via gh issue view <url> --json projectItems) as part of this or a related workflow and find it linked to zero projects, ask the user whether to add it (and to which project) instead of silently skipping — don't assume no project was ever intended. Resolve the ids fresh each time (they are not portable across projects):

gh project list --owner <org> --format json                    # title → project number, id
gh project item-add <number> --owner <org> --url <issue-url>    # add the issue, get the item id
gh project field-list <number> --owner <org> --format json      # "Status" field id + option ids

gh project item-edit --id <item-id> --field-id <status-field-id> \
  --project-id <project-id> --single-select-option-id <option-id>

repo-specific (wazuh-dashboard-plugins): a Wazuh dashboard issue is commonly linked to two different kinds of GitHub Project: a team board (e.g. XDR+SIEM/Dashboard team) that tracks day-to-day work status, and a release-tracking board (e.g. XDR+SIEM/Release 5.0.0) that tracks the issue against a shipping version. When an issue is (or will be) linked to both, drive status on the team board — the release board reflects release-wide scope, not one person's work, and should be left alone unless the user explicitly asks for it. If more than one team board is linked, list the project titles and ask which one.