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?
Use only when the user explicitly requests a review or audit of backend code under `api/`. Supports pending-change, file-focused, and pasted-diff reviews. Do not use for implementation-only requests, diagnosis without review intent, frontend code, or backend code outside `api/`.
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.
Use when writing, changing, or reviewing Cucumber and Playwright tests under `e2e/`, including feature files, step definitions, support code, scenario tags, locators, and assertions. Do not use for Vitest, React Testing Library, backend tests, or generic browser automation outside the E2E suite.
Use only when the user explicitly requests a review or audit of frontend code under `web/` or `packages/dify-ui/`. Supports pending-change, file-focused, and pasted-diff reviews. Do not use for implementation-only requests, diagnosis without review intent, or backend-only code.
Use when writing or changing Vitest or React Testing Library tests under `web/` or `packages/dify-ui/`, or when the user explicitly requests frontend test strategy, including evaluation of an existing strategy. Do not use for frontend code-review-only requests, general testability discussion, Python tests, or Cucumber/Playwright E2E.
Use when implementing or refactoring React/TypeScript components and the task requires decisions about component ownership, feature boundaries, state, data flow, effects, or interaction ownership. Do not use for review-only requests, test-only work, copy-only edits, or styling-only changes.