Skip to content
cccskills
FreePublished on GitHub

sync-viewer-symlinks

Ensure site/viewer/lib has correct symlinks to src/viewer/assets/lib

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md4.5 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Synchronize symlinks in site/viewer/lib/ so that the site viewer picks up all shared modules from src/viewer/assets/lib/.

Context

The site viewer (site/viewer/) shares most of its JavaScript and CSS with the agent viewer (src/viewer/assets/). Shared files are kept as symlinks in site/viewer/lib/ pointing into src/viewer/assets/lib/. A small set of site-specific files are standalone (not symlinked).

When new files are added to src/viewer/assets/lib/, the corresponding symlink in site/viewer/lib/ must be created manually. This skill detects and fixes any missing symlinks.

Standalone files (never symlinked)

Only these two top-level files in site/viewer/lib/ are site-specific real files (site keeps its own copy):

  • script.js — site-specific entry point
  • viewer_api.js — site-specific API transport layer (calls the in-browser WASM registry instead of the HTTP backend)

Everything else — including data.js — is a same-name symlink into src/viewer/assets/lib/. (There is no data_base.js; that was an older architecture. dashboards.js no longer exists.)

Coverage can be per-file OR a directory symlink

Most of site/viewer/lib/ is per-file symlinks, but some subtrees are covered by a directory symlink — e.g. site/viewer/lib/embed -> ../../../src/viewer/assets/lib/embed — which serves every file underneath it. So the invariant is resolution, not per-file-symlink presence: every shared module must resolve at the same relative path under site/viewer/lib/.

A tool that looks only for a per-file symlink (or a find that doesn't descend through a directory symlink) will false-flag files under a directory symlink. Test with [ -e "$link" ] (follows all symlinks), never [ -L ]. CAUTION: because site/viewer/lib/embed is a directory symlink into src/, writing to site/viewer/lib/embed/X writes through it into src/…/embed/X — never mkdir/ln inside a directory-symlinked path.

Enforced in CI

scripts/check-viewer-symlinks.sh implements this (resolution-based) check and runs on every PR via .github/workflows/viewer-symlinks.yml. Run it locally before pushing a viewer change: bash scripts/check-viewer-symlinks.sh.

Steps

  1. Scan src/viewer/assets/lib/ recursively for all .js and .css files

  2. For each source file, determine the expected path in site/viewer/lib/:

    • Skip the standalone top-level files script.js, viewer_api.js
    • Everything else → same relative path, which must resolve ([ -e ]) via either a per-file symlink or a covering directory symlink
  3. Check whether the expected symlink exists and points to the correct target. Compute the relative path from the symlink location back to the source file (e.g., ../../../src/viewer/assets/lib/charts/chart.js for a file in site/viewer/lib/charts/).

  4. Create any missing symlinks. Create parent directories if needed. Report each symlink created.

  5. Detect any stale symlinks in site/viewer/lib/ that point to non-existent source files, and report them (but don't delete without asking).

  6. Stage newly created symlinks with git add.

  7. Report a summary: how many symlinks checked, how many created, any stale links found.

Pre-commit hook

A Claude Code hook at .claude/settings.json runs .claude/scripts/pre-commit-check.sh before every git commit. It blocks the commit if:

  • Any shared viewer module fails to resolve under site/viewer/lib/
  • Dashboard JSON is out of date with Rust definitions (only when src/viewer/dashboard/ or src/viewer/plot.rs files are staged)

The hook wiring (.claude/settings.json) is per-checkout Claude Code config, so the hook only fires for local Claude Code users — that is exactly why the symlink check is also enforced in CI (viewer-symlinks.yml → scripts/check-viewer-symlinks.sh), which is the binding gate for every PR. To set up the local hook on a fresh checkout, create .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit*)",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/scripts/pre-commit-check.sh",
            "timeout": 120
          }
        ]
      }
    ]
  }
}

And copy or recreate .claude/scripts/pre-commit-check.sh (see the existing copy in this repo's working tree for reference).

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Write or update the CLI `--help` text and README section for a new or changed rezolus feature (a subcommand, flag, mode, or behavior change), then prove the help is usable by dispatching a fresh subagent that has never seen the code. Use this whenever you add or change how rezolus is invoked — new `rezolus <subcommand>`, new flags/args on an existing mode, renamed options, or changed defaults — and any time the user says the help/README is thin, stale, confusing, or "an agent couldn't figure this out." Treats help text as an interface under test, not prose.

The English summary is being prepared. Showing the original description.

iopsystems/rezolus277Updated Oct 20, 2026

Use when starting or picking up a non-trivial effort (feature, investigation, perf probe, refactor, migration) in a shared repo where teammates or future agents must coordinate or hand off; when a repo has no durable in-tree record of decisions and dead-ends; when you're about to drop a well-measured negative result; or when bootstrapping a journal from a repo's commit history.

The English summary is being prepared. Showing the original description.

iopsystems/rezolus277Updated Oct 20, 2026

pr

Free

Create a feature branch, commit changes, push, and open a PR against iopsystems/rezolus

The English summary is being prepared. Showing the original description.

iopsystems/rezolus277Updated Oct 20, 2026

Tag and push a prerelease from the current Cargo.toml version. Use when the user wants to cut an alpha/beta/rc prerelease. Aborts on stable versions (no `-` in version string) and if the tag already exists.

The English summary is being prepared. Showing the original description.

iopsystems/rezolus277Updated Oct 20, 2026

Create a release PR with version bump and changelog update

The English summary is being prepared. Showing the original description.

iopsystems/rezolus277Updated Oct 20, 2026

Use when reviewing a Rezolus sampler change before merge — a new sampler, a change to an existing sampler's probes/refresh/metrics, or core changes that affect samplers; or whenever a sampler's overhead, cadence, or data source is in question.

The English summary is being prepared. Showing the original description.

iopsystems/rezolus277Updated Oct 20, 2026

See all skills by iopsystems

Report a problem with this skill