Planner Status Report

Planner Status Report

Generate an AI status report from live Microsoft Planner plan data. Use this for a single Planner plan when the user asks to create, draft, generate, pull, prepare, or write a status report, project update, progress report, executive summary, recap, or briefing.

This skill mirrors the Planner DA StatusReport behavior: resolve one plan, extract the user's report intent, fetch Planner plan and task data, categorize tasks into mutually exclusive status-report buckets, compute overall and period statistics, then compose a Markdown report with an insight-first project-management narrative.

When to Use

• "Generate a status report for the Contoso launch plan"
• "Draft an executive summary from this Planner plan"
• "Create a project update focused on risks and blockers"
• "Pull a concise report for the last two weeks"
• "Give me a status report grouped by owner"
• "Prepare a stakeholder update from Planner data"

Do Not Use

• CRUD or operational task changes, even if the words "status report" appear in the object being edited.
• Existing report operations such as share, forward, translate, shorten, reformat, or compare prior reports.
• Single-fact lookups, counts, yes/no questions, or flat task lists.
• Multi-plan rollups or comparisons. This skill is scoped to one plan.
• General "how is the project?" or "catch me up" requests without an explicit report/update/summary/briefing noun.

Instructions

Pattern: Fetch + Local Analysis, with Ask as fallback. Use fetch_work_iq with deterministic Microsoft Graph-style paths for plan discovery and structured JSON. Use ask_work_iq only for semantic context or after the canonical structured plan-resolution paths are exhausted, unavailable, or policy-blocked. Do the report specification extraction, task categorization, statistics, and final composition locally in the skill. Do not invent data.

Step 1: Identify the user and current date

fetch_work_iq (
  entityUrls: ["/me?$select=id,displayName,mail"]
)

Use the current date supplied by the runtime as the authoritative "today". If no reporting period is specified, default to a 14-day window ending today.

Step 2: Resolve exactly one Planner plan

If the plan ID is already available from context, use it directly. Otherwise follow the canonical named-plan resolution workflow in Tasks (Planner). That shared guidance is authoritative for lookup order, paging, group-backed plans, filtering requirements, and semantic fallback behavior.

If the user's request does not identify a single plan:

1. List the likely matches with plan title and owning group.
2. Ask the user to choose one.
3. Do not generate a combined multi-plan report.

Step 3: Extract the report specification

Build a complete report specification from the user's request. Do not ask clarification questions for missing report details; apply defaults. Only ask when the target plan is missing or ambiguous.

Extract:

Default sections:

1. Overall status
2. Executive summary
3. Risks and blockers
4. Achievements
5. Progress
6. Upcoming commitments
7. Project milestones

Section selection rules:

• Generic status report requests include all default sections.
• Specific topics create those sections plus Executive summary, unless the user requested only those sections.
• If the user requests a summary-like custom section such as TL;DR, Overview, Recap, or At a glance, do not duplicate it with a separate Executive summary unless needed for safety.
• If the user says "focus on" a section, make that section detailed, but do not drop other default sections unless the user says "only", "just", or equivalent.
• If the user asks for concise output, omit visual-heavy constructs and keep tables compact, but do not omit critical risks.

Step 4: Fetch plan metadata and task data

Fetch the plan:

fetch_work_iq (
  entityUrls: ["/planner/plans/{planId}"]
)

Fetch tasks:

fetch_work_iq (
  entityUrls: ["/planner/plans/{planId}/tasks"]
)

For each plannerTask, capture only these Microsoft Graph properties when available:

• id
• title
• percentComplete
• priority
• createdDateTime
• startDateTime
• dueDateTime
• completedDateTime
• completedBy
• assignments
• bucketId
• appliedCategories

When using $select, limit it to the supported plannerTask properties listed above; do not invent additional properties or use derived display values in $select or $expand. Derive status locally from percentComplete. Resolve assignee display names from the user IDs in assignments. Resolve bucket names by fetching the plan's buckets and joining on bucketId:

fetch_work_iq (
  entityUrls: ["/planner/plans/{planId}/buckets"]
)

For richer grounding if needed, fetch task details for tasks that are overdue, recently completed, high priority, or specifically requested:

fetch_work_iq (
  entityUrls: ["/planner/tasks/{taskId}/details"]
)

Use only the description, checklist, and references properties returned by plannerTaskDetails, or semantic context summarized by ask_work_iq. Do not request history or dependencies as structured Planner fields, and do not fabricate blockers, dependencies, or narrative context from a task title alone.

Step 5: Normalize and categorize tasks

Normalize status:

Normalize priority:

Apply user filters before categorization.

Categorize every task into exactly one bucket, in this order:

1. Completed in period - completed date is between start_date and end_date, inclusive.
2. Completed before - completed, but before start_date.
3. Overdue - due date is before today and task is not completed.
4. In progress - status is In Progress and not overdue.
5. Upcoming - Not Started with start date after today.
6. Not started - Not Started with a start or due date and not overdue/upcoming.
7. Uncategorized - no dates and not completed.

