@zenuml/core 3.46.0 → 3.46.2

package/.claude/skills/dia-scoring/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: dia-scoring
+description: Score HTML-vs-SVG diagram parity in compare-case pages, including message labels, fragment labels, sequence numbers, arrows, participant headers, icons, stereotypes, participant colors, participant groups, comments, and residual diff scopes. Use Playwright for page inspection and semantic attribution.
+---
+
+# Dia Scoring
+
+Use this skill when the task is to measure **message labels, fragment labels, sequence numbers, message arrows, participant labels, participant boxes, participant icons, stereotypes, participant colors, participant groups, inline comments, and residual diff hotspots** between the HTML renderer and the native SVG renderer on `compare-case.html`.
+
+## Diff Source of Truth
+
+The `native-diff-ext` Chrome extension is the absolute source of truth for pixel diff. The analyzer script (`scripts/analyze-compare-case.mjs`) uses the same CDP screenshot capture method and the same diff algorithm (`cy/diff-algorithm.js`), producing identical results when run against the same viewport.
+
+- Use the **analyzer script** as the primary scoring tool (automated, reproducible, CLI-driven)
+- Use the **extension** for live interactive inspection in the browser
+- Both use CDP `Page.captureScreenshot` with `DOM.getBoxModel` border-box clip
+- When calibrating the skill, verify against the extension's live `#diff-panel canvas`
+
+The workflow:
+
+1. Run `node scripts/analyze-compare-case.mjs --case <name> --json` for structured data.
+2. Use `--output-dir <dir>` when you need saved `html.png`, `svg.png`, `diff.png`, and `report.json`.
+3. For live browser inspection, navigate to `http://localhost:8080/cy/compare-case.html?case=<name>` and use the extension's `#diff-panel canvas`.
+4. Use Playwright page inspection for semantic attribution (element positions, font metrics, DOM structure).
+
+## Offset Anchor
+
+All reported offsets must use the **outermost frame's top-left corner** as the anchor.
+
+- HTML anchor: the compare-case HTML frame root
+- SVG anchor: the compare-case SVG root / outer frame root
+- Do not report alternate offset systems
+- Do not anchor offsets to participant boxes, label boxes, stereotype boxes, or local containers
+- If a local-container-relative reading differs from the frame-anchor reading, prefer the frame-anchor reading in all reporting
+
+## Browser Requirement
+
+Use **Playwright browser tools only** for browser interaction in this workflow.
+
+- Preferred tools: `browser_navigate`, `browser_snapshot`, `browser_evaluate`, `browser_take_screenshot`, `browser_click`, `browser_wait_for`
+- Do not use Chrome DevTools browser tools for scoring, DOM inspection, screenshot capture, or residual validation
+- Do not build your own pixel diff from HTML/SVG screenshots. For pixel comparison, use only the extension-rendered `#diff-panel canvas`
+
+## Rules
+
+- Do not use `html-to-image` for capture.
+- Use browser-native screenshots only.
+- Use Playwright for browser-native screenshots and page inspection.
+- All offset calculations must be anchored to the outermost frame's top-left corner.
+- When recalibrating the skill itself, verify against the extension's live `#diff-panel canvas`.
+- Do not use Chrome DevTools browser tools for this workflow.
+- Scope:
+  - normal messages
+  - self messages
+  - returns
+  - creation messages (e.g., `«payload»`, `new Order()`)
+  - fragment conditions such as `[cond]`, `[else]`
+  - fragment section labels such as `catch`, `finally`
+  - participant label text and participant box geometry
+  - participant icons (actor, database, ec2, lambda, azurefunction, sqs, sns, iam, boundary, control, entity)
+  - participant stereotypes such as `«BFF»`, `«Interface»`
+  - participant background colors (`#FFEBE6`, `#0747A6`, etc.) and computed text contrast
+  - participant groups (dashed outline containers with title bar)
+  - inline comments (`// text`) above messages and fragments, including styled comments (`// [red] text`)
+  - residual `html-only` and `svg-only` diff clusters scoped back to nearby elements
+- For each supported message, include:
+  - label text
+  - fragment condition / section label text when present
+  - sequence number text, including fragment sequence numbers when present
+  - arrow geometry keyed by sequence number
+  - normal/return arrow endpoint deltas: `left_dx`, `right_dx`, `width_dx`
+  - self-arrow loop geometry from the painted loop path plus arrowhead, not the outer `svg` viewport
+  - self-arrow vertical deltas: `top_dy`, `bottom_dy`, `height_dy`
+- For participant icons, include:
+  - icon presence (HTML vs SVG)
+  - participant label text when the participant has an icon
+  - icon position relative to participant label
+  - icon visual match confirmation from diff image
+- For participant stereotypes, include:
+  - stereotype text presence (HTML vs SVG), e.g. `«BFF»`
+  - stereotype position relative to participant label (above label, smaller font)
+  - stereotype offset must be measured with per-letter glyph-box comparison relative to the outermost frame anchor
+  - do not use participant-box-relative or other local-container-relative deltas in final reporting
+  - do not mark a stereotype as clean from glyph boxes alone; also check the live `#diff-panel canvas` in the stereotype row
+  - if glyph-box deltas are `0/0` but the panel still shows localized red/blue pixels overlapping the stereotype glyph union, report the stereotype as `ambiguous` or `paint-level residual`, not clean
+  - stereotype text color matching participant background contrast
+- For participant colors, include:
+  - background fill color (hex value) on participant rect
+  - text color contrast (dark text on light bg, white text on dark bg)
+  - color application to both top and bottom participant boxes
+- For participant groups, include:
+  - group name text presence and position (centered title bar)
+  - dashed outline rect enclosing grouped participants
+  - group bounds: leftmost to rightmost participant with margin
+  - group height extending to diagram bottom
+- For inline comments, include:
+  - comment text presence and position (above the associated statement)
+  - comment Y offset from the message/fragment it belongs to
+  - fragment-level comments (e.g. `// comment 4` before `if(...)`) positioned above fragment header
+  - when all letters are `ambiguous` due to large positional offset (e.g. fragment comments at wrong X), the analyzer reports `box_dx` / `box_dy` from the bounding boxes instead of suppressing the measurement
+  - styled comment color application (e.g. `// [red] text`)
+- For participant boxes, use the analyzer script output directly:
+  - Report `html_box`, `svg_box`, `dx`, `dy`, `dw`, `dh` from the script's `participant_boxes` section
+  - The script already applies stroke correction (`strokedElementOuterRect`) — do not re-measure with `browser_evaluate`
+- For residual scopes, include:
+  - connected `html-only` and `svg-only` diff clusters from `#diff-panel canvas`
+  - cluster `size`, `bbox`, and `centroid`
+  - nearest scoped HTML and SVG targets at that position
+  - summaries that explain which element a remaining positional diff most likely belongs to
+  - live native diff panel confirmation before claiming a hotspot is real
+  - the largest confirmed live-panel `html-only` and `svg-only` clusters with approximate positions
+  - grouped summaries of where the panel's red and blue pixels are concentrated
+- Do not report a residual hotspot as real if it is absent from the live `#diff-panel canvas`.
+- Do not stop at totals like `HTML-only (44)` or `SVG-only (55)` when residuals matter; report where those pixels are.
+- Each reported letter must be backed by:
+  - direct HTML-vs-SVG browser layout positions
+  - pixel-panel confirmation from `#diff-panel canvas`
+- Participant stereotypes are first-class targets, not just part of `participant-box` or `participant-label`.
+- If the evidence is weak or contradictory, keep the letter `ambiguous`.
+
+## Known Analyzer Internals
+
+### Arrow pairing by sequence number
+
+The analyzer pairs arrows by sequence number (`text` field), not by label text (`pairText`). Calibrated on `repro-creation-return-arrow` (2026-03-24).
+
+## Commands
+
+Run from [../..](../..):
+
+```bash
+node scripts/analyze-compare-case.mjs --case async-2a
+node scripts/analyze-compare-case.mjs --case async-2a --json
+node scripts/analyze-compare-case.mjs --case async-2a --output-dir tmp/message-elements/async-2a
+```
+
+## References
+
+- Selector and pairing details: [references/selectors-and-keys.md](references/selectors-and-keys.md)

