What this prompt does
This prompt designs a complete GitHub project-management setup for a [team_size]-person [project_type] team. It generates issue templates for your [issue_types] using YAML form syntax, a pull request template with sections for description, testing, screenshots, and a checklist, and a GitHub Projects board with your [board_columns] and automation rules. It also builds a color-coded label taxonomy, a milestone structure for your [release_cadence], a CODEOWNERS file based on [team_structure], and branch protection rules.
The structure works because it standardizes the workflow hygiene that quietly drifts into chaos. YAML issue forms force consistent reporting, a clear label taxonomy makes triage fast, and a CODEOWNERS file aligned to the real team structure routes reviews to the right people automatically. By enforcing your chosen [workflow_standard] throughout, every template nudges the team toward the same conventions instead of relying on memory. The PR template's sections for description, testing, screenshots, and a checklist make every pull request self-documenting, and the milestone structure tied to your [release_cadence] gives the board a rhythm. Branch protection rules for main and release branches close the loop, so the process is not just suggested but actually enforced where it counts most.
When to use it
- Your team's issues and boards have drifted into inconsistency and you want to reset them.
- You need structured issue templates for
[issue_types]instead of free-form bug reports. - You want a GitHub Projects board with
[board_columns]and automation rules defined up front. - You need a CODEOWNERS file that routes reviews based on your real
[team_structure]. - You want milestones aligned to your
[release_cadence]and a consistent label taxonomy. - You are standardizing on a
[workflow_standard]like conventional commits and want templates to enforce it.
Example output
Expect a full configuration set: YAML issue forms for each of your [issue_types], a Markdown PR template, a Projects board definition with [board_columns] and automation rules, a color-coded label taxonomy spanning priority, type, status, and area, a milestone plan for [release_cadence], a CODEOWNERS file derived from [team_structure], and branch protection rules, all enforcing your [workflow_standard].
Pro tips
- List your real
[issue_types]so the YAML forms capture the fields you actually triage on, not generic placeholders. - Map
[team_structure]accurately, because CODEOWNERS only helps if it routes reviews to the people who really own each area. - Keep
[board_columns]to a workflow your team will follow; too many columns create busywork moving cards around. - Align milestones to your true
[release_cadence]so they stay meaningful rather than becoming stale buckets. - Adopt the label taxonomy consistently from day one; a half-applied label scheme is worse than none for triage.
- Iterate by living with the setup for a sprint, then feeding back what felt heavy and asking it to simplify.
