Although I like the concept of what this checks I can't help but feel the interface / parameter is really awkward to use in practice. Combining the truthy conditions to achieve the assertions, although confusing, would work from what I can see. However this method returning false doesn't seem to have been considered.

CommandInteraction#inGuild(true); // false - does this assert that its not a GuildMember, but it could still be APIInteractionGuildMember | null? Used in this way it doesn't actually help you determine if this is a DM or not, at least not that I can see? I don't even know if you can have falsy assertions.

I think combining these into one method with a boolean parameter is where I'm finding it awkward. I feel like inGuild() should clearly assert the difference between a DM and a Guild, then a separate method should assert the existence of a bot user.

When this was brought up on the discord server I also thought of it as a separate method, the only issue is I wouldn’t know what to call it but if someone does then I think it would be a preferred scenario

Substantial changes have been made since this PR originally was opened, rather than just being able to narrow regular Interactions it now allows interaction sub types to be narrowed as well using conditional typings. This allows a much more robust type checking system for interactions. For example let's say I want to know if a command interaction is in a cached guild, given a base Interaction:

// Narrow two levels
if (interaction.isCommand() && interaction.isInCachedGuild()) {
  // interaction is now of type GuildCommandInteraction<'cached'>;
  ...
  // Because we are in a cached guild, we can intuitively narrow `Message | APIMessage` to `Message`
  const message: Message = await interaction.fetchReply();
}

It now can not only infer guild specific properties are of a certain type, but can also infer typings for methods specific to CommandInteraction.

Alternatively you can use the types to give expectations as to what your function recieves:

{
  ...
  // The command handler run method only accepts command interactions where the bot is in the same guild.
  execute(interaction: GuildCommandInteraction<'cached'>) {
    // No need to verify cached or not at this point, the parameter type guarantees it's in a cached guild.
  }
}

This eliminates redundant type checking/casts in areas where the developer knows the guild will be cached.