teamcraft-glgd:project-health

What this skill does

## Goal

Give any team member — developer, PM, tech lead, QA, stakeholder — an interpreted view of project health right now. Not raw GitLab data. Insight: what is on track, what is at risk, what the trends indicate, and what the data reveals that the human should pay attention to.

## Hard Constraints

- Ask what the user wants to know before gathering any data. Current sprint health? Velocity trend across sprints? Defect rate? Quality signals? MR cycle time? The question determines what to gather. Do not produce a full report if they asked a narrow question.
- Ask the user to identify the project and milestone before searching. Never auto-search.
- The `teamcraft-glgd:health-analyzer` agent does the analysis. Pass all gathered GitLab data embedded in the task prompt — not file paths, not instructions to fetch from GitLab. The skill reads the data; the agent receives it as content.
- Do not present raw GitLab API output to the user. The agent synthesizes it into findings; the skill presents those findings as interpreted insight.
- This skill uses the Task tool to invoke the `teamcraft-glgd:health-analyzer` agent. The health-analyzer works purely from the GitLab data passed in the task prompt — no filesystem access required. It works in Claude Code and Claude Cowork.

## Understand the Question

Ask the user what they want to know. Some users want a full health picture. Others have a specific concern: is the sprint on track, where is velocity heading, why is the defect rate climbing, which MRs are stuck. The question shapes everything that follows — what data to gather, what the agent focuses on, how to present findings.

Adapt the interpretation to the audience. A PM cares about sprint trajectory and scope. A tech lead cares about quality signals and MR cycle time. A stakeholder cares about delivery confidence. A QA analyst cares about what's ready and what's blocked.

## Identify the Project and Milestone

Use `mcp__gitlab__list_projects` to see what is visible, surface the results, and ask the user which project they want health data for. Never assume. Once the project is confirmed, ask which milestone(s) are in scope. If they don't know, use `mcp__gitlab__list_milestones` to show what's available and let them select. Do not assume.

## Gather GitLab Data

Pull what the question requires:
- Milestone details: ID, name, start date, end date, description or goal
- All issues in the milestone(s): IID, title, state (opened/closed), labels, assignees, `created_at`, `updated_at`, `closed_at`
- All MRs linked to the milestone or created during the sprint period: IID, title, state (opened/merged/closed), pipeline status, `created_at`, `updated_at`, `merged_at`
- Pipeline data if the question involves CI/CD health or quality signals

## Run the Health Analyzer

Use the `teamcraft-glgd:health-analyzer` agent via the Task tool. Pass all gathered data embedded in the task prompt:
- GitLab project namespace and numeric project ID
- Milestone data: ID, name, start date, end date, goal or description
- The full issue list with state, labels, assignees, and timestamps (`created_at`, `updated_at`, `closed_at`)
- The full MR list with state, pipeline status, and timestamps (`created_at`, `updated_at`, `merged_at`)
- The health question being asked

The agent returns a structured health report. Present its findings as interpreted insight — not a data dump.

## Present Findings

Translate the agent's report into the insight the user asked for. Flag what is on track, what is at risk, and what the trends suggest. If the data reveals something the user did not ask about but should know, surface it clearly.

Be honest about what the data cannot tell you. Timing data is best-effort. Pipeline history has limits. Flag uncertainty rather than projecting false confidence.

Offer to dig deeper into any finding the user wants to explore further.