kc-project-pulse

name	kc-project-pulse
description	This skill should be used when the user asks to "update project status", "write pulse update", "draft weekly update", "post project pulse", "project 更新", "寫 pulse", "weekly update", or wants to draft and post Linear project status updates. Covers data collection, health assessment, drafting, and posting.

Project Pulse Update

Draft and post Linear project status updates (pulse updates) by collecting live data, assessing health, and presenting drafts for user approval before posting.

REQUIRED: Use linear-expert skill for Linear operations (loaded by linear-manager agent).

Process Flow

Collect Data (parallel) → Assess Health → Draft Updates → GATE → Post to Linear

MCP Availability

If Linear MCP is unavailable (tools fail or server not connected): Inform the user that this skill requires Linear API access for live data. Offer: (1) retry after connecting Linear MCP, (2) draft from git log + user-provided context only (health = user's judgment, not computed), (3) abort. Do not fabricate issue data from memory.

Steps

1. Collect Data (parallel)

Fetch all data sources in parallel for efficiency:

Source	Tool / Method	What to collect
Projects	list_projects	Active projects where user is lead or member
Previous updates	get_status_updates(type: "project", user: "me")	Last pulse per project for diff context
Completed issues	list_issues(assignee: "me", state: "completed", updatedAt: "-P7D")	Work done this cycle
In-progress issues	list_issues(assignee: "me", state: "started")	Current work
Cycles	list_cycles(teamId, type: "current") + list_cycles(teamId, type: "next")	Cycle dates for deadline context
Git activity	git log --all --oneline --since=<cycle-start> --author=<user>	Commits for additional context
Project details	get_project(query, includeMilestones: true) per project	Milestone progress and targets
All project issues	list_issues(project: <name>) per project	Full issue landscape (not just user's)

Two-phase collection: Sources 1-6 run in parallel (round 1). Sources 7-8 depend on project list from round 1 and run in parallel per project (round 2).

Tip: list_projects with includeMembers and includeMilestones may exceed query complexity. Fetch projects first (lightweight), then get_project per project with milestones.

2. Classify Projects

Separate projects into two groups:

Group	Criteria	Action
Lead	User is project.lead	Draft pulse update
Contributor	User has issues but is not lead	List in a "Contributor Activity" section shown to user (not posted to Linear)

Present the classification table to user for confirmation before drafting. The contributor summary is informational for the user only — it is never posted as a pulse update.

3. Assess Health

Per project, evaluate health using the heuristic in ${CLAUDE_PLUGIN_ROOT}/reference/health-assessment.md.

Quick thresholds (inline fallback if reference unavailable):

• onTrack — progress proportional to elapsed time, remaining work assigned, no blockers
• atRisk — progress <30% with <3 days to target, critical issues unassigned, or target needs shifting. Default here when uncertain.
• offTrack — will miss target without scope reduction or deadline extension, progress <10% in current cycle

Evaluate per milestone, roll up to project level (worst milestone wins). Milestones without target dates are informational — exclude from rollup. Evaluate against post-adjustment scope when issues have been moved.

4. Draft Updates

One draft per lead project. Structure per update:

## <Milestone Name> (<progress>, target <date>)

### Completed
- **DRC-XXXX** Description (assignee)

### In progress / Remaining
- **DRC-XXXX** Description (assignee, status)

### Risk (if atRisk or offTrack)
Explain what's behind and what's needed.

### Scope adjustment (if any)
Issues moved between milestones, with reasoning.

### Action needed (if any)
@mentions for reviews, decisions, or unblocking.

### Summary
1-2 sentence executive summary of where the project stands.

### Next: <Next Milestone> (if applicable)
- Upcoming issues not yet started

Drafting rules:

• Include ALL assignees' work, not just user's — the update represents the whole project
• Group by milestone when project has multiple active milestones
• Use issue identifiers (DRC-XXXX) for traceability
• Note cross-project contributions in "Cross-project delivery" section
• Mention cycle numbers when discussing timeline shifts

5. GATE — Present for Review

Show all drafts to user with a summary table:

| Project | Health | Key highlights |

GATE is mandatory. Never post without user confirmation — even if user explicitly asks to skip review. Blanket pre-approval is not confirmation; always present the draft first. A wrong health signal propagates to the entire team.

User may:

• Adjust health assessment
• Add/remove content
• Change wording
• Request specific @mentions
• Shift milestone targets

Incorporate all feedback, then confirm again if changes are significant.

6. Post to Linear

Post all approved updates in parallel using save_status_update:

save_status_update(
  type: "project",
  project: "<project name>",
  health: "onTrack" | "atRisk" | "offTrack",
  body: "<markdown content>"
)

After posting, present a summary table with links:

| Project | Health | Diff | Link |

Linear auto-generates a diffMarkdown showing milestone progress changes since last update — include this in the summary.

Arguments

The skill accepts optional arguments:

• No args — update all projects where user is lead
• Project name — update a specific project only
• --contributor — also draft updates for contributor projects (unusual, but supported)

Rules

• Always collect fresh data — never rely on memory or prior conversation context for issue states
• Parallel fetch — collect all data sources concurrently
• GATE before every post — user approves all content
• Lead projects only by default — contributor projects are lead's responsibility
• Include team contributions — pulse represents the project, not just the user
• Health is a signal, not a grade — atRisk means "team pay attention", not failure

Red Flags — STOP and Reconsider

• About to post pulse update without showing draft to user
• User asks to skip review — this is a GATE bypass, not pre-approval
• Drafting update for a contributor project without --contributor flag
• Using stale data from earlier in the conversation instead of fresh API calls
• Health assessment doesn't match the reasoning in the draft body
• Omitting conditional sections (Risk, Scope adjustment) to shorten the update when they apply

Additional Resources

Reference Files

• ${CLAUDE_PLUGIN_ROOT}/reference/health-assessment.md — Health assessment heuristic with examples