How can I create solid standardizations for creating user stories that will drive impact?

Improving the bug triaging process is something I'm very familiar with (I spent a lot of my career working closely with QA), so I have a lot of thoughts here. Before I go through anything though, I want to be clear that you should set your expectations realistically as you're working at a startup. A startup is going to value velocity above all else, and even if everyone wanted to refine a system, startups often don't have the infrastructure to do so. Adding process is often the enemy of speed as well - There's a good chance you won't get everything you want in this interaction.

That being said, I imagine the process should be something like this:

1. Figure out who is forwarding you these bugs - I'm assuming it's either a QA person or some project manager. Or maybe it's automated.
2. Talk to the person from Step #1 and deeply understand their situation - In particular, figure out what kind of information they have access to. There's a good chance these bugs are lacking context because the surrounding information simply isn't there.
3. Create a proposal to improve this process, weaving in your learnings from Step #2 - For example, if the person filing the bugs already has the email/user ID of the relevant users and simply isn't attaching that information, your proposal can call this out and recommend doing so. This proposal should be a well-written document.
4. Run your proposal by the team - Set up a meeting, share the proposal in the invite, remind everyone to read it before the meeting, and use the meeting to reach a consensus.

Ultimately, this entire situation is a big exercise in communication, so I highly recommend going through my Effective Communication Series if you haven't already.

In terms of what a good bug report/task would have, I largely agree with what you put down but have some additional thoughts:

• screen shots of current state and future state - If you're already getting a video, asking for screenshots on top of that seems like overkill. Also, I'm unsure how you would get the future ideal state screenshot unless the bug was already fixed?
• video of current issue - Looks like you're already getting this, so this is great.
• steps on how to reproduce - This is pretty standard, but if you're always getting a thorough video, this might not be necessary.
• device information - I don't think it's fair for the bug filer (i.e. the everyday user) to provide this information: The onus is on the company to figure this out. You should be logging this automatically somewhere, so you can get this information after you figure out which users were afflicted with the bug.
• potential solutions - This is something that you, as the engineer, would come up with after getting the initial bug report.

Something that's missing from your list is some way to identify the user who filed the issue. This will be their user ID, email, or name in your product (you will almost certainly have the first 2 at least).

In general, as the software engineer, you should be empowered to automate this as much as possible. Let's say a user hits some bug using your app/website and emails your company's support team letting them know. It would be annoying to ask that user for further information like what browser/phone they were using and what version of the app they were on. This is information you have access to within your product code - You just need to log it.