/planner-status-report

name: planner-status-report
description: Generates a Microsoft Planner status report for one plan, using task status, owners, dates, priorities, buckets, risks, wins, progress, upcoming commitments, and milestones.

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)](../../../workiq/skills/workiq/references/tasks-work-iq.md#find-the-plan-before-using-ask-required-for-named-plan-requests). 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:

| Field | Default | Notes | |---|---|---| | `start_date` | today minus 14 days | Convert user periods like "last week", "March", "since Monday" to dates. | | `end_date` | today | Use runtime current date. | | `audience` | `general` | Map leadership, executives, skip-level -> `executive`; team leads -> `team_lead`; engineers/myself -> `ic`; external/customer -> `client`. | | `grouping` | `none` | One of `none`, `assignee`, `bucket`, `priority`, `status`. | | `filters` | none | Assignees, priorities, buckets, statuses, include/exclude. Resolve "me/my/mine" to the user's display name when possible. | | `special_instructions` | empty | Preserve explicit structural instructions such as "one paragraph", "table only", "no charts", "focus on risks". | | `section_specifications` | all default sections | Include exactly what the user requested when they name sections/topics. |

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 ric