@zenuml/core 3.46.1 → 3.46.2

package/.claude/skills/land-pr/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: land-pr
+description: Merge a green PR and verify the npm release succeeds. Use when the user says "merge", "land", "land PR", "merge this", "ship to npm", "merge and release", or when a PR has passed CI and is ready to merge. This is a high-stakes action — merging to main triggers an automatic npm publish, so this skill verifies everything before and after merge.
+---
+
+# Land PR
+
+Merge a green PR to `main` and verify the npm release. In this repo, **merge = release** — every merge to main triggers automatic npm publish via GitHub Actions. Treat this as a production deployment, not a casual merge.
+
+## Preconditions
+
+Before merging, verify ALL of these:
+
+1. **All CI checks green** — no pending or failed checks
+2. **No pending reviews** — no requested changes outstanding
+3. **Branch is up to date** — no merge conflicts with main
+4. **PR is the right one** — confirm PR number with the user if ambiguous
+
+```bash
+gh pr view <PR_NUMBER> --json state,mergeable,statusCheckRollup,reviewDecision
+```
+
+If any precondition fails, report which one and stop. Do not attempt to fix — that's `babysit-pr`'s job.
+
+## Steps
+
+### 1. Verify readiness
+
+Run the precondition checks above. If anything is not green, stop and report.
+
+### 2. Squash merge
+
+This repo uses squash merges. The merge commit message should summarize the PR.
+
+```bash
+gh pr merge <PR_NUMBER> --squash --auto
+```
+
+Using `--auto` arms auto-merge so GitHub merges when all checks pass. If checks are already green, it merges immediately.
+
+### 3. Wait for merge
+
+If auto-merge was armed, wait for it:
+
+```bash
+gh pr view <PR_NUMBER> --json state
+```
+
+Poll until state is `MERGED`. Timeout after 5 minutes — if not merged by then, report and stop.
+
+### 4. Monitor npm publish
+
+After merge, the `Build, Test, npm Publish, and Deploy` workflow runs on `main`. Watch it:
+
+```bash
+gh run list --repo mermaid-js/zenuml-core --branch main --limit 1 --json databaseId,status,conclusion
+```
+
+Wait for the run to complete:
+
+```bash
+gh run watch <RUN_ID> --repo mermaid-js/zenuml-core
+```
+
+### 5. Verify npm publish
+
+Check that the new version appeared on npm:
+
+```bash
+npm view @zenuml/core version
+```
+
+Compare with the version before merge. If it didn't bump, check the `npm-publish` job logs for errors.
+
+## Output
+
+Report one of:
+
+- **LANDED** — merged, published to npm as `@zenuml/core@<version>`
+- **MERGE BLOCKED** — which precondition failed
+- **PUBLISH FAILED** — merged but npm publish failed, with error details
+
+## On publish failure
+
+**Do NOT auto-rollback.** A failed npm publish after merge is a serious situation that needs human judgment. Report:
+
+1. The merge commit SHA
+2. The failing workflow run URL
+3. The npm-publish job error output
+4. Whether the version was partially published
+
+The user decides whether to hotfix, revert, or investigate.
+
+## Does NOT
+
+- Fix CI (use `/babysit-pr`)
+- Create PRs (use `/submit-branch`)
+- Run local tests (use `/validate-branch`)

package/.claude/skills/ship-branch/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: ship-branch
+description: Ship the current branch from local validation through to npm release. Orchestrates validate-branch, submit-branch, babysit-pr, and land-pr in sequence. Use when the user says "ship", "ship it", "ship this branch", "ship to production", "release this", "get this to npm", or wants to go from local branch to published npm package in one command. Stops at the first failure with a clear report.
+---
+
+# Ship Branch
+
+Orchestrate the full path from local branch to npm release. This skill composes four sub-skills in sequence, stopping at the first failure.
+
+## Flow
+
+```
+validate-branch → FAIL → stop, report
+     | PASS
+submit-branch → FAIL → stop, report
+     | PR ready
+babysit-pr → EXHAUSTED → stop, "CI blocked"
+     | GREEN
+land-pr → BLOCKED → stop, report
+     | MERGED
+land-pr → PUBLISH FAIL → alert, stop
+     | PUBLISHED
+     done
+```
+
+## Steps
+
+### Step 1: Validate locally
+
+Invoke `/validate-branch`. If it reports FAIL, stop and show the failure. The developer needs to fix locally before shipping.
+
+### Step 2: Submit as PR
+
+Invoke `/submit-branch`. If it reports FAILED, stop and show what went wrong (dirty worktree, push conflict, etc.).
+
+On success, note the PR number and URL.
+
+### Step 3: Get CI green
+
+Invoke `/babysit-pr` with the PR number from Step 2. If it exhausts all 3 retry attempts, stop and report "CI blocked" with the babysit report.
+
+On success, the PR is green and ready to merge.
+
+### Step 4: Land and verify release
+
+Invoke `/land-pr` with the PR number. If merge is blocked (pending reviews, failed checks), stop and report.
+
+If merge succeeds but npm publish fails, alert immediately with the failure details. Do NOT auto-rollback.
+
+On full success, report the new npm version.
+
+## Rules
+
+- **Each step is a hard boundary.** No step reaches back to retry a previous step.
+- **No auto-rollback.** Stop and report on any failure. The developer decides next steps.
+- **Only this skill calls babysit-pr.** Sub-skills never cross-call each other.
+- **Confirm before merge.** Since merge = npm release, pause and confirm with the user before Step 4 unless they explicitly said "ship it" (indicating full automation is intended).
+
+## Output
+
+Final report:
+
+```
+## Ship Report: <branch-name>
+- Validation: PASS
+- PR: #<number> (<url>)
+- CI: GREEN (attempt <N>)
+- Merge: SQUASHED into main (<sha>)
+- npm: @zenuml/core@<version> published
+```
+
+Or on failure:
+
+```
+## Ship Report: <branch-name>
+- Validation: PASS
+- PR: #<number>
+- CI: BLOCKED after 3 attempts
+- Stopped at: babysit-pr
+- Details: <failure summary>
+```

