JellyRock

Session-start briefing: where did I leave off, what is in flight, what needs attention. One tested script reads git, the journal (followups, running work, cadences) and tracked projects and prints every fixed-threshold check that fires; JellyRock's own aggregator adds open PRs, high-engagement bugs, recent bug reports, current-branch CI, pending handoffs, open upstream-watch issues (Jellyfin releases and release candidates, Roku OS), recent ADRs, tech debt and architecture-doc staleness. Ends with one Suggested next move that hands off to /log, /done, /issue-triage, /runtime-triage, /ci-triage or /server-upgrade. Mandated by AGENTS.md's catchup-discipline rule: run at the start of any genuine new session, after a multi-day gap, or whenever you ask what the state of the world is.

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

Diagnose a failed CI workflow run and fix it the /snag way. A tested read-only script fetches the run, reports every failed job and step with the log region around its errors (not the post-job cleanup), and classifies each against this repo's gates.tsv, printing the banner a gate carries when its obvious fix is the wrong one. Then: re-run only what is transient, reproduce locally, find the root cause, and show one decision screen; the chosen fix is built test-first and committed on a fix branch, never pushed. Use when a CI run failed on a pull request or on the default branch.

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

DEPRECATED, replaced by the `enrich` phase built into /crash-report. The old flow filed crash issues first and enriched them one by one afterward. The new flow (stage, then enrich, then file) pulls the dashboard backtrace before filing, so issues are born complete and architectural-class crashes go to their epic instead of becoming standalone issues. Do not invoke it for new work: run /crash-report and paste the backtraces during its enrich step. It stays only as a redirect; the `enrich-issue` script subcommand still exists as a legacy escape hatch for a crash issue filed before the change.

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

Process a Roku weekly crash-report CSV (or a zip holding one or more CSVs) into tracked GitHub issues and architectural-epic evidence, enriching before filing (stage, then enrich, then file). STAGE parses and filters the CSV, groups by pkg-path signature, builds each cited app version in a temporary git worktree, maps the transpiled `.brs` line back to the source `.bs` line, runs the GitHub dedup search, and writes a local worksheet where every crash starts pending; a mechanism hint (task-launch, network, other) orders which to pull first but never authorizes a file. ENRICH folds in the per-crash backtraces you paste from Roku's dashboard (a 7-day window, one click per crash, no bulk export), extracts each `&hNN` exception code, and routes every crash to a disposition (nothing files or aggregates without a backtrace): `file` (a scoped bug becomes a new per-signature [crash] issue, born enriched), `aggregate` (a known architectural class: `&h29` big-library too-many-task-threads, `&h23` render-thread execution timeouts, the `&hec` init `m.global.constants` race; upserted as one flat record comment per `file·function·line·version` onto the class epic, never a standalone issue), or `watch` (accepted noise, a spike comment only). FILE performs the GitHub writes (create, comment or reopen for scoped bugs; the epic record upsert for architectural classes) and writes a run-summary handoff. Dedup-aware and idempotent. Use when a fresh Roku crash CSV arrives (weekly). A deep dive on one crash goes to `/issue-triage <N>` after filing.

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

Draft a GitHub issue body for the JellyRock repo from a Reddit/Discord post or free-form bug report and submit it via forge.sh. Reads the YAML form templates under .github/ISSUE_TEMPLATE/ to know which fields are required, fills them by extracting from the input, asks for any missing required fields, validates the body matches the chosen template's schema, then runs forge.sh issue create with the auto-labels the template defines. Use when you have a user report (paste from anywhere) and want to formalize it into a properly-structured GitHub issue.

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

