codingthefuturewithai/teamcraft-jcg:project-health

Goal

Give any team member — developer, PM, tech lead, QA, stakeholder — an interpreted view of project health right now. Not raw Jira 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? PR cycle time? The question determines what to gather. Do not produce a full report if they asked a narrow question.
• Use sprint listing tools to surface sprints from the board before asking the user — never demand the exact name cold.
• The teamcraft-jcg:health-analyzer agent does the analysis. Pass all gathered data embedded in the task prompt — not file paths, not instructions to fetch. The skill reads the data; the agent receives it as content.
• Do not present raw 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-jcg:health-analyzer agent. The health-analyzer works purely from the 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 PRs 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 PR cycle time. A stakeholder cares about delivery confidence. A QA analyst cares about what's ready and what's blocked.

Identify the Project and Sprint

Use mcp__sooperset-mcp-atlassian__jira_get_all_projects to see what is visible, surface the results, and ask the user which Jira project they want health data for. Never assume.

Once the project is confirmed, use mcp__sooperset-mcp-atlassian__jira_get_agile_boards to find the project's board, then mcp__sooperset-mcp-atlassian__jira_get_sprints_from_board to list sprints. Surface the active sprint and recent sprints and offer them to the user. Ask which sprint to analyze, or confirm if they name it directly.

Gather Data

Pull what the question requires. Use mcp__sooperset-mcp-atlassian__jira_search for the complete, structured issue data:

• Sprint issues: project = PROJ AND sprint = "[Sprint Name]" ORDER BY status ASC
  • For each issue: key, summary, status, issue type, assignee, priority, created, updated, resolutiondate
• PR data: Try in this order — (1) gh pr list --state all --json number,title,state,createdAt,mergedAt,headRefName via Bash; (2) if Bash is unavailable, use a GitHub MCP connector if one is configured; (3) if neither is available, omit PR data and note the gap in the report.
• Pipeline/workflow data: gh run list --limit 20 via Bash only — no MCP equivalent for GitHub Actions. If Bash is unavailable, omit CI/CD data and note it.

The GitHub repo is identified from git remote -v via Bash if available. If Bash is unavailable, ask the user or read it from .teamcraft/project.md. The Jira project key comes from .teamcraft/project.md if it exists.

Run the Health Analyzer

Use the teamcraft-jcg:health-analyzer agent via the Task tool. Pass all gathered data embedded in the task prompt:

• Jira project key and name
• Sprint name (as provided by the user)
• The full issue list with status, issue type, assignee, priority, and timestamps (created, updated, resolutiondate)
• The full PR list with state and timestamps (createdAt, mergedAt)
• Pipeline/workflow data if gathered
• 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. Workflow history has limits. Flag uncertainty rather than projecting false confidence.

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