I normally start with implementing accept/acknowledge/resend logic.

First when the receiving end is able to deduce it has received a validated, new and unique message (and not a resend of the previous message because an ack was lost) is it meaningful to start implementing code to decode the received message and decide what it should be used for. This may then result in a further need to send back a complaint that the received message was correctly received but did specify an unsupported command or out-of-range parameters.

It is normally important to separate transfer errors (normally needing a resend) from unsupported messages.

And unsupported messages should normally not exists, for a master should have a way to for capabilities before even trying to send the messages.

It is also often good to let the slaves have a method to report if they have been rebooted - then a master can on-the-fly reconfigure them, without the need to store nonvolatile data in the slaves. One problem with nonvolatile data in slaves is that a swap of two slaves may result in strange behaviour.