codingthefuturewithai/teamcraft-jcg:plan-sprint

Goal

Organise a sprint: a named set of Jira issues the team is committing to for the sprint period. The primary job is selection and organisation. Issue creation is the exception, not the rule — it only happens when there is genuinely no backlog to plan from.

Sprint scope is what the team can actually deliver in the time box — not everything the PRD describes, not a comprehensive backlog. When in doubt, do less. A sprint the team can complete beats a sprint that looks thorough on paper.

Establish Intent

Before loading anything, ask the user what they are planning today. Present the options clearly:

1. First sprint on a new project — PRD and tech decisions are the primary inputs; the backlog is empty or sparse; issues will be created as part of this session
2. Next sprint on an ongoing project — plan from the existing Jira backlog
3. Something else — the user describes what they have (meeting notes, a stakeholder request, a known list of work, anything)

Then load exactly what is needed for that path and nothing more.

---

Path 1: First Sprint, New Project

Load context: Ask what requirements input they have — a PRD in Confluence, notes, a description they want to give verbally, or nothing yet. Do not assume a PRD exists. If they can point at a Confluence page (by URL or page ID), use mcp__sooperset-mcp-atlassian__confluence_get_page directly. If they want you to search, use mcp__sooperset-mcp-atlassian__confluence_search and confirm the right document before loading anything. If the page ID is available from .teamcraft/project.md, use it directly. If they have tech decisions captured in Confluence, ask the same way. Work with whatever they have.

Define the sprint: Get the sprint goal, sprint name, start date, and end date from the user.

Propose issues: Based on the PRD, tech decisions, and sprint goal, propose a walking skeleton — the minimal end-to-end slice that proves the architecture works, not a feature-complete product. Each issue completable by one developer in 1-3 days with a clear, observable outcome. Don't overload the sprint.

Present all proposed issues for review. Get explicit confirmation and incorporate any changes before proceeding.

Identify the Jira project: Only after the sprint content is agreed, use mcp__sooperset-mcp-atlassian__jira_get_all_projects to surface what is visible and ask the user to confirm which project to use. Never assume. Record the Jira project key (e.g., PROJ) and numeric project ID from the result.

If a GitHub repo also needs to be created for this project, try in this order:

1. gh repo create via Bash with appropriate flags — confirm name, owner, and visibility first. Create with --clone=false so it is empty for the developer's scaffolding tool.
2. If Bash is unavailable, use a GitHub MCP connector if one is configured in your environment to create the repository with the same parameters.
3. If neither is available, give the user exact instructions for creating the repo in the GitHub UI, then continue with Jira issue creation.

Create issues: For each confirmed issue, use mcp__sooperset-mcp-atlassian__jira_search_fields to discover available fields, then draft and get explicit confirmation before creating with mcp__sooperset-mcp-atlassian__jira_create_issue. Standard Jira issue types are Story, Bug, Task, Epic, and Subtask — use the type appropriate to the work. Never create issues in bulk. Apply the right format by issue type.

Before drafting the first issue, read the reference file matching the issue type — references/example-feature-issue.md, references/example-bug-issue.md, or references/example-chore-issue.md. These define the required structure. Every issue must include all sections from the reference: Background & Goal, Acceptance Criteria, Technical Guidance, and Testing Requirements (for features and bugs) or Verification (for chores). An issue missing any of these sections is incomplete — a developer cannot pick it up cold without them.

As more issues are created, update cross-issue dependency references to use the real issue keys just assigned (e.g., PROJ-1, PROJ-2).

---

Path 2: Next Sprint, Ongoing Project

Identify the Jira project: Use mcp__sooperset-mcp-atlassian__jira_get_all_projects to see what is visible, surface the results, and ask the user which project they are planning for. Never assume. Confirm once identified and record the Jira project key.

Load sprint history: Use mcp__sooperset-mcp-atlassian__jira_get_agile_boards to find the project's board, then mcp__sooperset-mcp-atlassian__jira_get_sprints_from_board to see existing sprints. This gives context for naming the new sprint and understanding the project's cadence.

Load the backlog: Fetch open Jira issues not currently in a sprint using JQL: project = [PROJ] AND sprint is EMPTY AND resolution = Unresolved ORDER BY priority DESC

Present these to the user — these are the candidates for this sprint.

If the backlog is thin or empty: tell the user to create backlog issues first and then come back to plan the sprint.

Define the sprint: Based on sprint history, propose a name that follows the existing pattern (e.g., "Sprint 3" following "Sprint 2"). Get the sprint goal, start date, and end date from the user.

Select issues: Help the user decide which backlog issues belong in this sprint based on the sprint goal, priority, and capacity. The user drives selection — Claude advises.

---

Path 3: Something Else

Ask the user what they have and whether a Jira project already exists. If not, offer to identify or create one. Work with whatever they provide.

If issues are created as part of this session, follow the same issue creation steps as Path 1 — whatever applies.

If after the conversation there is still nothing concrete to plan from, tell the user to create backlog issues first and then come back to plan the sprint.

---

Create the Sprint and Add Issues

After all issues are created or selected, and the sprint details are confirmed:

1. Find the board: Use mcp__sooperset-mcp-atlassian__jira_get_agile_boards to find the project's Scrum board. If multiple boards exist, ask the user which one to use.

2. Create the sprint: Use mcp__sooperset-mcp-atlassian__jira_create_sprint with the board ID, sprint name, goal, start date, and end date.

3. Add issues to the sprint: Use mcp__sooperset-mcp-atlassian__jira_add_issues_to_sprint to move all confirmed issues into the new sprint.

4. Start the sprint: Ask the user whether to start the sprint now. If yes, use mcp__sooperset-mcp-atlassian__jira_update_sprint to set the sprint state to active. If not, leave it as a future sprint ready to start when the team is ready.

Done

Report all issues created or selected (issue key + title + one-line description). Confirm the sprint was created, name the issues added, and report whether it was started.

For your developer — values to record in .teamcraft/project.md:

GitHub repo: [owner/repo or "not yet created"]
Jira site URL: [https://yoursite.atlassian.net]
Jira project key: [PROJ]
Jira project ID: [numeric ID]
Confluence PRD page ID: [ID or "ask the PM"]
Confluence tech decisions page ID: [ID or "ask the tech lead"]
Confluence conventions page ID: [ID or "ask the PM"]

The developer creates and maintains .teamcraft/project.md. This summary gives them everything they need.