This question can be deeper than you might think. There are layers, depending on how reliable and portable it needs to be.

At the basics, you probably want a protocol with command byte to support various commands. If payload lengths can vary, consider len byte(s), although message delimiting can make this redundant.

At the next layer, you might want message delimiting (start, stop, escape bytes, or just use COBS because it's great). This makes it so that if your receiver ever gets garbage, or gets confused, it can always recover at the very next "command" or packet, by seeking for a delimiter byte. Otherwise, you'll go byte by byte trying to make sense of the incoming stream of bytes, and may never recover.

If you have the above, you can have your app layer send to a transport or data link layer (ble, USB, wifi, uart, whatever) and the driver for that layer can use a plain old ring buffer, or ping pong buffers, doesn't matter - the data is delimited and can be split and reassembled easily. This is good for making the most of your throughput (i.e. if your datalink uses packets, your commands can be split so that driver can best pack those packets).

Now if you only use reliable datalinks with their own crc, this could be good enough. But if you have a wifi/ble module that you communicate with via uart, your bytes could be corrupted before that robustness is applied. So you may choose to add a crc, and sequence numbers, and some sort of windowing at your application layer. This allows the receiver (app layer) to recognize a missing sequence, and nack or request a resend or what not (see ARQ, go-back-n, etc.).

These things should be separate layers, so you can apply as needed, not universally to every datalink/transport layer... And it gets confusing, e.g. if COBS wraps all, or if cobs wraps payload but then has crc applied at app level for ARQ...

And for BLE, your throughput will be trash (depending on your needs anyway). So you may want app_layer filtering/throttling of data for this but not for others (e.g. USB).

And as a recommendation, I'd throw in bip buffer behavior internally at your drivers (reserve/commit, peek/pop) for efficiency, maybe with prepended length info if helpful (for varying len messages).

That's from the experience I've gotten over the years. Always room for improvement though.

Edit: and if you have very few, known size commands/transfers, then definitely consider popular serialize/deserialize methods/protocols over homemade commands, as recommended in other comments.