Every task must appear in exactly one bucket. No duplication.

Compute:

overall_statistics:
  total = all tasks
  completed = completed_in_period + completed_before
  overdue = overdue
  in_progress = in_progress
  not_started = not_started + upcoming + uncategorized

period_statistics:
  total
  completed_in_period
  completed_before
  overdue
  in_progress
  not_started
  upcoming
  uncategorized

Step 6: Determine health verdict

Use the most severe applicable verdict:

If blocker information is not present in data, do not infer blockers. Base the verdict on overdue percentage, completion, derived task status, and explicit task-detail content.

Step 7: Resolve grouping for Progress and Milestones

If the user explicitly requested grouping, use it for the whole report.

Otherwise use this priority cascade for Progress and Project milestones:

1. Buckets, if at least two distinct non-empty bucket names were resolved.
2. Priority, if tasks span at least two priority levels.
3. Assignee, if tasks span at least two assignees.
4. Aggregate "Entire plan".

Render up to 8 groups. If there are more, show the top 8 by task count and aggregate the rest into "Other".

Step 8: Compose the report

Write the report directly in Markdown. Never expose internal JSON field names, category names, pipeline steps, or implementation details.

For this WorkIQ skill, follow the user's requested output surface:

• If Mermaid support is confirmed, include the Task Completion Chart by default.
• If Mermaid support is confirmed and the Project milestones section has enough grounded date data for a meaningful timeline, include the Gantt Timeline by default.
• A user request for charts, visuals, Gantt, timeline, or a task completion chart still requests the applicable visual, but cannot override an explicit renderer limitation.
• If the user explicitly asks for no charts, table-only output, or concise output, or contentToOmit includes charts, visualizations, pie charts, Gantt charts, or timeline, skip chart blocks and use tables/counter lines. This explicit opt-out takes precedence over confirmed Mermaid support.
• Select visual output using the renderer capability policy below. Do not infer Mermaid support merely because the report uses MCP.

Renderer capability policy

MCP initialization identifies the client and negotiates protocol features such as roots, sampling, and elicitation. Standard MCP capabilities do not advertise Markdown, HTML, Mermaid, or other response-renderer features. The WorkIQ tools also do not expose the MCP initialization handshake to this skill.

Determine Mermaid support in this order:

1. Use a trusted runtime-provided renderer capability when one is present.
2. Use trusted host-configuration evidence when it explicitly states that Mermaid diagrams or Mermaid fenced code blocks are supported or should be used. Host-level formatting or rendering instructions count as this evidence; generic Markdown support, client identity, and tool availability do not.
3. Honor an explicit user instruction to produce Mermaid or an explicit statement that their target renderer supports Mermaid. Once support is confirmed, visuals are enabled by default unless the user opted out.
4. Otherwise treat renderer support as unknown and use Markdown tables/counter lines.

Do not infer renderer support from the presence of an MCP server, clientInfo.name alone, tool availability, or generic Markdown support. Do not ask a clarification question only to determine renderer support; use the fallback when the signal is missing. Never use inline HTML or SVG for charts.

Use this structure unless the user's explicit section spec replaces it:

# Status report for [Plan Name]

**Date of report:** [Month DD, YYYY]  |  **Reporting period:** [Start Date] - [End Date]

[**Project Owner:** [Owner Name] - only when an individual owner can be resolved]

---

## Overall status

[RAG] **[Verdict]**  -  **[Completion %]% Complete**  -  [Total] tasks

[One sentence: insight first, numbers second.]

---

## Executive summary

[One 3-4 sentence paragraph: top risk theme, top win theme, top ask/next horizon, velocity signal if material.]

**[TOTAL]** Total - Completed **[N]** - In Progress **[N]** - Delayed **[N]** - Not Started **[N]**

[Task Completion Chart when Mermaid support is confirmed and charts were not omitted;
see chart rules below.]

**Key risks**
- **[Risk]:** [impact + owner when known].

**Key wins**
- **[Outcome]:** [delivered item + impact]. Resolved [Month DD] when known.

**Decisions / Asks**
- **[Action]:** [why + owner]. Omit this sub-heading if there are no asks.

---

## Risks and blockers

| # | Item | Status | Due date | Details | Action needed |
|---|---|---|---|---|---|
| 1 | [Task title] | [RAG status] | [date or -] | [impact and evidence] | [specific next step or -] |

---

## Achievements ([period label])

- **[Outcome framing]:** [specific completed item]. Resolved [Month DD].

---

## Progress ([period label])

[1-2 sentence narrative naming the dominant pattern across groups.]

**+[N]** Completed this period  -  **+[N]** Started or in progress  -  **[N]** Overdue

**Progress by [Bucket / Priority / Team Member / Overall]**

| Group | Status | Completed | In Progress | Delayed | Not Started | % Complete | Delta this period |
|---|---|---|---|---|---|---|---|
| [Group] | [RAG] | [N] | [N] | [N] | [N] | [PCT]% | +[N] |

