karpathy-guidelines
This skill provides lightweight coding guardrails for the Dify repository, emphasizing small, focused changes tied directly to user requests. It establishes principles for simplicity and pattern-matching with existing code, includes a structured workflow for inspection and testing, and offers a review checklist to prevent scope creep and unintended regressions.
git clone --depth 1 https://github.com/langgenius/dify /tmp/karpathy-guidelines && cp -r /tmp/karpathy-guidelines/.agents/skills/karpathy-guidelines ~/.claude/skills/karpathy-guidelinesSKILL.md
# 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 1. Inspect the current implementation and tests around the change. 2. Make the smallest coherent edit. 3. Add or update focused tests when the behavior changes or the risk is non-trivial. 4. Run the narrowest relevant verification first. 5. 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?
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.
Refactor high-complexity React components in Dify frontend. Use when `pnpm analyze-component --json` shows complexity > 50 or lineCount > 300, when the user asks for code splitting, hook extraction, or complexity reduction, or when `pnpm analyze-component` warns to refactor before testing; avoid for simple/well-structured components, third-party wrappers, or when the user explicitly wants testing without refactoring.
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.
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.
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.
React/TypeScript component style guide. Use when writing, refactoring, or reviewing React components, especially around props typing, state boundaries, shared local state with Jotai atoms, API types, query/mutation contracts, navigation, memoization, wrappers, and empty-state handling.