React/TypeScript component style guide. Use when writing, refactoring, or reviewing React components, especially around abstraction choices, props typing, state boundaries, shared local state with Jotai atoms, API types, query/mutation contracts, navigation, memoization, wrappers, and empty-state handling.

2026-06-17145.7k

frontend-code-review

langgenius/dify

Review Dify frontend code for correctness, accessibility, component design, dify-ui usage, data/query boundaries, performance, and tests. Trigger for `.tsx`, `.ts`, `.js`, UI, React, Next.js, pending-change, or focused frontend review requests.

2026-06-09145.7k

frontend-testing

langgenius/dify

Generate Vitest + React Testing Library tests for Dify frontend components, hooks, and utilities. Triggers on testing, spec files, coverage, Vitest, RTL, unit tests, integration tests, or write/review test requests.

2026-05-11145.7k

e2e-cucumber-playwright

langgenius/dify

Write, update, or review Dify end-to-end tests under `e2e/` that use Cucumber, Gherkin, and Playwright. Use when the task involves `.feature` files, `features/step-definitions/`, `features/support/`, `DifyWorld`, scenario tags, locator/assertion choices, or E2E testing best practices for this repository.

2026-05-11145.7k

backend-code-review

langgenius/dify

Review backend code for quality, security, maintainability, and best practices based on established checklist rules. Use when the user requests a review, analysis, or improvement of backend files (e.g., `.py`) under the `api/` directory. Do NOT use for frontend files (e.g., `.tsx`, `.ts`, `.js`). Supports pending-change review, code snippets review, and file-focused review.

2026-02-28145.7k

name	karpathy-guidelines
description	Lightweight coding guardrails for making focused, simple, and verifiable changes in this repo. Use for all coding work.

Karpathy Guidelines

Use this skill whenever you touch code in this repository.

Principles

Keep the change small and directly tied to the user request.
Prefer the simplest implementation that fits the existing codebase.
Read the nearby code first, then match its patterns.
Avoid unrelated refactors, broad rewrites, or style churn.
Preserve existing behavior unless the user explicitly asked to change it.
Treat regressions as a signal to narrow the change, not to add workaround layers.

Workflow

Inspect the current implementation and tests around the change.
Make the smallest coherent edit.
Add or update focused tests when the behavior changes or the risk is non-trivial.
Run the narrowest relevant verification first.
Report exactly what was verified and anything left unverified.

Review Checklist

Does this change solve the stated problem without expanding scope?
Did it preserve existing route/component/data-flow semantics?
Are new abstractions justified by real complexity?
Are tests focused on the behavior that could regress?
Are unrelated files and generated artifacts left alone?