Some random thoughts on what we've learned since moving to scaled agile at my work:
The more stories you write, the better you get at writing them. It's a skill, and the more you practice, the better they get.
Be careful not to get lazy and take shortcuts in writing the stories, or that behavior will continue, and will get worse, leading to stories that are incomprehensible. If you write crappy stories, you probably end up with crappy results.
Write the stories with the assumption you will win the lottery and not be around to perform the work, with the corollary that, if there are multiple teams around the world, your team won't be doing the work, so a good story makes it possible for whoever does the work to actually meet the requirements.
Don't skimp on testing criteria. Sure, no one likes writing those, but they are as important as writing a good story. When new code goes to user acceptance testing, the only failures should be for edge cases no one on the development team though of. If a user starts testing, and the program dies immediately, your credibility takes a big hit.
Try to avoid tying sizing to hours of work. It will always be wrong.
I read the book User Story Mapping a couple of years ago. The one concept that stuck in my mind is building shared understanding. That's super important. Otherwise you end up with the results in the comic in the Paul Andrew blog post.
Team members should review stories during refining sessions or during continuous exploration meetings. Provide feedback in good faith, and don't take feedback as a personal attack.