package/.claude/skills/dia-scoring/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Dia Scoring"
+  short_description: "Diagram label, number, and arrow offsets"
+  default_prompt: "Use $dia-scoring to measure message label, sequence-number, and arrow parity for a compare-case page."
+
+policy:
+  allow_implicit_invocation: true

package/.claude/skills/dia-scoring/references/selectors-and-keys.md

@@ -0,0 +1,253 @@
+# Selectors And Keys
+
+The analyzer uses these roots:
+
+- HTML root: `#html-output .frame`, fallback `#html-output .sequence-diagram`
+- SVG root: `#svg-output > svg`
+
+Offset anchor:
+
+- All reported offsets use the outermost frame root's top-left corner
+- HTML side: `#html-output .frame`, fallback `#html-output .sequence-diagram`
+- SVG side: `#svg-output > svg`
+- Do not emit final `dx` / `dy` values from participant-local or other nested-container anchors
+
+HTML label extraction:
+
+- Normal messages: iterate `.interaction`, skip `.return`, `.creation`, and self interactions, then read `.message .editable-span-base`
+- Self messages: `.self-invocation .label .editable-span-base`
+- Returns: `.interaction.return .message .editable-span-base`, fallback `.interaction.return .name`
+- Fragment conditions: `.fragment .segment > .text-skin-fragment:not(.finally)`, using only visible child spans when conditional branches are stacked
+- Fragment sections:
+  - `.fragment.fragment-tcf .segment > .header.inline-block.bg-skin-frame.opacity-65`
+  - `.fragment.fragment-tcf .segment > .header.finally`
+
+SVG label extraction:
+
+- Normal messages: `g.message:not(.self-call) > text.message-label`
+- Self messages: `g.message.self-call > text.message-label`
+- Returns: `g.return > text.return-label`
+- Fragment conditions: `g.fragment > text.fragment-condition`
+- Fragment condition / section groups: `g.fragment > g` containing `text.fragment-section-label`
+  - texts starting with `[` are treated as `fragment-condition`
+  - other texts are treated as `fragment-section`
+
+Pairing key:
+
+- Semantic grouping is by `kind + text`
+- Duplicate labels are paired by top-to-bottom order within that group
+- Output key is:
+  - `kind`
+  - `text`
+  - `y_order`
+- Fragment labels also include `owner=<fragment header>` in the human-readable summary when available
+
+Per-letter scoring:
+
+- Grapheme segmentation uses `Intl.Segmenter`, fallback `Array.from`
+- Glyph boxes come from browser layout ranges, not whole-word centroids
+- Numeric `dx` and `dy` are only emitted when direct layout evidence and diff-image evidence agree
+
+Arrow extraction:
+
+- HTML normal/return messages:
+  - line: direct child `svg` line strip inside `.message`
+  - head: direct child arrowhead `svg` inside `.message`
+- HTML self messages:
+  - loop: painted geometry inside `svg.arrow`
+  - parts: outer loop path plus nested arrowhead path
+- SVG normal messages:
+  - line: `line.message-line`
+  - head: `svg.arrow-head`
+- SVG returns:
+  - line: `line.return-line`
+  - head: `polyline.return-arrow`
+- SVG self messages:
+  - loop: painted geometry inside the outer `svg` under `g.message.self-call`
+  - parts: outer loop path plus nested arrowhead path
+
+Arrow scoring:
+
+- Arrows are keyed by sequence number when numbering is available, for example `arrow:1.2.3`
+- Normal and return arrows are measured as one combined geometry item:
+  - line + arrow head together
+- Self arrows are measured as one loop geometry item
+- Self arrows use the union of the painted loop path and arrowhead path, not the outer viewport box
+- Arrow output is endpoint-based, not box-centroid-based
+- For normal and return arrows, report:
+  - `left_dx`
+  - `right_dx`
+  - `width_dx`
+- For self arrows, also report:
+  - `top_dy`
+  - `bottom_dy`
+  - `height_dy`
+- Do not report `dy` for horizontal message arrows
+
+HTML sequence number extraction:
+
+- Normal messages: `.interaction:not(.return):not(.creation):not(.self-invocation):not(.self) > .message > .absolute.text-xs`
+- Self messages: `.interaction.self-invocation > .message .absolute.text-xs`
+- Returns: `.interaction.return > .message > .absolute.text-xs`
+- Fragments: `.fragment > .header > .absolute.text-xs`
+
+SVG sequence number extraction:
+
+- Normal messages: `g.message:not(.self-call) > text.seq-number`
+- Self messages: `g.message.self-call > text.seq-number`
+- Returns: `g.return > text.seq-number`
+- Fragments: `g.fragment > text.seq-number`
+
+## Participant Icon Extraction
+
+## Participant Header Extraction
+
+HTML participant header extraction:
+
+- Participant root: `.participant[data-participant-id]`
+- Participant box: outer border box from the participant root element
+- Participant stereotype: `label.interface`, when present
+- Participant label: last `.name` descendant, measured by glyph boxes
+
+SVG participant header extraction:
+
+- Participant root: `g.participant[data-participant]`
+- Skip `g.participant-bottom`
+- Participant box element: `:scope > rect.participant-box`
+- Participant box measurement must use the painted outer bounds of the stroked rect, not the inset rect geometry
+- Participant stereotype:
+  - prefer `:scope > text.stereotype-label`
+  - fallback: top-most direct `text` child above `text.participant-label`
+- Participant label: `:scope > text.participant-label`
+
+Participant stereotype pairing and scoring:
+
+- Pair by participant name
+- Validate text equality, for example `«BFF»`
+- Measure stereotype offset by per-letter glyph boxes relative to the outermost frame root, not by participant-local anchors or whole-word box centroids
+- Report:
+  - `letter_deltas`
+  - concise aggregate only when the per-letter evidence agrees
+- Do not mark the stereotype clean from glyph boxes alone
+- Also check the live `#diff-panel canvas` over the union of the HTML and SVG stereotype glyph boxes
+- If localized red or blue pixels persist in that stereotype region while glyph-box deltas are `0/0`, classify it as `ambiguous` or `paint-level residual`
+
+Participant box pairing and scoring:
+
+- Pair by participant name
+- Report `html_box` and `svg_box` with `x`, `y`, `w`, `h`
+- Box `x` / `y` values are frame-anchor-relative
+- Report box deltas:
+  - `dx`
+  - `dy`
+  - `dw`
+  - `dh`
+
+HTML icon extraction:
+
+- Participant root: `.participant[data-participant-id]`
+- Top-row participant only: keep the top-most entry for each participant id
+- Icon host: first child inside the centered participant row when it is an async icon host
+  - `[aria-description]`
+  - or contains `svg`
+  - or has `h-6` sizing class from `AsyncIcon`
+- Icon box: union of painted SVG shapes when available, fallback to the host box
+- Participant label: last `.name` descendant, measured by glyph boxes
+
+SVG icon extraction:
+
+- Participant root: `g.participant[data-participant]`
+- Skip `g.participant-bottom`
+- Icon element: `:scope > g[transform]`
+- Icon box: union of painted shapes within that transformed group
+- Participant label: `:scope > text.participant-label`
+
+Icon pairing:
+
+- Pair by participant name
+- Only report participant icon rows for participants where at least one side has an icon
+- Participant labels for icon-bearing participants are paired by participant name, not raw label text
+
+Icon scoring:
+
+- Absolute icon drift:
+  - `icon_dx`
+  - `icon_dy`
+- Absolute icon drift is measured from the outermost frame anchor
+- Relative icon drift against the participant label anchor:
+  - `relative_dx`
+  - `relative_dy`
+- If there is no participant label on one side, use the participant box center as the anchor
+- Report presence mismatch if one renderer has an icon and the other does not
+- Diff confirmation is taken from `#diff-panel canvas`, scoped to the union of the HTML and SVG icon boxes
+
+## Residual Scope Attribution
+
+Residual scope extraction:
+
+- Build connected clusters from the live `#diff-panel canvas` colors:
+  - red = `html-only`
+  - blue = `svg-only`
+- Ignore green `match` and magenta `color diff` pixels for positional scoping
+- Each cluster reports:
+  - `size`
+  - `bbox`
+  - `centroid`
+- These panel-derived clusters are the source of truth for residual hotspots.
+
+Residual scope candidates:
+
+- HTML side:
+  - labels
+  - numbers
+  - arrows
+  - participant stereotypes
+  - participant labels
+  - participant icons
+  - participant boxes
+  - diagram root fallback
+- SVG side:
+  - labels
+  - numbers
+  - arrows
+  - participant stereotypes
+  - participant labels
+  - participant icons
+  - participant boxes
+  - `rect.frame-border-inner`, fallback `rect.frame-border` / `rect.frame-box`
+  - diagram root fallback
+
+Residual scope attribution:
+
+- Pick the closest candidate to the cluster centroid on each side
+- Prefer targets that contain the centroid
+- Prefer more specific categories over large containers:
+  - `participant-icon`
+  - `participant-stereotype`
+  - `label`, `number`, `participant-label`
+  - `arrow`
+  - `participant-box`
+  - `frame-border`
+  - `diagram-root`
+- Use cluster/target overlap and centroid distance as tie-breakers
+
+Residual scope output:
+
+- `residual_scopes`: all attributed clusters
+- `residual_scope_summary`: top 20 concise lines for terminal use
+- `residual_scope_html_only_top`: top 10 `html-only` clusters
+- `residual_scope_svg_only_top`: top 10 `svg-only` clusters
+- When answering from the live panel, also report:
+  - the largest red clusters from `#diff-panel canvas`
+  - the largest blue clusters from `#diff-panel canvas`
+  - approximate diagram-space positions or bounding boxes
+  - attributed HTML and SVG targets for those clusters
+  - a short grouped summary of where the red and blue pixels are concentrated
+
+Live panel validation:
+
+- Source of truth for residual hotspots is `#diff-panel canvas`
+- Confirm the hotspot by reading the panel's actual red and blue pixels at that area
+- If the panel shows no red or blue pixels there, do not report that hotspot as a real residual diff
+- If the panel shows non-zero red or blue totals, do not stop at the totals alone; locate the dominant clusters and report them
+- Do not build or rely on a separate screenshot-to-screenshot diff for pixel comparison when `#diff-panel canvas` is available on the page

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)