teamcraft-glgd:learn-teamcraft

What this skill does

## Goal

Teach TeamCraft. Give the team member a thorough, role-appropriate understanding of the plugin — the workflow, the skills available to them, how artifacts flow, and where they fit. No environment access, no setup required. This is a teaching conversation.

## Hard Constraints

- No tool calls except `AskUserQuestion`. This skill does not read GitLab, Google Drive, or the filesystem. It does not need to.
- Never transitions to doing work. Teaching only. If the team member wants to run a skill after this session, name it and explain how to invoke it — but do not run it here.
- Cowork compatible.

## Establish What They Want to Learn

Ask whether they want:
- **Role-specific**: deep dive on their role in the TeamCraft workflow
- **Full overview**: the complete plugin — all phases, all roles, how everything connects
- **Core skills**: the essential set — if the full skill list feels overwhelming, start here

If they name a role, go deep on that role. If they want everything, walk the full workflow. If they want the core skills, use the Core Skills section below.

## Core Skills — The Essential Set

TeamCraft has a lot of skills because it covers a lot of ground — from problem discovery through sprint retrospectives. That breadth can feel overwhelming. This section cuts through it: **10 skills form the backbone of the entire workflow.** Everything else extends, enhances, or supports what these 10 do.

Present these in three groups and explain why each skill matters — not just what it does.

---

### Foundation (run once per project)

These four skills establish the project. Without them, every downstream skill operates with less context and produces weaker results.

- **`teamcraft-setup`** — Verifies that GitLab and Google Drive MCP connections are working. Nothing else in the plugin functions without these connections. Run this first, once.

- **`init-project`** — Creates the project scaffold: `.teamcraft/project.md`, `CLAUDE.md`, `.claude/rules/`, `.gitlab-ci.yml`. This is the local project context that the build loop reads on every issue. Without it, planning and implementation sessions start cold with no project awareness.

- **`capture-requirements`** — Produces the PRD in Google Drive. The PRD is the requirements backbone — `plan-sprint` derives issues from it, `create-issue` checks PRD integrity after creation, and `define-roadmap` organizes it into sprint-sized delivery. Without a PRD, the team is building from memory and conversation instead of a structured, shared source of truth.

- **`tech-decisions`** — Records the technology stack and key architectural choices in Google Drive. Every `plan-and-implement-issue` session automatically loads this document so the developer plans against established decisions, not ad-hoc choices. Without it, each developer independently decides what libraries, patterns, and approaches to use — and those decisions diverge.

---

### Sprint Planning (once per sprint)

- **`plan-sprint`** — Creates the GitLab milestone and populates it with well-formed issues. This is where the PRD turns into actual work items with acceptance criteria, technical guidance, and testing requirements. The quality of issues created here directly determines the quality of what developers build from.

---

### Build Loop (repeated for every issue — the daily work)

These five skills are the core development cycle. A developer runs them in sequence for each issue in the sprint.

- **`fetch-issue`** — Loads the GitLab issue and scans the codebase for relevant existing code before any planning begins. Produces a feasibility assessment: is this ready to plan, partially started, already implemented, or blocked? Prevents wasted planning on issues that aren't ready.

- **`plan-and-implement-issue`** — Loads all project context — tech decisions, conventions, tech stack, and live library documentation via Context7 — then enters Claude Code's plan mode which plans and implements the solution. Detects existing work and offers to resume. Creates the feature branch, opens a Draft MR on the first commit, implements unit by unit with TDD discipline. The developer reviews after each unit before proceeding. This is why the foundation skills matter: it pulls in everything `init-project`, `capture-requirements`, and `tech-decisions` produced.

- **`complete-issue`** — The quality gate before human review. Runs code health, security, and deviation reviews automatically, pushes the branch, and marks the MR ready. Includes `Closes #IID` so the issue auto-closes on merge. Without this step, MRs go to review without automated quality checks.

- **`mr-review`** — The reviewer's tool. Loads the full MR diff, implementation context, and discussion threads without leaving Claude Code. Leave comments, approve, or merge — all from the CLI.

- **`post-merge`** — Closes the loop after merge. Confirms the issue is closed in GitLab, cleans up stale labels, and syncs local git state. Prevents label drift and stale local branches from accumulating across sprints.

---

### Why these 10 and not the other 16?

The remaining skills are genuinely valuable — they cover problem discovery, roadmap planning, convention capture, QA support, stakeholder communication, sprint retrospectives, codebase analysis, and more. But they extend the core workflow rather than define it. A team can ship quality software with just these 10 skills and add the others as their process matures.

If the team member wants to know what to add next beyond the core, recommend based on role:
- **Developers**: `address-feedback` (responding to MR review threads) and `fast-path` (urgent work that skips sprint ceremony)
- **PMs**: `stakeholder-update` and `project-health`
- **Tech leads**: `analyze-codebase` and `capture-conventions`

## Role-Specific Teaching

Teach thoroughly for the named role. Cover what the role does, which skills they use, what artifacts they produce or consume, and how their work connects to the rest of the team.

---

**Developer**

The developer's world is the build loop in Claude Code. Walk through each step:

- `fetch-issue` — Load a GitLab issue and get a codebase feasibility analysis before writing any code. Read-only. The starting point for every piece of work.
- `plan-and-implement-issue` — Load all project context (tech decisions, conventions, live library docs via Context7) into the session, then enter Claude Code's native plan mode which plans and implements the solution. Creates the feature branch, opens a Draft MR on the first commit. Implements unit by unit with TDD discipline. Detects existing work and offers to resume.
- `complete-issue` — Runs code health, security, and deviation reviews before pushing. Marks the MR ready for review. Includes `Closes #IID` so the issue auto-closes on merge.
- `mr-review` — For when the developer is acting as reviewer: reads the diff, checks out the branch locally, leaves structured feedback threads.
- `address-feedback` — For when the developer is the author: polls for open reviewer threads, makes changes, pushes, resolves addressed threads.
- `post-merge` — After the MR merges: verifies the issue is closed, cleans up stale labels, syncs local git state.
- `fast-path` — Urgent work that can't wait for sprint planning. Skips ceremony, preserves all quality gates.

Where issues come from: upstream — the PM runs `plan-sprint` which creates the GitLab milestone and issues. The developer picks them up from there.

Where work ends up: merged to main, issue closed, ready for the next sprint.

Codebase orientation: when joining a brownfield project or inheriting a codebase, `analyze-codebase` is the go-to skill. It runs a quick-pass analysis of the codebase (tech stack, structure, patterns, health), then offers deeper analysis based on what you need: architecture documentation, component-level `.claude/rules/` files, ADR candidates extracted from the code, convention comparison against team standards, or a CLAUDE.md audit. The architec