Develop Issue

Develop an issue (issue → code → tests → delivery)

Entry point for feature/bug work. Takes an issue, produces the change plus a ready-to-paste PR delivery, and hands off to the developer for the screenshot and the final PR creation. Chains the check-standards and create-pr skills.

Workflow

Copy this checklist and track progress:

- [ ] 1. Plan from the issue (goal, acceptance criteria, affected layer)
- [ ] 2. Implement, focused on the issue, respecting conventions
- [ ] 3. Add/update colocated tests and run them
- [ ] 4. Validate with check-standards; fix failures
- [ ] 5. Add the CHANGELOG entry
- [ ] 6. Deliver via create-pr (prepare mode) — do NOT open the PR

1. Plan

Issues are normally shared as a URL and may live in a different repo. Read it first and classify the source:

gh issue view <issue-url>

• Internal — URL contains internal-devel-request (e.g. wazuh/internal-devel-requests): the issue link is not exposed in the PR (## Description gets no closing reference) and there is no CHANGELOG entry.
• Public — any other repo (e.g. wazuh/wazuh-dashboard-alerting): link it in the PR and add a CHANGELOG entry pointing to the issue.

Restate the issue's goal and acceptance criteria in your own words. Identify the affected layer(s) — public (browser/React), server (Node/routes/services). Ask the user only if genuinely blocked; otherwise proceed with reasonable defaults.

2. Implement

Keep the change scoped to the issue. Respect the architecture and conventions in CLAUDE.md:

• Never import server/ from public/ or vice versa; shared code goes in a shared module (this plugin has no common/ dir — follow the surrounding structure). Cross-plugin: public → other/public, server → other/server, preferably via setup()/start() contracts.
• This is a fork of opensearch-project/alerting-dashboards-plugin: match the upstream filename convention (PascalCase for components), English everywhere. It is primarily JavaScript (Redux Toolkit, Formik, react-vis); the OpenSearch license header is NOT enforced here, so do not add one. On upstream syncs, Wazuh content wins.

3. Tests (colocated)

Add or update unit tests as *.test.js / *.test.tsx, typically inside __tests__/ folders next to the changed source (snapshots under __snapshots__/). New functionality must include testing.

repo-specific (wazuh-dashboard-alerting): this plugin's scripts run from inside the wazuh-dashboard checkout at plugins/<this-plugin> (they reference ../../node_modules/.bin/jest). Bootstrap the platform once (yarn osd bootstrap from the wazuh-dashboard root), then run yarn test:jest here (not yarn test); refresh snapshots with yarn test:jest:update-snapshots.

4. Validate

Run the check-standards skill (prettier + eslint + tests over the diff; this JS-first repo has no typecheck step). Fix everything it reports before delivering.

5. CHANGELOG

For public issues, add an entry under the upcoming version in CHANGELOG.md (Added / Changed / Fixed / Removed), with the link pointing to the issue (not the PR). Skip the entry for internal-devel-requests issues, and for tooling/docs/test-only changes (use the no-changelog label on the PR).

6. Deliver (do NOT open the PR)

Invoke create-pr in its default prepare-and-hand-off mode. Output:

• The filled PR-template body, with the ## Description completed (public issue → Closes #<n> / issue URL; internal-devel-requests → no closing reference), the ### Review Checklist boxes that genuinely apply checked, and a screenshot/video reminder under ### Results and Evidence for any UI change.
• The pre-flight report (branch, suggested base, DCO status, check-standards result, CHANGELOG status, and the gh pr create command to run when ready).

End by reminding the developer to sign commits with --signoff and to add the screenshot before opening the PR.