with one click
interaction-flow-keeper
// Maintain interaction flow — Interaction typing, resolved data caching, command routing, autocomplete, modal responses, and interaction builders. Use when touching Interactions or slash command handling.
// Maintain interaction flow — Interaction typing, resolved data caching, command routing, autocomplete, modal responses, and interaction builders. Use when touching Interactions or slash command handling.
Maintain test and documentation alignment — PHPUnit tests, async testing patterns, PHPDoc contracts, guide pages, and documentation workflow. Use when adding tests, updating docs, or changing public behavior.
Maintain Builder classes — outbound payload construction, validation, serialization, component handling, and fromPart symmetry. Use when changing Builders or outbound Discord API payloads.
Maintain gateway event handlers — payload hydration, cache mutation, event return shapes, and handler registration. Use when touching WebSockets/Events, Handlers.php, or Event.php.
Work with DiscordPHP's infrastructure utilities — CacheWrapper, CacheConfig, BigInt, Multipart, Endpoint::bind URL templates, Collection base class, and domain Exceptions. Use when changing cache behavior, REST endpoint routing, file uploads, big-integer ID math, or adding/modifying exceptions.
Maintain the optional prefix-command layer — DiscordCommandClient, Command class, parsing, aliases, cooldowns, and help system. Use when touching message-based command handling.
Maintain Part domain models — fillable attributes, mutators, typed nested data, save/fetch behavior, permission checks, PHPDoc, and repository bindings. Use when adding or modifying any Discord Part class.
| name | interaction-flow-keeper |
| description | Maintain interaction flow — Interaction typing, resolved data caching, command routing, autocomplete, modal responses, and interaction builders. Use when touching Interactions or slash command handling. |
Use this skill when work touches:
src/Discord/Parts/Interactions/*src/Discord/WebSockets/Events/InteractionCreate.phpThis is typed-interaction flow skill. Load it when work affects how interactions are received, interpreted, routed, or answered.
Keep interactions as a coherent pipeline:
InteractionCreatesrc/Discord/Parts/Interactions/Interaction.phpsrc/Discord/WebSockets/Events/InteractionCreate.phpsrc/Discord/Helpers/RegisteredCommand.phpsrc/Discord/Parts/Interactions/Request/*src/Discord/Builders/CommandBuilder.phpsrc/Discord/Builders/ModalBuilder.phpsrc/Discord/Repository/Interaction/GlobalCommandRepository.phpsrc/Discord/Repository/Guild/GuildCommandRepository.phpInteraction flow in this repo has two distinct sides:
InteractionCreateInteraction::TYPES chooses concrete subtypeDo not mix inbound part modeling with outbound builder modeling.
Interaction::TYPES is centralIf Discord adds or repo adds support for new interaction type:
Interaction::TYPESInteractionCreateInteraction and its request data parts should expose:
through typed parts or typed collections where repo already has models.
InteractionCreate rulesThis handler is latency-sensitive and still responsible for cache correctness.
Preserve these patterns:
The handler already overrides some cache behavior to stay fast. Do not "clean it up" into slower generic behavior without understanding timing tradeoffs.
There is an interaction-specific registered command tree in RegisteredCommand.
Keep these facts straight:
CommandClient\CommandDiscord::listenCommand() populates application_commandsInteractionCreate routes slash/autocomplete events into that treeRegisteredCommand supports nested subcommand treessuggest()execute()If change touches application command routing, inspect both:
Discord::listenCommand() pathInteractionCreate callback routing pathWhen payload provides users or members:
When payload provides entitlements:
Do not assume interaction payload is only for immediate response. It also updates local state for later code.
Interaction code has less patience for extra work than many other gateway paths.
Prefer:
Avoid:
CommandBuilderModalBuilderInteraction defines response type constants. Use them to keep protocol semantics readable.
If interaction response uses components or modals:
type + data response shapeThey are different layers:
RegisteredCommand and interaction partsDiscordCommandClient and CommandClient\CommandDo not unify them by shoving shared semantics into wrong layer. Shared ideas may exist, but execution paths are different.
An interaction may reference a message, but it is not a message event. Keep response and request semantics on interaction types.
Stop if you see:
Interaction::TYPES updateInteraction::TYPES still complete for supported typesInteractionCreate still types, caches, and routes correctlyInteraction code in this repo is both protocol parsing and fast command routing. Keep it typed, cache-aware, and quick.