Should I have it setup like this: if(mySerial.available() >3)...making sure there's 4bytes in the buffer? Or is that no good either?
That's better, but still not perfect. I'll try to explain why. Reading and acting on 4 values read from the serial port is fine, up to a point. Suppose that the serial buffer contains 'L', 120, 34, 95, 'R', 14, 126, 240. Now, if you test that there are 4 or more bytes, and read the first 4 bytes, you have all the data needed to control one LED, and you know which one to control.
But, this relies on serial data never getting lost, which is a bad thing to rely on. Suppose that the buffer contained 'L', 120, 34, 95, 'R', 14, 126, 'L', 120, 34, 95, 'R', 14, 126, 240.
Now, you'll read the L, 120, 34, and 95, and set the appropriate LED to the appropriate levels. There are still 4 or more bytes, so, you'll set collect the next 4 bytes, and set the right LED to 14, 126, and 'L'.
Hmmm, that might not be a really good idea. There are still more than 4 bytes, so, next you'd set the LED whose ID was 120 (there isn't one) to 34, 95, and 'R'. That doesn't look too good, either.
There are several ways around the problem. You could read 4 bytes, peek at the next one, that you might need to wait for, and, if it's a 'R' or 'L', you'd have reasonable confidence that the 4 bytes you read were good, and you'd use them. If not, you'd discard the 4 bytes, without using them, and read and discard any byte that was not a 'R' or 'L'.
The problem here, though, is that 'L' is 76 and 'R' is 82, both of which are perfectly reasonable values for the LED color level.
You could send the values, as packets, as strings, rather than bytes. "<R, 120, 34, 95>". Here, the start and end of the packet are clearly defined. If a start or end marker get lost, you have a way of recovering. If a byte within the packet is lost, it is either a ID, a delimiter, or part of a value. If a comma is lost, that is easy to detect. If the ID is lost, that is easy to detect. If a part of a value is lost, that is harder to detect (120 could become 12 or 20), but not impossible. You could add a length to the packet, and/or a checksum.
The tradeoff with sending values as ASCII strings is that it requires more bytes (which take longer to transmit) and requires more processing to turn "120" back into 120.
It comes down to the speed you need, and the risk you are willing to accept.