@zenuml/core 3.47.9 → 3.48.1

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

@@ -1,253 +0,0 @@
-# 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/.agents/skills/land-pr/SKILL.md

@@ -1,120 +0,0 @@
----
-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. Decide merge strategy
-
-Inspect the branch's commit history to decide between squash and merge:
-
-```bash
-git log main..HEAD --oneline
-```
-
-**Auto-squash if ANY of these are true:**
-- Only 1 commit on the branch
-- Commit messages contain noise patterns: "wip", "fixup", "temp", "oops", "try again", "fix lint", "fix test", duplicate messages
-- More than half the commits have the same or very similar messages
-
-**Merge (preserve commits) if ALL of these are true:**
-- 2+ commits with distinct, meaningful messages
-- Each commit describes a self-contained step (not just iterations on the same change)
-- Commits follow a logical progression (e.g., "add X" → "refactor Y" → "delete Z")
-
-Announce the decision and why: "Squashing — 3 of 5 commits are fixups" or "Merging — 8 clean commits with distinct steps".
-
-### 3. Execute merge
-
-```bash
-# If squash:
-gh pr merge <PR_NUMBER> --squash --auto
-
-# If merge:
-gh pr merge <PR_NUMBER> --merge --auto
-```
-
-Using `--auto` arms auto-merge so GitHub merges when all checks pass. If checks are already green, it merges immediately.
-
-### 4. 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.
-
-### 5. 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
-```
-
-### 6. 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/.agents/skills/propagate-core-release/SKILL.md

@@ -1,205 +0,0 @@
----
-name: propagate-core-release
-description: Propagate a published `@zenuml/core` release by opening or reusing per-repo downstream issues with explicit rollout instructions. Use when the user says "push core to downstreams", "update downstream projects", "propagate release", "open downstream issues", "file rollout issues", or wants the newly published zenuml/core version handed off across mermaid, mermaid live editor, web-sequence, the IntelliJ plugin, confluence-plugin-cloud, and diagramly.ai.
----
-
-# Propagate Core Release
-
-Coordinate downstream consumers after `@zenuml/core` has already been published. This skill creates or reuses per-repo GitHub issues with clear implementation instructions for each downstream team. It does not edit downstream repos or open PRs on their behalf.
-
-## Scope
-
-This skill is for the post-publish propagation step only.
-
-It should:
-
-1. identify the published `@zenuml/core` version to roll out
-2. inspect each downstream repo's update conventions from [references/downstreams.md](references/downstreams.md)
-3. create or reuse one downstream issue per repo for that version
-4. include explicit repo-specific instructions in each issue body
-5. summarize which repos succeeded, failed, or were skipped
-
-It should not:
-
-- publish `@zenuml/core`
-- update downstream code directly
-- create downstream branches or PRs
-- auto-fix unrelated downstream test failures or implementation details
-
-Renderer integration rule:
-
-- Only `mermaid-js/mermaid` and `mermaid-js/mermaid-live-editor` should be treated as SVG-renderer integration work for `@zenuml/core` API changes.
-- All other downstreams remain HTML-renderer consumers. Do not migrate them to `renderToSvg` or other SVG-renderer APIs during propagation.
-
-## Downstream Repos
-
-Read [references/downstreams.md](references/downstreams.md) before starting. It contains the canonical downstream repo list, repo slug assumptions, and repo-specific update commands that must be copied into the issue instructions.
-
-## Preconditions
-
-Before starting:
-
-- confirm the target `@zenuml/core` version is already published
-- confirm `gh auth status` is healthy for all target orgs and repos where issues will be filed
-- if the user did not specify the target version, discover the latest published one first
-
-If the published version is ambiguous, stop and ask.
-
-## Batch Strategy
-
-Treat each downstream repo as an independent unit of work.
-
-- Continue processing the remaining repos if one repo fails.
-- Keep a per-repo status ledger as you go: `issue-opened`, `issue-reused`, `already-tracked`, `blocked`, `failed`.
-- Prefer deterministic, reusable issue text.
-- Check for same-version issues before creating anything new.
-- Reuse an existing open issue when it already targets the same core version.
-- If the same version already has a closed issue, treat it as `already-tracked` and report it instead of opening a duplicate unless the user explicitly asks to reopen or replace it.
-
-## Issue Rules
-
-Each downstream repo should get at most one open issue per core version.
-
-Before creating a new issue, search that repo for issues matching the target version in the title or body. Prefer exact matches on `@zenuml/core v<version>`.
-
-Use a consistent title pattern:
-
-```text
-chore: roll out @zenuml/core v<version>
-```
-
-Use a clear body with actionable instructions:
-
-```markdown
-## Summary
-- `@zenuml/core` `v<version>` has been published
-- this repo needs to adopt that release
-
-## Required Work
-1. Run: `<update-command>`
-2. Run: `<lockfile-refresh-command>` and include the lockfile in the PR when applicable
-3. Run: `<verify-command>` when applicable
-4. Keep the diff scoped to the core upgrade and any required integration fix
-5. Open a downstream PR that links back to this issue
-
-## Repo-Specific Notes
-- <repo-specific note 1>
-- <repo-specific note 2>
-
-## Acceptance Criteria
-- repo is updated to `@zenuml/core` `v<version>` or the equivalent vendored build output
-- lockfile is refreshed when the repo uses one
-- verification command passes locally, or failure details are documented in the PR
-- no unrelated dependency or renderer migrations are mixed into the change
-```
-
-If an issue already exists for the same target version, do not create a duplicate. Reuse the open one, or report the closed one as already tracked.
-
-## Workflow
-
-### Step 1: Resolve target version
-
-Determine the `@zenuml/core` version to propagate.
-
-- If the user supplied a version, use it.
-- Otherwise, query npm or the release source of truth and resolve the latest published version.
-
-Record:
-
-- target version
-- source used to resolve it
-
-### Step 2: Process each downstream repo
-
-For each repo in [references/downstreams.md](references/downstreams.md):
-
-1. Read the repo row carefully and extract the update command, verification command, and notes.
-2. Search for existing issues in that repo for the same core version, checking both open and closed issues.
-3. If an open match exists, reuse it and record the URL.
-4. If only a closed match exists, record it as `already-tracked` and do not create a duplicate unless the user explicitly asked for that.
-5. Otherwise create a new issue using the standard title and a repo-specific body.
-6. Make sure the issue body includes:
-   - the target core version
-   - the exact update command from the table
-   - the lockfile refresh command when the repo uses pnpm or yarn
-   - the exact verify command when one is defined
-   - the renderer and API caveats from the repo notes
-   - an explicit instruction to open a PR linked to the issue after the work is complete
-   - a version marker that makes future deduplication easy, such as `Core version: v<version>`
-
-### Step 3: Handle repo-specific blockers
-
-If a repo fails, capture exactly why:
-
-- missing issue creation permissions
-- existing issue search is ambiguous
-- existing closed issue should be reopened but the policy is unclear
-- dependency location unclear
-- package manager or package filter is unclear
-- repo notes are insufficient to write a safe instruction
-- issue creation failed
-
-Do not let one repo failure stop the rest of the batch.
-
-### Step 4: Summarize the rollout
-
-At the end, produce a per-repo summary with:
-
-- repo
-- issue URL or matched prior issue URL
-- final status
-- blocker if any
-
-## Repo Issue Guidance
-
-Each downstream has specific update and verification commands documented in [references/downstreams.md](references/downstreams.md). Follow the table exactly when drafting instructions. Do not guess package managers, package filters, or update commands.
-
-For each repo:
-
-1. Include the **Update Command** from the table verbatim
-2. Include the lockfile refresh step:
-   - `pnpm install` for pnpm repos
-   - `yarn install` for yarn repos
-3. Include the **Verify Command** from the table verbatim when one exists
-4. Tell the downstream team to keep the change scoped to the core upgrade and any required integration fix
-5. Tell the downstream team to open a PR after verification and link it back to the issue
-
-Special handling for renderer API changes:
-
-- `mermaid-js/mermaid` is the direct `@zenuml/core` SVG-renderer integration. When core export APIs change, it may require code updates in `packages/mermaid-zenuml`, not just a dependency bump.
-- `mermaid-js/mermaid-live-editor` is an indirect SVG-renderer consumer through `@mermaid-js/mermaid-zenuml`. Do not add `@zenuml/core` directly there just to follow a core release.
-- `web-sequence`, `confluence-plugin-cloud`, `diagramly.ai`, and similar downstreams stay on the HTML-renderer path unless the user explicitly asks for a renderer migration.
-
-Prefer the smallest downstream task description that updates the repo safely:
-
-- package dependency bumps
-- lockfile refreshes
-- vendored asset refreshes only when the repo actually vendors core output, such as `jetbrains-zenuml`
-
-Do not ask downstream teams to opportunistically clean up unrelated code while doing the upgrade.
-
-If a downstream repo needs custom update logic that is not obvious from the table or its notes, stop on that repo and report the ambiguity instead of inventing instructions.
-
-## Safety
-
-- Never update downstream repos directly from this skill.
-- Never merge downstream PRs from this skill.
-- Never batch all downstream repos into one issue.
-- Never file duplicate issues for the same repo and core version.
-- Never hide per-repo failures behind a single "batch failed" message.
-- Never ask downstream teams to update unrelated dependencies in the same PR.
-
-## Output
-
-Final report format:
-
-```markdown
-## Downstream Propagation Report
-- Core version: `v<version>`
-- Overall: <N> succeeded, <N> reused, <N> skipped, <N> failed
-
-### Repo Results
-- `<repo>`: issue opened | issue reused | already tracked | failed
-  issue: <url or none>
-  notes: <short reason or blocker>
-```

package/.agents/skills/propagate-core-release/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "Propagate Core Release"
-  short_description: "Open downstream rollout issues for a published core version"
-  default_prompt: "Use $propagate-core-release after @zenuml/core has been published to open or reuse per-repo downstream issues with explicit rollout instructions. Do not update downstream repos directly and do not open PRs on their behalf."
-
-policy:
-  allow_implicit_invocation: true

package/.agents/skills/propagate-core-release/references/downstreams.md

@@ -1,42 +0,0 @@
-# Downstream Repos
-
-Canonical downstream targets for filing rollout issues after a published `@zenuml/core` release.
-
-## Repo Table
-
-| Repo | Local Path | Pkg Manager | Update Command | Verify Command | Notes |
-|------|-----------|-------------|----------------|----------------|-------|
-| `mermaid-js/mermaid` | `~/workspaces/zenuml/native-svg-renderer/mermaid` | pnpm | `pnpm --filter @mermaid-js/mermaid-zenuml update @zenuml/core` | `pnpm build` | Direct SVG-renderer integration. Only touch `packages/mermaid-zenuml`; export API changes may require source edits in addition to the version bump. |
-| `mermaid-js/mermaid-live-editor` | clone if missing | pnpm | `pnpm update @mermaid-js/mermaid-zenuml` | `pnpm build` | Indirect SVG-renderer consumer via `@mermaid-js/mermaid-zenuml`. Do not add `@zenuml/core` directly here. |
-| `ZenUml/web-sequence` | `~/workspaces/zenuml/web-sequence` | yarn | `yarn upgrade @zenuml/core` | `yarn build` | HTML-renderer consumer. Do not migrate to SVG-renderer APIs during routine propagation. |
-| `ZenUml/confluence-plugin-cloud` | `~/workspaces/zenuml/confluence-plugin-cloud` | pnpm | `pnpm update @zenuml/core` | `pnpm build:full` | HTML-renderer consumer. Do not migrate to SVG-renderer APIs during routine propagation. |
-| `ZenUml/diagramly.ai` | `~/workspaces/diagramly/diagramly.ai` | pnpm | `pnpm update @zenuml/core --filter <pkg>` | `pnpm build` | HTML-renderer consumer. Do not migrate to SVG-renderer APIs during routine propagation. |
-| `ZenUml/codemirror-extensions` | `~/workspaces/zenuml/codemirror-extensions` | pnpm | `pnpm update @zenuml/core` | `pnpm build` | CodeMirror language extensions for ZenUML DSL. HTML-renderer consumer. |
-| `ZenUml/jetbrains-zenuml` | `~/workspaces/zenuml/jetbrains-zenuml` | — | See notes | — | **Not an npm consumer.** Vendors a built JS bundle. Update by copying the new `dist/` output from core's build. Skip if unsure and report. |
-
-## Issue Authoring Guidance
-
-When writing a downstream issue for an npm consumer, explicitly include the lockfile refresh step:
-
-- **pnpm**: `pnpm install` (updates `pnpm-lock.yaml`)
-- **yarn**: `yarn install` (updates `yarn.lock`)
-
-Tell the downstream team to include the updated lockfile in the PR. A PR without an updated lockfile will usually fail CI.
-
-## Local Checkout Usage
-
-Local checkouts are optional for this skill. Use them only if you need extra context to clarify the issue body safely. Do not clone repos just to file the issue.
-
-If you do need a checkout and the local path does not exist:
-
-```bash
-gh repo clone <repo-slug> <local-path>
-```
-
-## General Rules
-
-- Each repo gets its own rollout issue.
-- Reuse an existing open issue when it already targets the same core version.
-- `mermaid-js/mermaid` and `mermaid-js/mermaid-live-editor` are under the `mermaid-js` GitHub org (not `ZenUml`).
-- Only `mermaid-js/mermaid` and `mermaid-js/mermaid-live-editor` should receive SVG-renderer integration changes tied to core API/export changes.
-- Treat all other downstreams as HTML-renderer consumers unless the user explicitly asks for a renderer migration.