plugins/teamcraft-glgd/skills/define-roadmap/SKILL.md
Produce a multi-sprint product roadmap in Google Drive — the planning layer between a baselined PRD and individual sprint planning. Organises what gets built in what order across sprints, with priorities, dependencies, and capacity rationale. Feeds directly into plan-sprint.
npx skillsauth add codingthefuturewithai/claude-code-primitives teamcraft-glgd:define-roadmapInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Produce a roadmap that answers: given everything in the PRD, what gets built in what order, over how many sprints, and why in that sequence? The roadmap is the bridge between "here are all the requirements" and "here is what we commit to this sprint." It makes sequencing decisions explicit and visible so sprint planning is selection from a ranked backlog, not improvisation.
The roadmap is an AI-native artifact — it must be structured so an agent loading it for sprint planning can immediately understand priorities, dependencies, and sequencing rationale without human interpretation.
Call mcp__google-drive__list_accounts before any other Drive operation:
account_email explicitly on every Drive tool call this session.If $ARGUMENTS contains a Drive URL or file ID, load the PRD directly. Otherwise ask the user if they can point at the PRD before searching.
Ask whether a GitLab project exists — if so, load sprint history from mcp__gitlab__list_milestones to understand what has already shipped and give the roadmap accurate starting context.
Ask whether tech decisions are available in Drive. Load if the user can point at them — sequencing often depends on technical prerequisites.
Work conversationally. The PRD contains all requirements — the task is to sequence and group them into cohesive sprint-sized chunks with clear rationale.
For each roadmap item, establish: what it is (capability or feature area from the PRD), why it comes at this point in the sequence (dependency, risk, value), roughly how large it is (sprint count estimate), and what it unlocks next.
See references/example-roadmap.md for the expected structure and depth.
Surface sequencing decisions that need the user's input — when two capabilities have no dependency between them, the PM chooses priority. Do not assume.
Show the complete roadmap for review. Do not store until the user confirms.
Ask the user where in Google Drive to store it — which folder. Never save to the Drive root. Record the URL.
Share the Drive URL. Add the roadmap URL to .teamcraft/project.md alongside the PRD and tech decisions URLs — plan-sprint will load it as context for sprint selection. The natural next step is plan-sprint: select the first sprint's issues from the roadmap's first phase.
development
Launch (or re-launch) the user's live, multi-project work board. The dashboard is a single HTML file copied to a stable user-side location at ~/.claude/teamcraft-board.html and opened in the user's default browser. It has two views via a header toggle — a drag-and-drop Kanban Board and a live Status tab with analytics (work by status, throughput, cycle time, aging, blocked chains, recomputed on every poll). Each project is added via a header dropdown; the dashboard polls each project's .teamcraft/work directly from the browser and updates in real time. Use when the user says 'show me the kanban', 'work board', 'open the board', 'board view', 'kanban view', 'live dashboard', 'visual dashboard', 'live status dashboard', 'status dashboard', 'project metrics', 'throughput/cycle-time view', 'HTML view of work items', 'drag-and-drop board', or asks to see/move/track work visually.
development
Run a retrospective — AI compiles evidence from recent work, facilitates human reflection, and captures process decisions back into living docs. Use when the user says 'run a retro', 'let's do a retrospective', 'run a retrospective on the last 2 weeks', 'let's reflect on how that feature went', or 'time for a retro'.
development
Re-evaluate what Claude needs to be told about this project as the codebase evolves. Some gotchas become obvious from the code (remove them). New gotchas emerge. Decisions change. Use when the user says 'refresh the rules', 'update Claude's context', 'are the rules still accurate', 'clean up claude rules', or after significant codebase changes.
development
Report project status from work items and git history — either as a quick, interpreted read here in the session, or by pointing the developer to the live Status dashboard (the work board's Status tab). Covers work by status, what's in flight, cycle times, throughput, backlog priorities, aging alerts, blocked chains, and how commit activity lines up with the board. Use when the user says 'project status', 'show me the project status', 'what's the status of the work items', 'how are we doing', 'generate a status report', or asks for a status dashboard.