rse-plugins

Use when work context must transfer to another session or person. Triggers: create a handoff, hand off this work, summarize context for the next session, prepare a handoff.

Use when a result, experiment, or analysis must be reproducible by others or by a future session. Triggers: make this reproducible, capture provenance, pin the environment for this result, why can't I reproduce X.

Use when research or scientific code must be trustworthy — verifiably correct, regression-safe, and numerically stable. Triggers: harden this code, is this numerically correct, add regression tests vs known results, make the research code robust.

Use when an approved implementation plan (a docs/rse/specs/plan-*.md file) exists and the next step is writing the code. Triggers: implement the plan, execute the plan, start building, run the plan.

Use when an existing implementation plan needs changes before or during execution. Triggers: update the plan, change the plan, add a phase, revise scope, incorporate experiment results.

Use when a feature, refactor, or multi-file change needs to be designed before coding. Triggers: plan X, design the implementation, how should we build X, create an implementation plan.

Use when you need to understand how an existing codebase works and/or survey external prior work (papers, methods, tools) before planning or changing something. Traces function call paths, maps module dependencies, searches academic papers and documentation, compares library alternatives. Triggers: research the codebase, how does X work, where is X implemented, what tools or libraries exist for X, prior art on X, has this been done before, survey approaches to X.

Use when the best technical approach is genuinely uncertain and a head-to-head prototype comparison is needed before committing to a design. Triggers: should I use X or Y, compare approaches, benchmark, which is faster or simpler.

Use when starting or continuing ANY research-software task — understanding or modifying code, surveying prior art, planning, experimenting, implementing, validating, reproducing, or hardening — and before reading code to "just check", before editing, or before answering "how does X work". Triggers: research workflow, which skill should I use, where do I start, guide me through the workflow, structured development.

Use when an implementation is (claimed) complete and must be checked against its plan before shipping. Triggers: validate the implementation, verify it matches the plan, is the implementation correct, check before PR.

Manage scientific Python dependencies and environments with the pixi package manager: create environments, add conda-forge and PyPI packages, define and run tasks, and generate reproducible multi-platform lockfiles. Use when the user mentions pixi, pixi.toml, pixi.lock, pixi init/add/run, conda-forge, or needs reproducible scientific Python environments combining conda and PyPI packages.

Dependency and lockfile supply-chain security review with 2025–2026 attack campaign patterns. Use when reviewing package.json, pyproject.toml, requirements.txt, pixi.toml, conda-lock.yml, or any lockfile; when evaluating a new dependency for addition; or when responding to a supply-chain compromise incident. Contains patterns for detecting maintainer-account-takeover style attacks that CVE scanners miss.

Ecosystem-specific supply-chain gotchas for npm, PyPI, conda/pixi, cargo, and Go. Use when reviewing package.json + .npmrc, pyproject.toml + setup.py, pixi.toml + conda-lock.yml, Cargo.toml + .cargo/config.toml, or go.mod + GOPROXY config — any time a supply-chain recommendation depends on which ecosystem you're in. Loads ecosystem-specific reference docs on demand.