Walk a major dependency-version bump (a Renovate major PR, possibly a grouped one carrying several deps, or a package you name) through JellyRock's major-bump SOP so the judgment steps run the same way every time. Resolves each package and its from and to versions, fetches the upstream changelog/migration guide for that range, classifies the breaking changes, greps the codebase for the call sites those breaks actually hit, runs the mechanical gate that fits the dependency's type (a runtime BrightScript lib: validate, build, lint:bs, then test:unit and test:rta on a device; JS or Node tooling: test:scripts, then run the affected script; GitHub Actions: the PR's own CI plus a trace of the conditional paths CI doesn't exercise), and returns a go/no-go with any required migration surfaced (and applied on request). Majors never automerge (the org Renovate config), so this is the human-review path. Use when a Renovate major PR appears, or before bumping a dependency's major version by hand. Not for patch or minor bumps (those automerge after a soak) or for Jellyfin server releases (use /server-upgrade).

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

Run JellyRock's docs governance checks (broken markdown links, link anchors that match no heading, broken related-files frontmatter paths, stale tech-debt anchor references, journal-schema gates for progress.md and the decisions.md supersede chain, stale-doc detection) and surface a structured fix list grouped by category. Consumes the --json output of scripts/lint/docs-check.cjs and the human-readable output of scripts/lint/docs-stale.cjs. Use when a commit hits the docs-lint pre-push hook, before pushing a PR that touched docs/ or any CLAUDE.md, or when you want a one-shot pass over doc references.

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

