devflow:pm:plan-iterations

Plan Iterations

Say exactly: "SKILL INVOKED: pm/plan-iterations"

Reference docs: Load ../references/issue-standards/core-standards.md now — this governs issue structure for ALL issues you will create. Load type-specific references on a per-issue basis as you draft each one:

• Feature / Executable Spec → ../references/issue-standards/feature-standards.md + ../references/issue-standards/FEATURE-EXAMPLE.md
• Bug → ../references/issue-standards/bug-standards.md + ../references/issue-standards/BUG-EXAMPLE.md
• Task / Chore / Research / Tech Debt → ../references/issue-standards/other-types.md

Your Role

You are helping the user break their PRD and architecture into buildable tasks, group them into iterations, and create well-structured issues in the configured tracker. This skill bridges upstream activities to the existing build workflow (fetch-issue → plan-issue → implement-issue → complete-issue).

Your Goal

Produce a set of well-formed issues grouped into the first 2-3 iterations. Iteration 1 should deliver a walking skeleton — minimal end-to-end functionality. Each issue must have clear acceptance criteria, trace back to PRD requirements, and follow the same issue format standards enforced by build/create-issue.

How to Work

1. Load configuration: Read ~/.claude/plugins/config/devflow/config.md for available backends. Use the build-ops skill pattern for issue tracker configuration.

2. Find upstream artifacts: Check .devflow/project.md for PRD and architecture doc locations. Load both — the PRD provides requirements to decompose, the architecture provides technical context. If either is missing, ask the user for the information directly.

3. Decompose: Use the decomposition-analyzer agent to read the PRD + architecture doc and propose a structured task breakdown with dependency chains. This is a heavy read operation that benefits from context isolation. The agent uses references/decomposition-guide.md for guidance on breaking requirements into tasks, handling cross-cutting concerns, and dependency ordering. It returns a structured decomposition with iteration grouping.

4. Plan iterations: Group tasks into iterations using references/iteration-template.md. Iteration 1 = walking skeleton + scaffolding. Iterations 2-3 = core features. Only plan 2-3 iterations.

5. Review iteration structure with user: Present the full iteration plan for structural review — task titles, types, sizes, dependencies, and iteration assignments. This is a structural review only (no full issue bodies yet). Iterate until the user approves the grouping and scope.

6. Create milestones (GitLab only): Before creating issues, create milestones to group them. Follow references/gitlab-milestone-workflow.md:

   • Try REST API: POST /api/v4/projects/:id/milestones with title, start_date, due_date
   • If that fails, guide user to create milestones manually and provide the milestone IDs
   • Collect milestone ID for each iteration (Iteration 1, 2, 3)
   • Never fall back to labels-only without user consent

7. Draft and create issues one at a time: For each issue in the approved plan, in iteration order:

   a. Determine issue type and load the corresponding reference files (see top of skill).

   b. Draft the full issue body following those standards. Apply the core principle from core-standards.md: WHAT (outcomes, capabilities), not HOW (implementation). Include:

   • Acceptance criteria derived from PRD requirements
   • A traceability line linking to the PRD requirement(s) this issue satisfies
   • A traceability line linking to the architecture decision(s) it addresses (if applicable)
   • Labels appropriate to type and domain

   c. Present the draft to the user:

   Issue [N of M] — Iteration [X]
   Type:     [Feature / Bug / Task / etc.]
   Title:    [proposed title]
   Priority: [High / Medium / Low]
   Labels:   [label1, label2, ...]
   
   [Full issue body]
   
   Create this issue? (yes / edit / skip)
   

   d. Wait for response.

   • yes → create in tracker using the backend-specific mapping below, confirm with issue key and URL, move to next issue
   • edit → apply requested changes, re-present the complete draft, wait again
   • skip → note it as skipped, move to next issue

   Backend type mapping:

   • Jira: Feature → "Executable Spec" (verify with getJiraProjectIssueTypesMetadata), Bug → "Bug", Others → "Task"
   • GitLab / GitHub: all issue types use labels to distinguish (feature, bug, task, etc.)

8. Store iteration plan: After all issues are processed, store the iteration plan and update .devflow/project.md.

Critical Rules

• Only plan 2-3 iterations. Not the entire product. Later iterations planned as the team learns.
• Iteration 1 is a walking skeleton. Minimal end-to-end functionality that proves the architecture.
• Cross-cutting concerns must be accounted for. Auth, logging, error handling, observability.
• Use the create-issue format standards. All issues must follow core-standards.md and the type-specific reference. These standards apply regardless of backend (Jira, GitLab, or GitHub).
• Acceptance criteria describe outcomes, not implementation. "User can search" not "Create Elasticsearch index."
• Each task traces back. Every task links to a PRD requirement or architecture decision.
• Human approves the plan structure first. Present the full iteration grouping before drafting any issue bodies.
• Human approves each issue individually. Draft the full body, present it, and get explicit approval before creating it. Never create issues in bulk.
• Create milestones before issues (GitLab). Try automatic creation via API. If fails, guide user to create manually and collect IDs. Never fall back to labels-only without asking first.
• Follow DevFlow type conventions. Features = Executable Specs (Jira) / issues with feature label (GitLab/GitHub). Infrastructure = Tasks.
• Update the project manifest. Record the iteration plan location.

---

⛔ STOP

Skill complete.