---

## Upcoming commitments ([period label])

| # | Task | Due date | Owner | Description |
|---|---|---|---|---|
| 1 | [Task title] | [date or -] | [owner or Unassigned] | [grounded one-line reason this matters] |

---

## Project milestones

| Phase / Group | Start | End | Status as of today | Items |
|---|---|---|---|---|
| [Group] | [Month YYYY or -] | [Month YYYY or -] | [status] | [done] / [total] |
| **- Today -** | **[Month DD, YYYY]** | - | - | - |

[Gantt timeline when Mermaid support is confirmed, charts were not omitted, and the
grounded milestone data supports a meaningful timeline; see chart rules below.]

---

*This report was generated from Microsoft Planner plan data as of [Date of report]. Content reflects task data available at generation time. Verify facts before distribution.*

Chart rules

Task Completion Chart

Use overall_statistics exactly:

• Completed = overall_statistics.completed
• Overdue/Delayed = overall_statistics.overdue
• In Progress = overall_statistics.in_progress
• Not Started = overall_statistics.not_started

If Mermaid support is confirmed by the renderer capability policy and the user did not opt out of charts, emit this chart by default:

**Task Completion Chart:**
```mermaid
pie title Project Task Status
    "Completed" : [count]
    "Overdue" : [count]
    "In Progress" : [count]
    "Not Started" : [count]
```

If Mermaid support is unknown or unavailable, use the counter line only:

**[TOTAL]** Total - Completed **[N]** - In Progress **[N]** - Delayed **[N]** - Not Started **[N]**

Gantt Timeline

When rendering a Gantt:

1. Use Mermaid gantt.
2. Convert all dates to YYYY-MM-DD.
3. Include only high-risk, high-priority, or milestone-like tasks supported by titles, dates, and task details.
4. Group selected work into 5-6 broader project phases only when the task data supports those groupings.
5. Keep the chart to 8 rows or fewer across tasks and milestones.
6. Use milestones only for major events such as phase completion, go-live, client sign-off, or major deadlines.

Example format:

```mermaid
gantt
    title [Plan Name]
    dateFormat  YYYY-MM-DD
    axisFormat   %b, %Y
    excludes    weekends

    section [Phase Name]
    [Task Name]     :task_id, 2026-05-01, 10d
    [Milestone]     :milestone, milestone_id, 2026-05-15, 0d
```

Composition rules:

• Lead with insight, then evidence.
• Use exact counts from the computed statistics.
• Do not mix period-scoped and cumulative counts without labeling them.
• List all active risks/blockers when relevant. If too many, show the highest-risk items and one overflow row.
• Upcoming commitments must come only from the Upcoming and Not started buckets.
• Achievements must come only from Completed in period.
• Completed before the period is historical context only; do not list it as a current-period win.
• If an explicit section has no supporting data, include the heading and state the absence factually.
• If a default section has no supporting data, omit it unless the structure requires it.
• Use Mermaid only when permitted by the renderer capability policy and not explicitly omitted by the user. When permitted, include applicable charts by default. Never use SVG or inline HTML. Always keep the counter line or milestone table as a readable fallback alongside any Mermaid chart.
• Do not include task IDs unless the user explicitly asks for them.

Step 9: Delivery behavior

Default delivery is inline in chat.

If the user asks to email, post to Teams, or create a document, first show a preview and ask for explicit confirmation before sending or creating content visible to other people.

Parameters

Required MCP Tools

Error Handling

Plan not found

List likely plans and ask the user to pick one. Do not guess.

Multiple plans requested

Explain that this skill handles one Planner plan at a time. Ask the user which plan to report on first, or suggest using a multi-plan/project snapshot skill.

No tasks in plan

Generate a minimal report with the title, date, period, and a factual note that the plan has no tasks. Do not invent risks, milestones, or upcoming commitments.

Missing dates

Put undated incomplete tasks in Not started or Uncategorized as appropriate. Mention significant undated work in the summary if it affects planning confidence.

Missing assignee names

Render as Unassigned or Unknown user rather than dropping the task.

Partial fetch failure

Use whatever structured data is available, acknowledge the limitation briefly, and avoid sections that depend on missing data. Do not retry silently.

Outbound sharing requested

Preview the exact recipient and content before using create_entity_work_iq to send or post. If the report includes private Planner data, warn the user before sending.

Examples

Standard report

"Generate a status report for the Apollo Planner plan."

The skill resolves the Apollo plan, fetches plan tasks, defaults to the last 14 days, categorizes tasks, computes health, and returns the full Markdown report.

Executive risk focus

"Create a concise executive update focused on risks and blockers since Monday."

The skill uses Monday through today as the period, shapes the language for leadership, emphasizes risks/blockers, and keeps the output concise while preserving critical task evidence.

Owner-grouped progress

"Draft a status report grouped by owner, only for urgent and important tasks."

The skill filters to urgent/important tasks, groups the full report by assignee, and reports progress, risks, upcoming commitments, and milestones by owner.