osn

Use when reading the session-performance cards to find where agent effort is going — running the report over `.claude/metrics/`, interpreting it without the traps that have already produced two wrong findings, and reporting what is actually supported. Also the step before proposing any change to how work is dispatched.

Use when starting a piece of feature or fix work in this repository — taking or opening its GitHub issue, cutting the branch (a worktree on the local bare repo, an in-place branch on the remote environment) and producing the implementation plan, including the wiki pages the work will make stale and its observability plan. Also the step for turning a tracker finding into a branch without publishing it.

Use when driving one or more tasks end to end from the local bare repo's `main` worktree — a feature designed with the user first when its scope is open, or a ready list of tasks — ordering them, cutting a worktree per task, handing each to a subagent that runs new-feat, running prep-pr with every finding fixed rather than reported, and shepherding each pull request to a squash merge and worktree teardown. Not for a one-file change, and not outside the bare repo.

Use when dispatching a subagent and choosing which one — mapping a task and its declared complexity to an agent definition, and so to a model and an effort level. Invoked by orchestrate when it hands off a task; also the answer to "should this run on a cheaper model".

Use when preparing the current branch for a pull request — resolving the base branch, checking changesets, running builds and reviews, filing findings as issues, and opening the PR with the mandatory five-section body.

Use when an issue needs its complexity declared — proposing a rating from the issue body alone and getting the owner to confirm or amend it, or backfilling a rating onto an existing unrated issue. Invoked by new-feat at issue-creation time; also the backfill path for issues opened before the label existed.

Use when running the retrospective on a piece of work that has just finished — the retro, normally the step straight after `prep-pr` opens the pull request — to write and commit the session-metrics card for the branch, read what the session actually cost against the difficulty declared before it started, and turn that into concrete changes to the skills, `CLAUDE.md`, the wiki, the tests or the brief. Also the owner of the card — nothing else writes one carrying the pull request's identity.

Use when a branch has finished and the session-metrics card is all that is wanted — writes, commits and renders the card, and stops. The card-only half of `retro`, for sessions running close to their token budget. Where there is room to think, run `retro` instead — this one deliberately produces no findings and changes nothing.

Use when auditing the monorepo's dependencies — every workspace package.json — for version drift between workspaces and for upgrades available on npm. Finds the packages whose declared ranges disagree, checks the registry for newer versions, classifies each upgrade against the waiting-period rules, reads the changelogs of the ready ones, and reports the package.json changes to make.

Use when reviewing the documentation a branch changes — CLAUDE.md, READMEs and pages under wiki/ — or sweeping the whole wiki with --full. Cross-checks every claim a page makes against the code, finds wikilinks and heading anchors the branch broke, checks frontmatter and page shape, and reports D-C/H/M/L findings in the four-field format.

Use when reviewing a branch diff for performance defects — redundant database round trips, N+1 queries, unbounded reads, per-request layer rebuilds, wasted client fetches, and build steps that ship a broken artefact — and reporting findings with P-C/W/I IDs in the four-field format.

Use when reviewing a branch diff for security concerns — auth, tokens and sessions, injection, secrets, cookies, CSP and third-party content — and reporting findings with S-C/H/M/L IDs in the four-field format.

Use when checking whether a branch is adequately tested — building and running the affected workspaces, then auditing changed code for missing test files, untested exports, untested error paths and untested routes — and reporting gaps with T-M/U/E/R/S IDs in the four-field format.

Use when setting up or repairing a development environment for this repository on a machine — Bun at the pinned version, the GitHub CLI and its auth, SSH commit signing and the recommended git config, workspace dependencies, lefthook hooks and the portless dev proxy — and verifying it with the type-check, lint and format gates. Also the place to start when bun, gh, turbo or a hook is missing or the wrong version.

Use when an implementation plan has just been written and before any code is written — hands the plan to a second model in a fresh context to attack it, then requires every finding to be closed or rejected in writing. Invoked by new-feat at the end of its planning step and by orchestrate once per phase, and worth running on its own for any plan whose assumptions have not been checked against the code.

Comprehensive guide for developing WebGPU-enabled Three.js applications using TSL (Three.js Shading Language). Covers WebGPU renderer setup, TSL syntax and node materials, compute shaders, post-processing effects, and WGSL integration. Use this skill when working with Three.js WebGPU, TSL shaders, node materials, or GPU compute in Three.js.