I originally attempted this before switching to the costume method because I couldn't figure out how to access a clone's local variables, thank you for a little more insight into how that works, and thank you for remixing this.
Actually, Jens has the power to make it one-step-process only.
Here's how. When user drags the 'of' block from the sensing category to a sprite's scripting area, the second slot could be defaulted to the sprite itself so its local variables would be automatically listed in the first slot.
Point is that you shouldn't ever design your program to need accessing a local (!) variable - or any local state - of another sprite. I get that y'all have been brainwashed into believing that controlling everything from a single script is somehow "elegant" or "expressive" or "how the real programmers do it", but ... it's not! Instead signal an event and let interested sprites react to it. Instead ask/tell the clone to do something, and let it handle the response. Before I get flamed for writing this: Yes, I know you can do it in Snap and I'm not telling you not to, but if you insist on doing it wrong I might as well nudge you to at least do it in two steps.
The stone can be added back. (In the first remix when I was testing a "local variables approach" instead of a costume name one, I probably removed the stone to be able to test a smaller amount of code).