codingthefuturewithai/teamcraft-glgd:plan-sprint

Goal

Organise a sprint: a GitLab milestone with the 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.

Resolve Drive Account

Call mcp__google-drive__list_accounts before any other Drive operation:

• No accounts — Drive is not configured for this user. Tell them and skip Drive operations.
• One account — Use it. Pass account_email explicitly on every Drive tool call this session.
• Multiple accounts — Present the list, ask which account to use for this session. Pass that account_email on every Drive tool call.

If any Drive call returns a permission error, surface it: the active account may not have access to that file or folder. Offer to try another account if one is available.

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 GitLab 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 somewhere in Drive, notes, a description they want to give verbally, or nothing yet. Do not assume a PRD exists. If they can point at a document in Drive, load it directly using mcp__google-drive__download_file. If they want you to search, search and confirm the right document before loading anything. If they have tech decisions captured, ask the same way. Work with whatever they have. If a Drive file operation fails with a path error, read the error message to identify a valid accessible host path and retry with it.

Define the sprint: Get the sprint goal 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 or create the GitLab project: Only after the sprint content is agreed, ask whether a GitLab project already exists for this work. Use mcp__gitlab__list_projects to surface what is visible and ask the user to confirm which one, or confirm there isn't one yet. If one needs to be created, confirm the project name, namespace, and visibility (public or private) with the user before creating it. Create using mcp__gitlab__create_repository with initialize_with_readme: false — the repository must be empty so the developer's scaffolding tool can initialise it. Record the numeric project ID from the API response.

Create the milestone: Create the GitLab milestone with the sprint goal as description and the agreed end date. Ask if the user wants a custom name; default to "Sprint 1". Record the milestone numeric ID and URL from the API response.

Create issues: For each confirmed issue, draft it and get explicit confirmation before creating it. Never create issues in bulk.

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 IIDs just assigned.

---

Path 2: Next Sprint, Ongoing Project

Identify the GitLab project: Use mcp__gitlab__list_projects to see what is visible, surface the results, and ask the user which project they are planning for. Never assume. Confirm once identified. Use mcp__gitlab__get_project to retrieve the numeric project ID.

PRD staleness check: If a PRD URL is available (from .teamcraft/project.md or the user), load it and check when it was last modified. Compare against issues created since that date. If issues exist that may represent scope not in the PRD, flag it before planning:

"The PRD was last updated [date]. [N] issues were created after that date and may not be reflected in it. Planning a sprint from a stale PRD means agents implement from outdated requirements. Consider updating the PRD before or immediately after this planning session."

Surface the specific issues in question. Let the user decide whether to update now or proceed. Do not block planning — surface and move on.

Load the backlog: Fetch open GitLab issues not currently assigned to a milestone. Present them 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.

Show sprint history: Use mcp__gitlab__list_milestones to display completed milestones so the user has context for sprint sequencing and naming.

Define the sprint: Get the sprint goal 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.

Create the milestone: Create the GitLab milestone with the sprint goal and end date. Record the numeric milestone ID and URL from the API response.

If assigning existing backlog issues to the milestone requires a step the tools cannot do directly, tell the user clearly which issues (by IID and title) to assign in GitLab.

---

Path 3: Something Else

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

If a milestone is created as part of this session, follow the same milestone creation steps as Path 1 or 2 — 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.

---

Done

Report the milestone created (numeric ID + URL) and all issues in it (IID + title + one-line description).

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

GitLab namespace: [namespace/project]
GitLab Project ID: [numeric ID]
Sprint milestone ID: [numeric ID]
PRD (Drive URL): [URL or "ask the PM"]
Tech Decisions (Drive URL): [URL or "ask the tech lead"]
Conventions (Drive URL): [URL or "ask the PM"]
Roadmap (Drive URL): [URL or "ask the PM — run define-roadmap if not yet created"]

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