사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/ewrogers/sgdk-skills --skill sgdk-best-practices시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
SGDK Best Practices
Make the important contracts visible: ranges, units, ownership, lifetime and failure behavior. Preserve the game's existing architecture and creative direction. These are implementation patterns, not a new engine or style guide.
Treat Labs as optional evidence for a specific technique. Explain the contract being reused and adapt it to the game; do not inherit a Lab's controls, progression, scene flow or module layout merely because working code exists. Whole-game copying is appropriate only when the developer asks for it.
Choose the relevant check
- C correctness: promotions, overflow, shifts,
alignment, aliasing and byte formats across host and target builds.
- Module boundaries: small interfaces, private state,
borrowed resources and partial initialization without a prescribed layout.
- SGDK ownership: sprite cleanup, queued DMA,
foreground/interrupt responsibilities and the selected compiler's defaults.
- Executable examples: checked arithmetic and byte
decoding, transactional sprite acquisition, and a copied palette upload.
Read the reference that fits the change; do not load every specialist manual. The examples build independently. Other installed SGDK skills are optional: sgdk-project owns setup, sgdk-math numeric representations, sgdk-scenes scene transitions, sgdk-performance profiling, and sgdk-debug fault diagnosis. This skill supplies the C and lifetime contracts underneath those workflows.
Apply a contract, then prove it
Before changing code, identify who calls it and what must remain true. Record units and valid ranges where they are not apparent. Distinguish borrowed data from owned resources and choose a useful response to exhaustion or invalid input. Do not silently change gameplay to accommodate a convenient implementation.
Check unfamiliar APIs against the headers and implementation in the selected ewrogers/sgdk:latest container. Pull it before validation and record the actual SDK/compiler versions. The references were checked against SGDK 2.11 and the container's GCC 16.2.0. C17 is the baseline; isolate SDK/GCC extensions at the boundary rather than assuming desktop and target ABIs match.
Keep public headers focused on the operations callers need. Hide internal state; avoid giving unrelated modules writable globals or raw ownership of SDK objects. A simple struct and a few functions may be sufficient. Preserve an established layout unless moving code solves a concrete dependency problem.
Test boundary values, rejected operations, repeated cleanup and recovery after failure. Run the portable parts as optimized host C, then compile the SDK-facing parts with the real SDK. Use target execution for ABI-sensitive behavior. Mocks check your adapter's contract; they cannot establish what SGDK actually does.
Treat C correctness, SDK requirements and optional conventions separately. Do not impose a universal ban on allocation, require hand-written assembly or copy a Lab's art, music, mood, tuning or genre rules into another project.
