프로덕션 데이터 접근을 위한 N+1 쿼리 문제 해결 플레이북입니다. 코드가 루프 내에서 데이터베이스를 쿼리하거나, ORM이 행마다 관계를 지연 로딩하거나, 리스트 엔드포인트가 5개 행에서는 빠르지만 50개에서는 느린 경우 사용하세요. 실제 사례는 references/bad-vs-good.md에 있습니다. HTTP 계약 설계나 Go/JavaScript 언어 스타일에는 사용하지 마세요.
이 스킬은 ORM이나 루프에 의해 숨겨진 라운드 트립으로 인해 발생하는 N+1 쿼리 문제를 해결하기 위한 프로덕션 데이터 접근 플레이북입니다. N+1 문제, SELECT * 사용, 인덱스가 없는 쿼리, 페이징 없는 대규모 리스트 등 Rule 03을 위반하는 패턴을 방지합니다. 주로 ORM(예: Rails의 ActiveRecord, Java의 Hibernate)을 사용하는 코드베이스나, 루프 내에서 반복적으로 데이터베이스를 호출하는 애플리케이션에 적합합니다. references/bad-vs-good.md 파일을 참고하여 컬렉션에서 관계 로딩 전에 eager loading을 적용하거나, 일대다 관계를 페이징된 리스트에 조인하기 전에 반드시 검토하도록 안내합니다. 작업 완료 기준은 N개의 부모 리스트가 동일한 관계에 대해 N개의 쿼리를 발생시키지 않고, 쿼리 로그가 행당 하나가 아닌 고정된 수의 명령문을 보여주며, 페이지당 요청한 부모 수가 정확히 반환되는 것입니다.
npx skills add https://github.com/sshdkeyu/skill-prod-cursor/tree/HEAD/skills/data-accessRule 03은 최소 기준입니다: N+1 없음, 핫 경로에서 SELECT * 없음, 인덱스 기반 쿼리, 대규모 리스트는 페이징 처리. 이 스킬은 ORM이나 루프가 라운드 트립을 숨길 때 이 규칙이 어떻게 실패하는지를 다룹니다.
컬렉션에서 관계를 로딩하거나, 매핑을 eager로 표시하거나, 일대다 관계를 페이징된 리스트에 조인하기 전에 references/bad-vs-good.md를 읽으세요.
This repo contains 3 individual skills — each has its own dedicated page.
Design or review REST/RPC API contracts that are consistent, evolvable, and hard to misuse. Use when defining new endpoints, reviewing an API surface, or resolving naming/versioning/error-shape questions.
Rigorous, severity-ranked review of a diff, PR, or file. Use when you want a thorough check of correctness, security, performance, design, readability, and test coverage with actionable feedback.
Production Go playbook. Use when writing or reviewing Go: errors, goroutines, byte payloads, parsers, and switches on external input. Worked cases are in references/bad-vs-good.md. Do not use for JavaScript, TypeScript, or API-contract design.
ElevenLabs text-to-speech with mac-style say UX.
Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.
Capture and automate macOS UI with the Peekaboo CLI.
Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".
Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".