package/.claude/skills/submit-branch/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: submit-branch
+description: Push the current branch and create or reuse a PR on mermaid-js/zenuml-core. Use when the user says "submit", "create PR", "push and PR", "open a pull request", "submit branch", or wants to publish their work as a PR without merging. Does not fix CI or merge — those are separate skills.
+---
+
+# Submit Branch
+
+Publish the current branch as a pull request on `mermaid-js/zenuml-core`. Reuses an existing PR if one already exists for this branch.
+
+## Preconditions
+
+The worktree must be in a committable state:
+
+- **Clean worktree** — nothing to commit, just push. This is the ideal case.
+- **Scoped changes** — all modified files relate to the current work. Stage and commit them.
+- **Mixed/unrelated changes** — modified files include unrelated work. **Stop and ask the user** which files to include. Never auto-commit a mixed worktree.
+
+To check: `git status` and review the file list. If in doubt, ask.
+
+## Steps
+
+### 1. Check worktree state
+
+```bash
+git status
+```
+
+If dirty, evaluate whether changes are scoped (all related to the branch's purpose) or mixed. If mixed, stop and ask.
+
+If scoped, stage the relevant files and commit with a descriptive message. Follow the repo's commit conventions (one-line message, Co-Authored-By trailer).
+
+### 2. Push
+
+```bash
+git push -u origin <branch-name>
+```
+
+Use regular push — never force-push. If push fails due to upstream changes, report the conflict and stop.
+
+### 3. Create or reuse PR
+
+Check if a PR already exists:
+
+```bash
+gh pr view --json number,title,url 2>/dev/null
+```
+
+If a PR exists, report its URL and stop — nothing more to do.
+
+If no PR exists, create one:
+
+```bash
+gh pr create --title "<concise title>" --body "$(cat <<'EOF'
+## Summary
+<bullet points>
+
+## Test plan
+<what was tested>
+EOF
+)"
+```
+
+The PR targets `main` on `mermaid-js/zenuml-core`.
+
+## Output
+
+Report:
+
+- **SUBMITTED** — PR number, URL, and branch name
+- **FAILED** — what went wrong (dirty worktree, push conflict, gh error)
+
+## Does NOT
+
+- Run tests or lint (use `/validate-branch` for that)
+- Fix CI failures (use `/babysit-pr` for that)
+- Merge the PR (use `/land-pr` for that)

package/.claude/skills/validate-branch/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: validate-branch
+description: Run local validation checks on the current branch before shipping. Use when the user says "validate", "check branch", "am I good", "run tests", "preflight", "is this ready", or wants to verify their branch passes all checks before pushing or creating a PR. Also use as a precondition check before invoking submit-branch or ship-branch.
+---
+
+# Validate Branch
+
+Verify the current branch passes all local checks. This is the "am I good?" skill — run it anytime before shipping, or just to check your work.
+
+## Why this order matters
+
+Checks run fastest-first so you get feedback quickly. Lint catches syntax issues in seconds. Unit tests catch logic errors in a few seconds. Playwright E2E is slowest (~1-2 min) and catches integration regressions. No point waiting for E2E if lint fails.
+
+## Steps
+
+Run from the `zenuml-core` directory. Stop on first failure.
+
+### 1. Lint
+
+```bash
+bun eslint
+```
+
+If lint fails, report the errors and stop. These are usually quick fixes.
+
+### 2. Unit tests
+
+```bash
+bun run test
+```
+
+Do NOT use `bun test` — it picks up Playwright files and gives false failures. If tests fail, report the failing test names and stop.
+
+### 3. Playwright E2E
+
+```bash
+bun pw
+```
+
+If snapshot tests fail, check whether the changes are intentional (rendering code changed) or unexpected. Report which snapshots failed.
+
+## Output
+
+Report one of:
+
+- **PASS** — all 3 checks passed, branch is ready
+- **FAIL** — which check failed, the error output, and a one-line suggestion
+
+## Gotchas
+
+- `bun run test` not `bun test` — critical difference, the latter runs E2E too
+- Playwright needs browsers installed (`bun pw:install` if missing)
+- If the dev server is running on port 8080, Playwright may conflict — check first
+- HTML Playwright snapshot failures are a hard stop — never update HTML snapshots without understanding why they changed