GitHub Project Board for Planning Issues and Pull Requests
Set up a board that shows real status.
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it.
Design a GitHub Projects board for [TEAM]. Work types: [WORK_TYPES]. Stages in our workflow: [STAGES]. Fields we need (priority, size, owner, iteration): [FIELDS]. Reports we want: [REPORTS]. Define the views (board by status, table by owner, roadmap by iteration) and a table of fields with name, type, allowed values and who sets it, plus a one-sentence definition of each status. Describe automation in words, such as moving an item to In review when a pull request is opened and closing it when the pull request merges [VERIFY availability], and how to link issues and pull requests so progress updates and duplicates are avoided. Set rules for item size and work-in-progress limits, for example no more than two items in progress per person. Weekly planning routine: review done items (5 minutes), groom the top of the backlog (10), choose the next iteration's items (15), and check blocked items (5). Fewer fields and views are better; say which to add later. Test with three sample items and ask after four weeks whether the board saved time. Mark all feature statements [VERIFY].
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.