Switch SDD workflow from roadmap-based to GitHub issue-driven

Replace the roadmap.md phase-picking flow with GitHub issue discovery.
The /sdd-plan-next-phase command now searches for epics labeled `epic`
and `refined` that are unassigned and have all dependency issues
resolved (marked `done`). On selection, it assigns the epic and creates
a branch. The /sdd-ship command offers to label the epic as `done`
after PR creation.

Signed-off-by: Per G. da Silva <pegoncal@redhat.com>

Author: Per G. da Silva

.claude/commands/sdd-implement.md

@@ -1,8 +1,8 @@
-Implement the current phase spec for operator-controller.
+Implement the current epic spec for operator-controller.
 
 ## Steps
 
-1. Identify the active phase spec. Look for a `specs/*/plan.md` file on the current branch. If multiple exist or none are found, use AskUserQuestion to clarify which phase to implement.
+1. Identify the active epic spec. Look for a `specs/*/plan.md` file on the current branch. If multiple exist or none are found, use AskUserQuestion to clarify which epic to implement.
 
 2. Read all spec files for the phase:
    - `plan.md` — understand the goals and approach

.claude/commands/sdd-plan-next-phase.md

@@ -1,4 +1,4 @@
-Plan the next development phase for operator-controller.
+Plan the next development phase for operator-controller by selecting an eligible GitHub epic.
 
 ## Steps
 
@@ -9,31 +9,46 @@ Plan the next development phase for operator-controller.
    git checkout main && git pull upstream main
    ```
 
-3. Read `specs/roadmap.md` and find the next undefined phase (look for "TBD" or the last numbered phase and increment).
+3. Search for eligible epics on the upstream repository. An eligible epic has labels `epic` and `refined`, is unassigned, and has no unresolved dependencies:
+   ```
+   gh issue list --repo operator-framework/operator-controller --label epic --label refined --assignee "" --state open --json number,title,body,labels,url --limit 20
+   ```
+
+4. For each candidate epic, check its linked issues to verify dependencies are resolved. Use the GitHub API to inspect linked issues:
+   ```
+   gh api repos/operator-framework/operator-controller/issues/{number}/timeline --jq '.[] | select(.event=="cross-referenced" or .event=="connected")'
+   ```
+   An epic is eligible only if all blocking/dependency issues have the `done` label. Epics with no dependencies are also eligible.
+
+5. Present the eligible epics to the user via AskUserQuestion, showing the issue number, title, and a brief summary. Let the user pick which epic to work on.
+
+6. Assign the selected epic to the current git user:
+   ```
+   gh issue edit {number} --repo operator-framework/operator-controller --add-assignee @me
+   ```
 
-4. Create a new branch:
+7. Create a new branch named after the epic:
    ```
-   git checkout -b phase-{N}-{short-name}
+   git checkout -b epic-{number}-{short-name}
    ```
 
-5. Use AskUserQuestion to gather details about the upcoming phase:
-   - What is the focus area for this phase?
-   - What are the key deliverables (3-6 items)?
-   - Are there any dependencies or blockers?
-   - What validation criteria define "done" for this phase?
+8. Use AskUserQuestion to gather implementation details about the epic:
+   - What is the approach for this epic?
+   - How should the work be broken into task groups?
+   - What validation criteria define "done"?
 
-6. Create the phase spec directory and files:
+9. Create the phase spec directory and files:
    ```
-   specs/YYYY-MM-DD-phase-{N}-{name}/
-     plan.md          — overview, goals, approach
+   specs/{epic-number}-{name}/
+     plan.md          — overview, goals, approach (link back to the GitHub issue)
      requirements.md  — detailed requirements and task groups
      validation.md    — acceptance criteria and test plan
    ```
 
-7. Reference `specs/mission.md` for alignment with project goals and design principles. Reference `specs/tech-stack.md` for implementation constraints (build commands, test frameworks, CI requirements).
+10. Reference `specs/mission.md` for alignment with project goals and design principles. Reference `specs/tech-stack.md` for implementation constraints (build commands, test frameworks, CI requirements).
 
-8. After writing the spec files, run a self-review:
-   - Check internal consistency across plan, requirements, and validation
-   - Verify alignment with mission goals and non-goals
-   - Ensure deliverables are concrete and testable
-   - Flag any gaps or ambiguities using AskUserQuestion
+11. After writing the spec files, run a self-review:
+    - Check internal consistency across plan, requirements, and validation
+    - Verify alignment with mission goals and non-goals
+    - Ensure deliverables are concrete and testable
+    - Flag any gaps or ambiguities using AskUserQuestion

.claude/commands/sdd-ship.md

@@ -80,4 +80,9 @@ Verify, commit, and publish the current branch for operator-controller.
    )"
    ```
 
-6. Report the PR URL when done.
+6. If this branch is linked to a GitHub epic (check `specs/*/plan.md` for an issue reference), use AskUserQuestion to ask whether to add the `done` label to the epic:
+   ```
+   gh issue edit {number} --repo operator-framework/operator-controller --add-label done
+   ```
+
+7. Report the PR URL when done.

AGENTS.md

@@ -357,7 +357,7 @@ This project uses spec-driven development. Governing specs live in `specs/`:
 
 | Command | Purpose |
 |---|---|
-| `/sdd-plan-next-phase` | Plan the next development phase: create branch and spec directory |
+| `/sdd-plan-next-phase` | Pick an eligible GitHub epic (`epic`+`refined`, unassigned, deps resolved), assign it, create branch and spec directory |
 | `/sdd-implement` | Implement a phase spec: follow task groups, run checks |
 | `/sdd-review` | Review branch changes for consistency with specs and conventions |
 | `/sdd-ship` | Verify, commit, and publish: run checks, create PR with conventions |

specs/conventions.md

@@ -78,6 +78,16 @@ Examples:
 - **Release branches:** `release-v{MAJOR}.{MINOR}` (e.g., `release-v1.2`)
 - **Feature branches:** Created from `main`, typically in contributor forks, merged via PR
 
+## Issue Labels
+
+| Label | Purpose |
+|---|---|
+| `epic` | Marks an issue as an epic (a significant body of work) |
+| `refined` | Indicates the epic has been refined and is ready for implementation |
+| `done` | Marks a completed epic; used to resolve dependency chains |
+
+An epic is eligible for work when it has both `epic` and `refined` labels, is unassigned, and all linked blocking issues carry the `done` label.
+
 ## Git Remotes
 
 Fork-based development workflow:

specs/roadmap.md

@@ -84,6 +84,9 @@ This document captures the historical evolution of operator-controller in phases
 
 ## Next Steps
 
-<!-- The team will iterate on these. Add upcoming phases here as priorities become clear. -->
+Future work is tracked via GitHub issues on the upstream repository rather than phases in this file. The `/sdd-plan-next-phase` command discovers the next available epic automatically.
 
-- **Phase 7:** _TBD - to be defined by the team_
+An issue is eligible for work when it has:
+- Labels: `epic` and `refined`
+- No assignee
+- No unresolved dependencies (all linked blocking issues have the `done` label)