ソース情報
- リポジトリ
- iopsystems/rezolus
- ソースの最終更新活動
- 2026年7月17日 14:51
- 検出された SKILL.md の言語
- 英語
- スター
- 272
- フォーク
- 21
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/iopsystems/rezolus --skill sync-viewer-symlinksコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか?SkillsMP が現在取得できるファイルをダウンロードできます。
Use when adding or changing what the rezolus viewer exposes — an /api/v1 endpoint, a dashboard section, the metric catalog, metadata/description derivation, or the frontend data those depend on — or when editing src/viewer/ or crates/viewer/, or reviewing a viewer change. The viewer ships as two separate Rust backends (server + WASM) behind one shared frontend; changing one silently diverges them.
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.
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.
SOC 職業分類に基づく
SKILL.md を表示中
| name | sync-viewer-symlinks |
| description | Ensure site/viewer/lib has correct symlinks to src/viewer/assets/lib |
Synchronize symlinks in site/viewer/lib/ so that the site viewer picks up
all shared modules from src/viewer/assets/lib/.
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.
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 pointviewer_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.)
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.
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.
Scan src/viewer/assets/lib/ recursively for all .js and .css files
For each source file, determine the expected path in site/viewer/lib/:
script.js, viewer_api.js[ -e ])
via either a per-file symlink or a covering directory symlinkCheck 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/).
Create any missing symlinks. Create parent directories if needed. Report each symlink created.
Detect any stale symlinks in site/viewer/lib/ that point to
non-existent source files, and report them (but don't delete without
asking).
Stage newly created symlinks with git add.
Report a summary: how many symlinks checked, how many created, any stale links found.
A Claude Code hook at .claude/settings.json runs
.claude/scripts/pre-commit-check.sh before every git commit. It blocks
the commit if:
site/viewer/lib/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).