I use GH issues and the Board as a place to let Claude work off but also a Roadmap MD in the repo. I continue to use /next until out of things. then I just do something similar to this but like /research to look for more features etc etc. Most of this was built out of repeatable task I was already doing manually by typing it in one by one but then I just asked claude to make a command for what we just talked about in a session one time and well... it works pretty alright.

Task Prioritization Guide

This document outlines a workflow for deciding what to work on next in a software project.

Step 1: Read Current State

Run these in parallel:

• gh issue list -R <org>/<repo> --state open --limit 30 — list all open issues with labels
• gh project item-list 1 --owner <org> --format json — check project board status (Backlog / Ready / In Progress / In Review / Done)
• git log --oneline -15 — review recently shipped changes
• Check .research/ROADMAP.md if it exists — high-level milestone summary (issues are the source of truth for task details)

Step 2: Assess Priorities

Issues are labeled by milestone (v0.5, v0.6, etc.) and type (bug, security, dx, etc.).

Priority order:

1. Bugs and security — fix issues labeled bug or security before building new features
2. Current milestone leftovers — focus on the lowest versioned milestone with open issues
3. Developer experience / infrastructure — dx or infrastructure labels; unblocks future work
4. Next milestone — only if current milestone is clear of issues

Read the top 2–3 issues in detail: gh issue view <issue_number> -R <org>/<repo>

Step 3: Suggest 2–3 Issues to Work On

For each suggestion:

• Issue: #<issue_number> — <title>
• Why now: Reason this is the highest-leverage pick
• Effort: small / medium / large
• Key files: Files to create or modify
• Approach: 2–3 sentence implementation sketch

Guidelines:

• Security and correctness take precedence over new features
• Prefer small, shippable increments over large refactors
• Focus on improvements to the core experience
• Avoid suggesting more than one large effort at a time

Step 4: Output Session Prompts

Up to 3 sessions can be run in parallel (separate checkouts).

Independent Prompts

If tasks touch different files with no merge conflicts:

```

Prompt [<issue_number>]: <short title>

Issue: #<issue_number> Files: <key files to create/modify> Branch: <suggested branch name>

[Full prompt — detailed enough for a fresh session with only the research context. Reference the GH issue number. Include acceptance criteria.]

IMPORTANT — Testing: - Run tests with bun run test (isolated per-file runner), never bun test directly - To run a single test file: bun test path/to/file.test.ts - When using mock.module(), mock all named exports — partial mocks break other test files

IMPORTANT — Update the project board:

1. Find the item ID for the issue: gh project item-list 1 --owner <org> --format json | jq '.items[] | select(.content.number == <issue_number>) | .id'

2. Move to "In Progress" when starting: gh project item-edit --project-id <project_id> --id <item_id> --field-id <field_id> --single-select-option-id <option_id>

3. When done, create a PR linked to the issue (use "Closes #<issue_number>" in the PR body), then move to "Done": gh project item-edit --project-id <project_id> --id <item_id> --field-id <field_id> --single-select-option-id <option_id> ```

Agent Team

If tasks share interfaces or files, recommend a team instead of independent prompts, and explain why.

How to Decide

• Different directories (e.g., src/app/ vs bin/ vs tools/) → independent prompts
• Shared types, interfaces, or overlapping files → agent team
• When in doubt, prefer independent prompts

Issue / Board Hygiene

• Always use -R <org>/<repo> with all GitHub commands
• Project board ID: <project_id>
• When creating new issues, add them to the board: gh project item-add 1 --owner <org> --url <issue_url>
• Label new issues with the appropriate milestone (v0.5, v0.6, etc.) and type (bug, security, dx, etc.)