Mark journal work complete: close an existing followup by its fid, or ship the in-flight `running` cursor. Companion to /log, which captures new entries; /done closes existing ones. Finds the entry, proves the work actually landed, then closes it: a followup through the journal script (the entry is removed; git is the history; on main it also gains a Recently shipped line), the cursor by a direct edit. Nothing is committed on its own: the closure rides in the commit of the change that prompted it. No confirm gate on a proven closure. Pure local-file edits, apart from read-only checks that the work landed. Use when the work an entry describes is committed on this branch (pushed or merged is not required, since the closure rides in the same change set) and its journal entry needs closing. Not for capturing new entries (use /log), and not for work that is still uncommitted, undeployed or partial (don't pre-mark optimistically).

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

This skill should be used when the user explicitly types "/end-session": the mandatory final step of any session started or resumed with /start-project or /resume-project, which the agent prints alone in its own block as the session's last line for the user to type, never invoking it directly. It updates the active project's PLAN.md (Status, kickoff, log), checks the PLAN against itself, and commits+pushes. Do not auto-invoke on vague phrases mid-session.

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

Session-start orchestrator for JellyRock. Reads the same `scripts/catchup-state.js` state `/catchup` uses, ranks what is actionable by a fixed order, recommends the single best next move (the rule that picked it, the state behind it, 1-3 alternatives), and hands it off by printing the one command to type: `/resume-project <slug>` for a tracked project, `/start-project` for project-shaped new work, a skill that covers the pick (`/ci-triage`, `/issue-triage`, `/runtime-triage`, `/server-upgrade` for investigations; `/new-setting`, `/new-migration`, `/new-api-version`, `/translation-add` for recurring "add an X" work; `/done` or `/log` for a journal fix), or, for an ad-hoc one-off, a researched, fork-free plan (forks asked in chat, saved to `.claude/plans/`) run by a Sonnet sub-agent that `/focus` supervises and reviews. Recommend-then-confirm, one command per route. Use at the start of a session when you want the next move picked rather than a state dump; `--area=<name>` scopes it to a subsystem. Distinct from `/catchup` (state briefing, never picks) and `/ramp` (area deep-dive briefing).

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

Investigate one GitHub issue and act on it the /snag way. Fetches the issue and its comments, first checks it is still true (everything it names still exists), reads it through the repo's issue forms, classifies it (bug, feature, enhancement, or a design decision), checks whether it is real, reproducible and not already fixed, maps it to an area, reproduces it and finds the root cause, then shows one decision screen; the chosen fix is built test-first and committed on a fix branch, never pushed. Anything posted on the issue is drafted and shown first. Use when you have an issue number you want to act on.

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

Single-entry-point capture for the journals this repo keeps: `decision` (agent-gated: ADR-grade becomes a numbered record in `docs/adr/`, sub-architectural a note in `docs/decisions.md`, trivia is declined; `--revise=<slug>` corrects a note that misdescribes what shipped, which is not a supersede), `followup` (an open entry in `docs/progress.md`, written by the journal script with a permanent fid; `--area=<name>` picks its category; an upstream to watch is a followup too, since CI opens an issue for Jellyfin and Roku OS releases) or `running` (the `## Currently running` paragraph in `docs/progress.md`). Routes by the first argument. Mechanical types apply directly with no confirmation prompt; `decision` is agent-classified: the agent drafts, applies a significance gate (architectural / hard-to-reverse / cross-component?), routes it, and shows a diff-and-confirm before writing, with one-tap human override. The only sanctioned write path for these journals. Pure local-file edits; it commits nothing, the change that prompted the entry carries it. Use when you have something to write down. NOT for status flips on existing entries (use /done) and not for half-formed thoughts (refine first, /log once the shape is clear).

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

Guided workflow for standing up a new Jellyfin apiVersion tier (V3, V4, …) in JellyRock when an upstream release restructures the API enough to need a new `if m.getApiVersion() >= N` dispatch level. Wraps the "Add an API tier" recipe in docs/dev/jellyfin-server-versioning.md and walks every surface that must move together (the boundary map in YAML, its BrightScript twin `resolveApiVersion()`, the `sdkVN.bs` endpoints, the dispatch branches, the device profile, the manifest tier clamp, and the validators), stopping at each step so the tier split cannot land half-built. Use when proactive RC/master triage (via `/server-upgrade <rc-or-unstable>`) shows a breaking API shift that a per-method `>= N` branch must cover. Not for routine endpoint additions inside an existing tier (those use the existing `>= 2` shape directly).

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

Guided workflow for writing a registry migration in JellyRock when a setting key is renamed, removed, or its data shape changes. Walks docs/dev/registry-migrations.md (add a version constant, add a guarded block to the runner for the right scope in source/migrations.bs, update the code that used the old name, write a real-registry integration test, run it on hardware). Use when an existing setting changes shape; brand-new settings don't need migrations and should use /new-setting instead.

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

Guided workflow for adding a new user setting or global setting to JellyRock. Walks the recipe in docs/dev/new-user-setting.md (pick the kind, add the settings/settings.json entry, add its strings, add the JellyfinUserSettings field, read it in code, test it). Stops at each step to verify and gives the user the relevant file paths. Use when adding a toggle, a choice, a number or a text setting that the user can change in the JellyRock Settings screen.

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

Create or update a pull request: a typed title (`fix:`, `feat:` … from `scripts/lib/pr-title.js`, which places the change in CHANGELOG.md), category labels chosen by judgment, a concise body from `.github/pull_request_template.md` that reads as the squash commit message, and one skill-owned "review notes" comment for the detail reviewers want but `git log` doesn't. Detects an existing open PR for the current branch and routes to update-mode (diff title/labels/body/comment, ask, then apply) instead of duplicating; aborts cleanly on merged/closed PRs. Scans branch + commits for related issues, falls back to `gh` issue search, surfaces architecture docs whose related-files were touched, and runs the four-pillar judgment passes (tech-debt scan, decision-shape detect, followup capture) so journal hygiene is part of shipping rather than a separate manual step. Required for all PRs in this repo; it supersedes any default PR-creation flow.

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

Area-scoped deep-dive briefing for context-switching into a JellyRock subsystem. Loads the scoped CLAUDE.md, the matching architecture topic doc, area-relevant tech-debt slugs, recent commits scoped to the area, and skills/agents that mention the area. Use when switching into `components`, `components/video`, `components/data`, `source`, `source/api`, `source/utils`, `tests`, `locale`, or `scripts` after >2 weeks not touching it, or when a sub-agent needs scoped briefing before research. Complements /catchup (which is global).

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

This skill should be used ONLY when the user explicitly types "/resume-project" (optionally with a slug). It loads an existing tracked project under docs/projects/ and the surrounding context so work can continue cleanly, using the project's Next-session kickoff as the starting prompt. Do NOT auto-invoke when the user merely opens the repo or mentions past work.

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

Triage a JellyRock runtime failure (crash, freeze, unexpected behavior) from a pasted Roku log / crash report end-to-end. Parses the log, classifies the failure category (render-thread-crash / task-crash / api-error / registry-corruption / nav-error / unknown), maps to the probable code area, writes a handoff packet to `.claude/handoffs/`, and continues into the investigation contract at sibling [`INVESTIGATION.md`](INVESTIGATION.md). No dedup check: each runtime log is unique. Use when you have a Roku BrightScript log, debug-console output, or a crash report.

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

Get a second opinion from a reviewer with a clean context. Runs only when the user types /second-opinion (with what to review), or replies second-opinion on a decision screen; never on its own. One item comes back improved (ranked problems with evidence, fixes, what is missing); several come back compared without bias (neutral shuffled labels, criteria written before the options are seen, a winner and what would flip it, an option nobody listed). The report is shown word for word, then a point-by-point response, then the screen again with changes marked. NOT for bugs in a code diff (use /code-review) or for how a skill ran (a skill audit).

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

Triage a Jellyfin server release against JellyRock's API usage. CI opens one digest issue per release; this skill reads the data report (`.api-watch/cache/findings-candidates-<from>..<to>.json` from `npm run api-watch:findings`, built here if missing), investigates each candidate by reading the app code it cites, resolves the edge cases the design doc lists (a spec break that is not a runtime break, a capability guard or dispatch branch that covers it, a spec-regeneration artifact, an enum change, graceful degradation, whether an opportunity is worth it, floor coverage, removal versus rename), and writes a verdict per finding. Then `scripts/server-upgrade.js` runs scaffold, plan and execute: it dedups against existing `[server-upgrade]` issues, files each `file` verdict as a sub-issue of the digest, notes the skip and monitor verdicts on the digest, rewrites its checklist and closes it once every finding has a verdict. Nothing files without one approval per release. Post-floor endpoints the endpoint-availability ledger covers (MediaSegments, Lyrics, QuickConnect) do not come back every release. Use when a new Jellyfin stable release lands and you want to know what, if anything, it breaks for us. Release candidates and unstable/master builds take a local path: the report is built in memory, findings go to a `.claude/handoffs/` note, and nothing is filed on GitHub until the stable release.

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

Handle a flaw found mid-work without switching gears. Start it the moment a defect, bug, gap or regression surfaces while doing other work, BEFORE any fix is drafted. A trivial slip is fixed on the spot. Anything else is investigated read-only (reproduce, root cause, history of the broken lines, what depends on it), then shown on one decision screen with the candidate fixes, a recommended fix and a recommended timing. The user picks a fix to build now (test-first, committed, never pushed) or files it as a pinned followup (asap) or a plain one (later). Not for picking the next task (use /focus), saving a thought unexamined (use /log), or a pasted Roku log, failed CI run or issue that has its own flow (use /runtime-triage, /ci-triage, /issue-triage).

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

Execute a procedural implementation plan on the Sonnet model for token savings. Runs when the user types /sonnet with a plan path, or as a Sonnet sub-agent that a parent (usually /focus, right after it saves the plan) starts and supervises. Checks the plan is for this repo, walks its Approach literally, runs its Verification, commits, records the landing in the plan's project, and stops before push for an explicit OK. Not for judgment-heavy work: if the plan still has open forks, architectural decisions or "we need to figure out X" gaps, stay on the judgment-grade model and finish the planning first. Not for investigation or recipe work that has its own skill (/ci-triage, /issue-triage, /new-setting and the like): the recipe is the better plan.

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

This skill should be used only when the user explicitly types "/start-project" (optionally with a slug). It begins a new tracked JellyRock project under docs/projects/, running scaffold-project.sh to create PLAN.md from docs/projects/_TEMPLATE.md and index it in the projects README, then walking the user through the Charter. For multi-session work that crosses a phase boundary or carries a decision worth recording as an ADR in docs/adr/. Do not auto-invoke on vague phrases like "let's start something"; for a single-session fix just do the work and capture any tail via /log followup.

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