<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve It's hard to figure out how to set up `rules` correctly, especially if you have `only/except` already in your head, because it works fundamentally differently. We should update the docs and provide templates to make this first step easier to help people avoid frustration. ### Intended users * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) ### User experience goal Get to first green pipeline with `rules` more quickly and easily and with less frustration. ### Proposal Add pre-configured templates for building with: - Branches and tags - Branches, tags, and MRs ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> ### Permissions and Security N/A since this is just a template change. ### Documentation Will require updating the `workflow: rules` and `rules` docs. ### Availability & Testing Does not impact product availability. ### What does success look like, and how can we measure that? Getting to your first green pipeline with `rules` is easier, though we do not currently have a measure for this. ### What is the type of buyer? IC who wants to set up pipelines without frustration. ### Is this a cross-stage feature? No ### Links / references