메뉴
Maintain Repository classes — REST endpoints, route vars, cache coherence, typed collections, and persistence boundaries. Use when changing repository CRUD, cache behavior, or endpoint bindings.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/discord-php/DiscordPHP --skill repository-cache-keeper명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | repository-cache-keeper |
| description | Maintain Repository classes — REST endpoints, route vars, cache coherence, typed collections, and persistence boundaries. Use when changing repository CRUD, cache behavior, or endpoint bindings. |
Use this skill when work touches src/Discord/Repository/**/*.
This is cache-and-REST boundary skill. Load it when a change affects how parts are collected, fetched, persisted, cached, or routed to endpoints.
Keep repositories as:
Not as service dumping ground.
src/Discord/Repository/AbstractRepository.phpsrc/Discord/Repository/AbstractRepositoryTrait.phpsrc/Discord/Parts/PartTrait.php sections for getRepositoryAttributes(), getCreatableAttributes(), getUpdatableAttributes()src/Discord/Helpers/CacheWrapper.php and cache config code if cache behavior matterssrc/Discord/Repository/GuildRepository.phpsrc/Discord/Repository/Guild/ChannelRepository.phpsrc/Discord/Repository/Channel/MessageRepository.phpsrc/Discord/Repository/Interaction/GlobalCommandRepository.phpsrc/Discord/Repository/Guild/GuildCommandRepository.phpEvery repository centers on same shape:
AbstractRepository$class to the concrete part family$endpoints$discrim$vars route context from parent part or callerIf a method no longer feels like typed collection + route-aware persistence, it probably belongs elsewhere.
$classConcrete part family allowed in this repository. If wrong, hydration, type checks, and cache writes all become unsafe.
$endpointsRoute templates keyed by operation name. Typical keys:
allgetcreateupdatedeleteNot every repository supports every operation. Missing endpoint is an intentional capability statement.
$varsRoute-binding context. This is how nested repos know where they live:
guild_idchannel_idapplication_id, message_id, or other parent route piecesWhen repo behavior looks wrong, inspect parent part getRepositoryAttributes() first.
$discrimCollection key field, usually id. Only change when payload family genuinely keys on a different field.
$cachePer-repository cache wrapper. It is not optional frosting. Repo methods should keep it coherent with in-memory items.
create(array|object $attributes = [], bool $created = false)Builds local typed part using repository context plus attributes. No REST call. No remote persistence. Use it for drafts or hydration helpers.
save(Part $part, ?string $reason = null)Generic persistence path:
$part->created is false$part->created is truePart-level save() may wrap or redirect this when semantics demand it.
delete($part, ?string $reason = null)Remote delete plus cache removal. Accepts part or identifier. Keep typed return contract.
fetch(string $id, bool $fresh = false)Resolve from memory, then cache, then REST unless forced fresh. This is one of main async entry points. Keep it Promise-based.
fresh(Part $part, array $queryparams = [])Refresh a known created part from REST and update cache.
freshen(array $queryparams = [])Bulk refresh repository contents from REST. This is repo-wide sync tool, not a one-item fetch.
Repositories are hybrid objects:
get(), find(), first(), last()cacheGet(), cachePull(), fetch(), freshen()That dual nature is intentional. Do not flatten repository into only async map or only plain collection.
items can hold real parts, WeakReference, or null placeholdersEndpoint and bound varsRepository methods should bind route vars through Endpoint/Endpoint::bind(), not manual string interpolation spread across code.
If child repository starts losing route info, fix parent part getRepositoryAttributes() or repo constructor normalization, not random callers.
If a repo needs to clean or enrich vars for route correctness, constructor override is fine. Example patterns already exist:
MessageRepository unsets thread_id for thread message routingGuildCommandRepository injects bot application idAdd repo-specific methods when operation is broader than generic CRUD and naturally belongs to collection/route boundary.
Good examples:
GuildRepositoryGuildRepositoryChannelRepositoryBad examples:
$part->save() or $part->someAction()If code needs to know "is this current member or generic member", "is this webhook message or normal message", or "does bot need manage_messages here", that usually belongs on part side first.
$class$endpoints$discrimgetRepositoryAttributes()@method helpers if family uses themSome repos are intentionally small:
GlobalCommandRepositoryMessageRepositoryThat is okay. Not every repo needs custom methods.
If nested route shape is tricky, normalize vars in constructor instead of forcing every caller to know internals.
Methods like fetch() and get() preserve performance by preferring in-memory/cache before REST. Keep that bias unless correctness requires bypass.
Repositories are often updated from gateway events, not only from their own REST methods. When changing repository keying or cache semantics, inspect matching event handlers. If repository expectations change but event cache writes do not, the repo will look "randomly stale".
Common families to cross-check:
Stop if you see:
save()items updated but cache wrapper ignored, or reverse$class, $endpoints, $discrim, $vars still describe repo correctlygetRepositoryAttributes() still supplies needed route varsRepository code in this repo should feel boring in right way: typed, route-aware, cache-coherent, and predictable. If a repository starts making domain decisions or returning untyped transport data, pull it back to its real job.