plugins/teamcraft-glgd/skills/teamcraft-setup/SKILL.md
First-time setup for the Teamcraft GLGD plugin. Verifies that GitLab MCP and Google Drive MCP are configured and working, guides through setup if not, and recommends companion plugins. Run this before any other Teamcraft skill. Works in Claude Code and Claude Cowork.
npx skillsauth add codingthefuturewithai/claude-code-primitives teamcraft-glgd:teamcraft-setupInstall 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.
Get Teamcraft GLGD fully operational. That means two MCP servers working — GitLab and Google Drive — and the right companion plugins installed. This skill verifies each connection, guides through setup if anything is missing, and leaves the user ready to run any other Teamcraft skill.
Run this once when first installing the plugin. Re-run it anytime a connection stops working.
Before verifying any connections, understand who is setting up and what they need. Ask:
"Before we start, a couple of quick questions so I can tailor the setup:
- What kind of work will you be doing with Teamcraft? (e.g., writing code, planning projects, managing requirements, a mix of everything)
- Are you running this in Claude Code or Claude Cowork?"
What this tells you:
claude mcp add CLI works. In Claude Cowork, MCP servers must be configured in Claude Desktop's config file — follow references/cowork-mcp-setup.md.Store what you learn for the rest of the setup flow. If the user's answers make it obvious (e.g., "I'm planning sprints in Cowork"), don't ask redundant follow-ups.
First confirm basic connectivity by calling mcp__gitlab__list_projects. If that fails, go straight to references/gitlab-mcp-setup.md.
If connectivity succeeds, the server is running but may be missing required tool subsets. Teamcraft depends on specific env vars that are not set by default. Spot-check each subset by attempting a lightweight call:
| Tool to call | Required env var | What Teamcraft uses it for |
|---|---|---|
| mcp__gitlab__list_milestones (any project ID) | USE_MILESTONE=true | Sprint containers — every sprint planning session |
| mcp__gitlab__list_pipelines (any project ID) | USE_PIPELINE=true | CI/CD health monitoring |
| mcp__gitlab__execute_graphql (minimal query) | GITLAB_TOOLS=execute_graphql | Advanced project queries |
| mcp__gitlab__list_wiki_pages (any project ID) | USE_GITLAB_WIKI=true | Project orientation in onboard |
For each call: if the tool responds (even with an empty list or API error), that subset is exposed and the env var is set. If the call fails with a "tool not found" or "unknown tool" error, that env var is missing.
Report which subsets passed and which failed. For any failure, follow references/gitlab-mcp-setup.md — the reconfiguration section shows the exact fix.
Call mcp__google-drive__list_accounts. Any response means the server is reachable.
references/google-drive-mcp-setup.md.references/google-drive-mcp-setup.md.Based on the environment from Step 1:
Run claude plugin list and check for the following. If missing, tell the user what's needed and why. Do not assume specific install commands are correct — plugin registries and install mechanisms evolve. Name the plugin and let Claude Code guide the installation.
frontend-design — discover-problem uses it for client-facing HTML mockups. Without it the session still works but visuals look generic.
context7 — plan-and-implement-issue uses it for real-time library documentation during technical research. Without it, tech research falls back to training data. Note: context7 may be available as a plugin or as an MCP server — check both if one doesn't work.
LSP plugins — Only if the user writes code. Follow references/lsp-plugins.md.
Tell the user which plugins are needed and why. Help them figure out how to install plugins in their Cowork environment.
Summarize what's working and what (if anything) was skipped or still needs attention. Then let the user know setup is complete and Teamcraft is ready to use.
If the user asks what to do next, point them to teamcraft-glgd:learn-teamcraft for a walkthrough of available skills. Don't steer them toward a specific activity — that's their call.
tools
Capture feedback about Teamcraft itself and turn it into a well-structured GitHub issue on the plugin's repo. Vets whether the problem is really a Teamcraft skill defect (vs. misuse, the harness, or the user's own project) by root-causing against the actual skill source, then helps the developer decide whether to file and publishes via the GitHub CLI. Use when the user says 'improve teamcraft', 'a teamcraft skill did the wrong thing', 'file feedback on teamcraft', 'report a teamcraft bug', 'I have an idea to make teamcraft better', or when a Teamcraft skill clearly misbehaved and the user wants that captured upstream.
tools
Learn the Teamcraft plugin itself — how its workflow, skills, and artifacts fit together. A guided overview for a human getting started, or a system map for Claude orienting itself to how Teamcraft works before working in a Teamcraft repo. Teaching only; needs no project or environment access. Use when someone wants to understand Teamcraft (the tool, not their specific project), asks "how does Teamcraft work", "explain the workflow", "which skill do I use for X", or when Claude needs the big picture of how the skills hook together.
tools
--- name: teamcraft:work-board description: 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 (analytics: work by status, throughput, cycle time, aging, blocked chains, recomputed on every poll). Each project is added via a header dropdown; the
development
Run pre-PR reviews (code health, security, acceptance criteria), address findings, and submit the PR for review. Ends when the PR is ready and CI has passed. Use when implementation is done and ready for review, or when the user says "I'm done coding", "validate this", "ready for review", "submit this for review", "run the pre-PR reviews", or "prepare this for review".