The Sprint Retrospective Isn't for SM- or PO-Driven Agendas
It doesn't really matter if this is "Sprint Zero" or your ten-thousandth Sprint. The objective of the Sprint Retrospective remains the same:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored.
Because the retrospective is really the key to the inspect-and-adapt process of your Scrum implementation, and targets continuous improvement, there are a couple of things I would say about your underlying question.
You as the (presumptive) Scrum Master should not be driving the content of the retrospective, except perhaps as a member of the Scrum Team who identifies ways to improve the Sprint Retrospective if the team lacks the initiative or experience to use it effectively. In other words, facilitate but don't drive the event, and use it as an opportunity to work with the Product Owner to add Scrum or Sprint Retrospective training to the Product Backlog if the team will need to consume capacity to make better use of the event in future.
As a member of the Scrum Team, the Product Owner should be encouraged to participate in identifying what went well and what didn't, too. This shouldn't cross the line into criticizing the Developers or the Increment, but the continuous improvement process includes the whole Scrum Team, not just the Developers!
None of the other things you mentioned in your list are things that should be done within the Sprint Retrospective. The outcomes from the retrospective should be identification of "impactful improvements," not the detailed planning of them. The guide specificially says:
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
So, while the process is new, and the Scrum Team may not have yet gelled, it would be inappropriate to set a rigid agenda or use the event for "work" that properly belongs in a different event or on one of the backlogs.
An Example Technique to Kick-Start a Retrospective
There are certainly some common techniques for soliciting feedback during a retrospective. One such is throwing up a bite of pasteboard with two columns, one of which is labeled "Do More of These Things" and the other labeled "Do Less of These Things." Then hand out some sticky notes, and let people write out a few notes and slap them on the board in the appropriate column. As with planning poker, the goal here is to kick-start a discussion or identify common themes without anchoring.
There are other techniques, and Scrum is not at all prescriptive about how you implement the event. All the framework really requires is that you use the event for its intended purpose, and that purpose is primarily about continuous improvement through inspection and adaptation. Notably, the guide says:
Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.
There are a number of books on the topic of running effective Sprint Retrospectives, some written by well-respected Scrum Trainers and thought leaders. However, the good ones all focus on how to use the event to empower the team and help it be more self-driving; any book that advocates a rigid agenda or anything firmer than some gentle "safety bumpers" to help a new team increase their process maturity shouldn't make your reading list for this important event.
The Last Responsible Moment for Inspect-and-Adapt Within the Current Sprint
The Sprint Retrospective is the last responsible moment for inspection-and-adaptation of the current iteration. Following the retrospective, your next event is Sprint Planning, so this is the opportunity for the team to reflect on what was learned about its process during the current Sprint, and creating some action items for experimentation or evaluation in a future Sprint. It isn't the only time this can be done; it's just the last time it can be done within the current Sprint, so try to keep the focus on things that weren't already identified earlier in the Sprint.