Hardened GitHub Actions release workflow patterns for supply-chain security. Use when reviewing or writing GitHub Actions release workflows (.github/workflows/*.yml). Contains SHA-pinning, OIDC trusted publishing, two-job build/publish split, --ignore-scripts, Pwn Request prevention, deny-by-default permissions, and egress hardening patterns. Triggered by March 2026 TeamPCP campaign that specifically hijacked release tags.

Incident-response runbook for supply-chain compromises. Use when an advisory, CVE, GHSA, or campaign report names a dependency or GitHub Action this project uses; when responding to a Shai-Hulud-style maintainer takeover; or when a TeamPCP-style tag hijack is reported. Walks the lockfile-check → CI-cache-check → secret-rotation → persistence-artifact-hunt 4-point check end-to-end.

SBOM generation and provenance verification for research software releases. Use when reviewing or writing release workflows that publish to PyPI, npm, GHCR, or similar registries; when verifying a downstream artifact's signatures or attestations; or when evaluating SLSA level for a release pipeline. Covers CycloneDX/SPDX SBOM generation with syft, Sigstore keyless signing with cosign, npm provenance, and SLSA build levels.

Supply chain threat posture assessment for projects and packages. Use when reviewing a project's .github/workflows/*.yml, package.json, pyproject.toml, requirements.txt, pixi.toml, or lockfiles for exposure to active 2025–2026 campaigns. Covers Shai-Hulud (500+ npm packages), TeamPCP (Trivy, Checkmarx, LiteLLM, Bitwarden CLI, SAP CAP via tag hijacking), axios (100M weekly downloads), and LiteLLM .pth persistence — all attack patterns CVE scanners miss.

Use when designing or analyzing an A/B test, calculating sample size for an experiment, evaluating whether a variant won, debugging surprising experiment results, or choosing between frequentist and Bayesian analysis for a design change.

Use when auditing a web interface for WCAG 2.2 AA/AAA compliance, fixing reported accessibility violations, verifying ARIA usage, checking keyboard navigation or color contrast, or preparing accessibility documentation for a release.

Use when defining a brand color palette, generating accessible shade scales, mapping semantic color tokens, building dark mode variants, or validating WCAG contrast compliance across a color system.

Use when implementing or extending a shared component library — scaffolding new components with CVA variants, writing Storybook stories, wiring visual regression, or auditing existing components for state and a11y coverage.

Use when starting a new frontend project and choosing a CSS approach, refactoring inconsistent CSS, hitting specificity wars, integrating a component library, adding theming/dark mode, or deciding between BEM, Tailwind, CSS Modules, or CSS-in-JS.

Use when analyzing a product's UI/UX to extract transferable patterns, benchmarking your own design against a category leader, looking up how a specific product (Stripe, Linear, Notion, Apple, Spotify, Netflix, Tinder, Airbnb, etc.) solves a design problem, or building a competitive teardown.

Use when packaging a design for developer implementation, writing component specifications, running design QA against a built UI, exporting assets from Figma, or resolving design-vs-code drift before a release.

Use when running a heuristic evaluation, structuring a design critique, selecting which design framework to apply for a given project context, or auditing a UI against Gestalt/Nielsen/Rams principles.

Use when bootstrapping a new design system from scratch, auditing an existing UI for systemization, setting up Storybook + Style Dictionary scaffolding, or defining governance and versioning for a shared component system.

Use when implementing or refactoring design tokens, setting up Style Dictionary, defining a three-tier token architecture, wiring multi-platform output (web/iOS/Android), or auditing existing tokens for naming and reference integrity.

Use when implementing or scaffolding a reusable UI component in React, Vue, Svelte, or Web Components/Lit; when porting a design across frameworks; or when a component needs hooks, composables, reactive state, slots, or shadow-DOM encapsulation.

Use when laying out a page or component, choosing between CSS Grid and Flexbox, setting up a column grid, aligning nested components to a parent grid, or building responsive card/dashboard layouts.

Use when structuring a new site/app's content, when users report "I can't find anything," when running a card sort or tree test, or when auditing navigation labels and taxonomy for an existing product.

Use when adding or fixing UI animation, choosing duration/easing for a transition, debugging janky motion, implementing micro-interactions or page transitions, or auditing motion for prefers-reduced-motion compliance.

Use when building or refactoring an interface that must work across phone, tablet, and desktop; setting breakpoints; sizing touch targets; serving responsive images; or testing layout across viewports.

Use when building a new type scale, converting fixed sizes to fluid clamp() values, choosing or pairing fonts, fixing readability issues (line height, measure, tracking), or encoding typography as design tokens / CSS custom properties.

Use when auditing an existing interface for usability issues, when running a heuristic evaluation or cognitive walkthrough, when scoring an SUS survey, or when prioritizing UX bugs by severity.

Use when visualizing a user's end-to-end experience for a specific scenario, identifying pain points and emotion lows, aligning teams on user flow, planning improvements to onboarding/checkout/support, or producing a service blueprint.

Use when planning or running user interviews, building personas or JTBD job stories, designing a competitive audit, synthesizing research data, or framing insights and How-Might-We questions for ideation.

Use when writing or auditing UI copy — button labels, error messages, empty states, onboarding flows, confirmation dialogs, tooltips, success toasts — or when establishing voice and tone documentation for a product.

Use when designing or coding a new interface that needs a distinctive aesthetic direction, when reviewing visuals for hierarchy/brand alignment, or when an existing UI feels generic ("AI slop") and needs production-grade visual polish.

Use when sketching a new screen before visual design, when restructuring an existing page's content priority, when validating layout feasibility with engineering, or when communicating responsive behavior across breakpoints.

This skill should be used when the user asks to "develop a download script", "debug data download", "fix download error", "create data pipeline template", "download template", "GAIA data pipeline", "download from S3", "access Zarr store", "cloud data access", or mentions specific data source names like "CONUS404", "HRRR", "WRF", "PRISM", "Stage IV", "USGS", "ORNL", "DEM", "Synoptic", or "IRIS" in the context of downloading or processing data. Provides templates, configuration validation, and debugging guidance for hydroclimatological data download scripts used in the GAIA project.