teamcraft-jcg: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 Jira, Confluence, GitHub, 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 Jira, Confluence, and GitHub 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/`, `.github/workflows/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 Confluence. 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 Confluence. 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 Jira backlog issues, creates the sprint, and adds the issues to it. 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 Jira 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 PR 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 PR ready. The Jira issue key goes in the PR body for traceability. Without this step, PRs go to review without automated quality checks.

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

- **`post-merge`** — Closes the loop after merge. Explicitly closes the Jira issue (GitHub PRs don't auto-close Jira issues), cleans up stale status, and syncs local git state. This step is especially important in the JCG stack because without it, Jira issues stay open after the code is merged.

---

### 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 PR 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 Jira 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 PR 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 PR ready for review. The Jira issue key goes in the PR body for traceability — Jira issue closure happens explicitly via `post-merge`, not automatically.
- `pr-review` — For when the developer is acting as reviewer: reads the diff, engages PR comment threads, approves or requests changes, merges.
- `address-feedback` — For when the developer is the author: polls for open reviewer threads, makes changes, pushes. Thread resolution happens in the GitHub UI.
- `post-merge` — After the PR merges: explicitly closes the Jira issue (no auto-close from GitHub PRs), cleans up stale status, 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 Jira backlog issues, creates the sprint, and adds the issues to it. The developer picks issues up from there.

Where work ends up: merged to main, Jira issue explicitly 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