with one click
storybook
Use when writing or reviewing Storybook stories (`.stories.tsx`) for React components.
Menu
Use when writing or reviewing Storybook stories (`.stories.tsx`) for React components.
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Codex's capabilities with specialized knowledge, workflows, or tool integrations.
Prepare Langfuse weekly production reviews that explain what broke, what was fixed, what remains open, and where alerting or tracking needs cleanup. Use when asked for a production review, "what broke last week", fixed/open bugs, Datadog alerted monitors/pages, status-page incidents, incident.io incidents, or an engineering-team overview that combines Linear, Datadog, and customer incident signals.
Shared backend guide for Langfuse's Next.js, tRPC, BullMQ, and TypeScript monorepo. Use when creating or reviewing tRPC routers, public REST endpoints, BullMQ queue processors, backend services, middleware, Prisma or ClickHouse data access, OpenTelemetry instrumentation, Zod validation, env configuration, or backend tests across web, worker, or packages/shared.
Shared code review workflow for Langfuse. Use when reviewing a PR, branch, diff, or local changes for correctness, regressions, risk, and missing tests. Start with references/review-checklist.md for repo-specific review rules and use package AGENTS.md files plus any matching shared skills when the change touches those areas.
Security review patterns for Langfuse. Use during code review, design, or planning whenever a change accepts user-supplied URLs, host/endpoint/baseURL fields, secrets, cross-tenant data, new outbound HTTP requests, new integrations (webhooks, blob storage, LLM connections, image proxies), redirect-following behavior, or new auth/permission scopes. Covers SSRF/outbound URL validation today and is intentionally extensible to other recurring security findings (tenant isolation, secret handling, redirect mishandling, file upload, RBAC scope drift).
Use when building, changing, or refactoring large Langfuse frontend features, virtualized lists, large tables, controller components, local feature state, Zustand stores, row selection, high-frequency UI state, or rendering-performance issues.
| name | storybook |
| description | Use when writing or reviewing Storybook stories (`.stories.tsx`) for React components. |
Only create stories for components that do not do any of the following:
Stories should follow the ComponentName.stories.tsx filename pattern. Components covered by stories should have exactly one exported or public component.
If this is not the case, suggest splitting up the file that includes the component to be covered first.
Be mindful of the breadth a story covers. A story should show a component in isolation. Page-level compositions should be rare and intentional.
Suggest abstracting a presentational component that does not violate the criteria and receives relevant data via props.
Make sure the props are well-defined using TypeScript.
Keep the existing component, but update it to use the newly created component for rendering. These presentational components are easier to test and easier to reuse.
Use "CSF Next" format by default.
Cover only the relevant component by default.
Avoid custom render functions by default.
Use satisfies and typed Storybook metadata so invalid args, decorators, and play functions are type-checked.
Use play functions to test user-relevant interactions after render, not to compensate for complex setup or hidden dependencies.
Name stories after the state they represent, not the implementation. Also do not include the component name in the story name.
Default, Empty, WithLongName, Error, Disabled, LoadingTest1, CustomRenderExample, ButtonWithLongNameAndIconSet callbacks up as Storybook Actions by default:
import { fn } from "storybook/test";
Avoid large fixtures.
Use the smallest meaningful data shape needed to render the state.
If fixtures are required and may be shared, check whether a reusable helper function exists. Otherwise, create one for defining the fixture.
If a component has many variants, and the point of the story is to showcase the design of a component rather than its functionality, stories may render the component multiple times.
For example, a Button with a size: "sm" | "md" | "lg" prop may have a story that shows three buttons side by side.
If the button also has a variant: "primary" | "secondary" prop, consider using a matrix-like UI that showcases all possible combinations.
These compositional stories should not contain Storybook play functions. They should also not allow the Storybook user to customize the predefined args, such as size and variant, via Storybook args. Having an arg for non-bound props, such as text, may be acceptable.