Run any Skill in Manus with one click

kymo-parity

Stars7

Forks1

UpdatedJune 20, 2026 at 23:45

Check or close Python↔JS feature parity in kymostudio via the conformance suite. Use when adding a feature to one impl (Python or JS) that the other needs, when a JS conformance test diverges from Python's golden, or to confirm a new behavior is locked in both languages. Encodes the rule that Python is the reference impl and JS reconciles toward it.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

kymostudio

kymostudio/kymostudio

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	kymo-parity
description	Check or close Python↔JS feature parity in kymostudio via the conformance suite. Use when adding a feature to one impl (Python or JS) that the other needs, when a JS conformance test diverges from Python's golden, or to confirm a new behavior is locked in both languages. Encodes the rule that Python is the reference impl and JS reconciles toward it.
argument-hint	[feature-or-stem]
allowed-tools	Bash Read Edit Grep

This is the Loop 2 parity watcher from docs/research/engineering/loop-engineering/application-kymostudio.md. CLAUDE.md's headline constraint: packages/python and packages/js are two independent impls kept at parity. The conformance suite enforces it — but only for behaviors that have a corpus case. A new feature with no case is invisible to the gate until you add one.

The asymmetry (non-negotiable)

Python is the reference implementation and the sole golden writer. JS is read-only against conformance/golden/. So parity is always restored by reconciling JS toward Python, never by editing the golden or loosening the JS test. The documented root cause of every past divergence was JS rounding — fix it with pyRound (packages/js/src/round.ts, half-to-even) wherever Python uses int(round(...)): hot spots are alignment.ts, bpmn-layout.ts, from-bpmn.ts, to-bpmn.ts.

Two modes

A. Diagnose a divergence (a JS conformance test is red)

Run cd packages/js && npm test and read the deepEqual diff — it names the field and the two values.
Locate where Python computes that field vs where JS does (Grep the field name in both packages/python/src/kymo/ and packages/js/src/).
If the values differ by a rounding boundary (.5 cases, off-by-one px), it's a pyRound site in JS. Apply pyRound; re-run. If it's a genuinely unported feature, port it to JS.
Never touch conformance/golden/* to "fix" this — that inverts the reference direction.

B. Lock a new behavior into both impls

Add a minimal corpus case exercising the behavior to conformance/corpus/<name>.kymo (or a .bpmn fixture under the BPMN corpus).

Regenerate the golden from Python (the writer):

cd packages/python && KYMO_UPDATE_CONFORMANCE=1 uv run --group dev python -m pytest tests/test_conformance.py tests/test_bpmn_conformance.py

Run the JS suite against the new golden:
```
cd packages/js && npm test
```
If JS passes → parity is locked. If it diverges → mode A (port/reconcile JS).
A genuinely tracked-but-unreconciled .bpmn gap goes in conformance/known_divergences.json with a reason — but treat that as a last resort, not a shortcut.

Output

State: the field/feature, which impl was behind, the reconciliation (pyRound site or port), and the final cross-impl /kymo-verify all verdict. If you added a corpus case, name it.

More from this repository

same repository

issue

kymostudio/kymostudio

Create or reformat a GitHub issue on kymostudio/kymostudio via the `gh` CLI. Picks the matching `.github/ISSUE_TEMPLATE` form (bug_report / feature_request), mirrors its fields into the body, sets the org Issue Type (Feature for feature_request) and auto-applies `#`-prefixed area labels from the existing repo labels. Use when the user says "tạo issue", "create issue", "mở issue", "open issue", "report bug", or asks to reformat an existing issue for this repo.

2026-06-247

fmt-sweep

kymostudio/kymostudio

Fix a red "Format & clippy" (rust.yml) CI job on kymostudio — auto-apply cargo fmt, verify the exact CI lint gate goes green, and ship the fix. Use when a Rust core CI run fails on the rustfmt or clippy step, or to pre-empt one before pushing Rust changes. Formatting is deterministic and non-semantic, so the fmt fix is safe to auto-apply; clippy failures are surfaced, not blindly rewritten.

2026-06-217

kymo-golden

kymostudio/kymostudio

Reconcile kymostudio's golden/baseline fixtures after an INTENTIONAL renderer, layout, or grammar change — classify each failing gate as intended vs a real regression, regenerate only the right tier, then prove parity held. Use when golden SVG tests, the BPMN corpus baseline, or the conformance suite fail because you deliberately changed output. Do NOT use to silence an unexplained red test.

2026-06-207

kymo-verify

kymostudio/kymostudio

Run kymostudio's verifiable stop condition — Python pytest + JS conformance parity — and report a clear PASS/FAIL with the failing output. Use as the goal check for any /loop or /goal on this repo, or to confirm a change is green before committing. Trigger phrases - "is it green", "verify the build", "check parity", "did the change break anything".

2026-06-207

loop-design

kymostudio/kymostudio

Design an autonomous agent loop for the kymostudio repo — pick a verifiable goal contract, wire trigger/actions/verification/memory, and pick a safe maturity level. Use when the user wants to automate recurring work here ("automate X", "set up a loop", "run this nightly", "keep checking Y"), or before writing a /loop, /goal, or .claude/workflows script. Loop engineering = designing the system that prompts the agent, not prompting by hand.

2026-06-207

name	kymo-parity
description	Check or close Python↔JS feature parity in kymostudio via the conformance suite. Use when adding a feature to one impl (Python or JS) that the other needs, when a JS conformance test diverges from Python's golden, or to confirm a new behavior is locked in both languages. Encodes the rule that Python is the reference impl and JS reconciles toward it.
argument-hint	[feature-or-stem]
allowed-tools	Bash Read Edit Grep

The asymmetry (non-negotiable)

Two modes

A. Diagnose a divergence (a JS conformance test is red)

Run cd packages/js && npm test and read the deepEqual diff — it names the field and the two values.
Locate where Python computes that field vs where JS does (Grep the field name in both packages/python/src/kymo/ and packages/js/src/).
If the values differ by a rounding boundary (.5 cases, off-by-one px), it's a pyRound site in JS. Apply pyRound; re-run. If it's a genuinely unported feature, port it to JS.
Never touch conformance/golden/* to "fix" this — that inverts the reference direction.

B. Lock a new behavior into both impls

Add a minimal corpus case exercising the behavior to conformance/corpus/<name>.kymo (or a .bpmn fixture under the BPMN corpus).

Regenerate the golden from Python (the writer):

cd packages/python && KYMO_UPDATE_CONFORMANCE=1 uv run --group dev python -m pytest tests/test_conformance.py tests/test_bpmn_conformance.py

Run the JS suite against the new golden:
```
cd packages/js && npm test
```
If JS passes → parity is locked. If it diverges → mode A (port/reconcile JS).
A genuinely tracked-but-unreconciled .bpmn gap goes in conformance/known_divergences.json with a reason — but treat that as a last resort, not a shortcut.

Output

State: the field/feature, which impl was behind, the reconciliation (pyRound site or port), and the final cross-impl /kymo-verify all verdict. If you added a corpus case, name it.