Monday Weekly Report

Weekly Project Report (monday.com)

Generate a weekly project-status report for one or more monday.com boards. This is general project tracking — owners, statuses, due dates, and milestones — not engineering throughput, so keep all language generic ("owner", "item", "board") and never assume a board is a software project. The report includes a date-driven delivery-risk assessment with a concrete catch-up plan, per-board health rollups, role-aware owner activity (each owner's role is confirmed once and cached), items moved this week, overdue / due-soon work, stuck / stale items, and upcoming milestones. Writes PROJECT_REPORT.md to the current directory, prints to stdout, and on --send delivers via email.

This skill is read-only. It never creates, edits, moves, or deletes monday boards, items, columns, groups, or updates.

Arguments

Parse arguments from the user's invocation:

• --dry-run (default) — write PROJECT_REPORT.md and print to stdout. Do not send email.
• --send — after generating, email the report. Primary recipient comes from env var MONDAY_WEEKLY_REPORT_TO (required when --send is used); additional recipients from MONDAY_WEEKLY_REPORT_CC (comma-separated, may be empty/unset). If MONDAY_WEEKLY_REPORT_TO is unset, abort and ask the user to set it.
• --window <past|current> — choose the weekly window. past (default) = the previous completed Mon→Sun (a fixed 7-day week; stable for scheduled emails). current = week-to-date: this week's Monday through today (a partial week, fewer than 7 days unless run on Sunday) so the report can be run any day. When omitted in an interactive preview, the skill asks (Step 1). A --send / non-interactive run defaults to past.
• --week-offset N — run for N weeks ago (0 = the week described by --window, 1 = the week before, default 0).
• --board <id|name> — board to include. Repeatable. When omitted, resolve boards via cache, then env var, then interactive prompt (Step 2).
• --reconfirm-boards — ignore the cached board set and re-resolve / re-prompt for which boards to include (Step 2).
• --reconfirm-roles — force the interactive role prompt for every owner, ignoring the cache (Step 4).
• --reconfirm-statuses — force the interactive status-mapping prompt for every board, ignoring the cache (Step 3.5).

If the user did not pass --send, treat the run as a preview. Never send email unless --send is present. Interactive prompts (window, board pick, roles, status mapping) only happen in a preview/interactive run — a --send run never prompts and instead falls back to cached values plus auto-detected defaults.

Authentication (monday hosted MCP)

This skill uses the monday MCP server only — there is no monday CLI fallback. The server is not bundled in the plugin's .mcp.json; it is registered per folder with claude mcp add (local scope):

export MONDAY_TOKEN="your_monday_api_token"   # avatar → Developers → My access tokens
claude mcp add monday --transport http https://mcp.monday.com/mcp --header 'Authorization: Bearer ${MONDAY_TOKEN}'

All tool calls execute as that user and are subject to their monday.com permissions. If mcp__monday__* tools are not available (tool-not-found errors), the server has not been added or MONDAY_TOKEN is unset — inform the user, point them at the claude mcp add command above, and stop. Do not attempt any other data source.

MCP tools and the snapshot-vs-activity-log split

This skill calls read tools only. The write-capable monday tools (create_*, change_item_column_values, move_item_to_group, delete_*, create_update) are excluded from allowed-tools. all_monday_api is granted — bulk item paging and activity-log reads need it — and it is a general GraphQL passthrough that could mutate, so read-only on that one tool is a prompt-level rule, not a configuration guarantee: only ever issue read queries through it (query { … }, never mutation).

Read paths (which tool supplies what):

• Board enumeration (Step 2, interactive pick) — query all_monday_api (query { boards(limit: N) { id name } }) when the dynamic API is available. When it is not, the skill cannot list boards itself — ask the user to name or ID the boards (or set MONDAY_WEEKLY_REPORT_BOARDS / pass --board).
• Bulk item pull (Step 5) — page all items on a board via all_monday_api (items_page) when available. When the dynamic API is off, fall back to get_board_items_by_name for the specific items/groups of interest and note in the header that coverage is limited to looked-up items.

Attribution mode (hybrid — decided for this skill):

• Activity-log mode — when all_monday_api is available, read the board activity log for precise "who moved which item to which status during the week":

  query { boards(ids: [<BOARD_ID>]) {
    activity_logs(from: "<WEEK_START_ISO>", to: "<WEEK_END_ISO>") {
      user_id event data created_at
    }
  } }
  

  Status-change events carry the column id, previous and new label, and user_id — the monday analog of "transition BY user DURING". Resolve user_id via list_users_and_teams.

• Snapshot mode (fallback) — when the dynamic API (and thus activity_logs) is unavailable, derive weekly movement from each item's updated_at and its latest updates/comments: an item counts as "touched this week" if updated_at falls in the window. Coarser — you know it changed, not exactly what or by whom (attribute to the current owner).

State the active attribution mode in the report header (e.g. Attribution: snapshot (updated_at) — board activity log unavailable). Always try activity-log mode first, fall back silently to snapshot mode, and disclose it. For the richest report, recommend the user register the local stdio monday server with --enable-dynamic-api-tools true (the hosted endpoint cannot expose the dynamic tools; see the monday skill, including its Node build caveat). Never block the report because the dynamic API is off — degrade and disclose.

Step 1: Resolve the weekly window

Reuse the dev-report window logic.

1. Determine the mode (past or current):

   • If --window was passed, honor it.
   • Else if this is a non-interactive / --send run, use past.
   • Else (interactive preview) and today is mid-week (not the end of a completed week), ask the user with AskUserQuestion — one question, multiSelect: false, header Window:
     • Question: "This week is still in progress — which weekly window do you want?"
     • Option A (first, default): Past full week (Mon–Sun) — the last completed 7-day week.
     • Option B: Week-to-date (this Mon → today) — partial current week; lets you run the report any day.
   • If today is Sunday end-of-day the two windows coincide; skip the prompt and use past.

2. Compute the raw window:

   • past: week_end = most recent Sunday 23:59 local — today when today is Sunday (the week completing today; this is why the two windows coincide in step 1), otherwise the last Sunday before today; week_start = week_end − 6 days at 00:00 local.
   • current: week_start = this week's Monday 00:00 local; week_end = today 23:59 local (now). Partial — fewer than 7 days, possibly only 1–4 working days.
   • Apply --week-offset N to either mode by subtracting 7*N days from both bounds.
   • Record window_mode and a human label for the header. ISO-format week_start / week_end for the activity-log query.

3. Partial-week handling (current mode only): today is in progress — exclude it from any "per-day" rate and from stale/overdue new-today penalties. If completed working days < 2 (a Monday/Tuesday run), mark per-day figures provisional in the header. Stuck/stale/overdue detection uses trailing-N-days or due-date comparisons and is unaffected by the window mode.

Step 2: Select boards

Boards are the lens (the monday analog of a Jira sprint). Resolve the set in this precedence:

1. --board <id|name> arguments (repeatable) — if present, use exactly these.
2. Cached board set in boards.json (Step "Caches") — reuse unless --reconfirm-boards was passed.
3. Env var MONDAY_WEEKLY_REPORT_BOARDS — comma-separated board IDs or names.
4. Otherwise, interactive prompt (preview runs only):
   • If all_monday_api is available, enumerate boards (query { boards(limit: 100) { id name } }) and ask which to include with AskUserQuestion (multiSelect: true, header Boards).
   • If the dynamic API is not available, the skill cannot list boards — ask the user to type the board IDs or names directly (and suggest setting MONDAY_WEEKLY_REPORT_BOARDS so future runs don't re-ask).
   • Cache the chosen set to boards.json.

Resolve each name to a numeric board ID (via the boards query when available, else get_board_schema/get_board_items_by_name confirmation). Before interpolating any value into any query, match it against the shape for its kind and reject it on mismatch — board ids ^[0-9]+$ (resolve names to a numeric id first and splice only that id; subitem-board ids are board ids), column ids ^[A-Za-z0-9_-]+$, dates and ISO timestamps ^\d{4}-\d{2}-\d{2}(T\d{2}:\d{2}:\d{2}(Z|[+-]\d{2}:\d{2})?)?$ (the week_start/week_end activity-log bounds), pagination cursors ^[A-Za-z0-9+/=_.-]+$ (the opaque items_page cursor) — re-resolving a rejected value rather than splicing it. A value that fits none of these kinds is never spliced into a query; re-derive it as one of these kinds first. If a name is ambiguous (multiple matches), ask the user to disambiguate by ID. Support multiple boards — every section is computed per board and rolled up across boards in the at-a-glance view.

For a non-interactive --send run with no --board, no cache, and no MONDAY_WEEKLY_REPORT_BOARDS, abort with a message asking the user to set MONDAY_WEEKLY_REPORT_BOARDS or pass --board.

Step 3: Discover each board's schema

For every selected board, call get_board_schema and locate, by type (not by guessing IDs):

• status column(s) (type: status/color) — the primary progress signal. If the board is already in the status cache (Step 3.5), reuse the cached status_col_id — do not re-decide. Otherwise, a board may have more than one; pick the one whose labels look like a workflow (contains a Done-like and an In-progress-like label). If two are equally plausible, ask the user once which is the tracking status. Either way the chosen column id is persisted as status_col_id in the board's status-cache entry (Step 3.5) so later runs reuse it.
• people / owner column (type: people) — who owns the item.
• date / timeline column (type: date or type: timeline) — the due-date signal that drives delivery risk. Prefer a timeline (start+end) if present; else the date column. A board may legitimately have none.
• groups — top-level groupings (often phases / workstreams / priorities); used for the per-group health rollup.
• dependency column (type: dependency, optional) — if present, captures item-to-item dependencies; enables the dependency-aware risk and "re-sequence" recommendations. Skip those clauses entirely when no dependency column exists.
• subitems / subtasks column (type: subtasks, optional but common) — links each parent item to its subtasks. Subtasks always count (Step 5/6): a parent's real progress lives in its subtasks, so the report must evaluate them, not just the top-level rows. Subtasks live on a separate subitem board with its own column namespace, so their status / people / date column IDs differ from the parent's (e.g. the parent's status is often status5 on the subitem board, and dependency_mm… for the dependency). Discover the subitem board's columns by their type — either call get_board_schema on the subitem board, or read one subitem's full column_values { id type text } once and match by type. Never assume the subitem status id equals the parent's.

Record per board: board_id, board_name, status_col_id, people_col_id, date_col_id (or null), dependency_col_id (or null), subitems_col_id (or null), the resolved subitem-board column ids (sub_status_col_id, sub_people_col_id, sub_date_col_id — or null when a board has no subtasks), and the group list. If a board has no date column, note it — its delivery-risk subsection will render "no date column — risk not assessed" rather than aborting.

Step 3.5: Confirm status mapping per board (cached)

monday status labels are board-specific ("Working on it", "Stuck", "Done", "Waiting for review", "Won't do", …). The report needs to know which labels mean what. Confirm once per board and cache.

Buckets to map every status label into:

Auto-detect defaults from label text (lowercased, substring match) and monday's default green/orange/red/grey colors, applying the first matching rule in this order: contains "won't/cancel/duplicate/reject" → cancelled; green or contains "done/closed/complete/shipped/approved" → done; red or contains "stuck/blocked/waiting/on hold" → stuck; orange/yellow or contains "working/progress/review/doing" → in_progress; grey/empty or contains "not started/backlog/to do/new" → not_started. A label matching no rule maps to in_progress — the stated fallback bucket, never a guess at another — and always counts as ambiguous for the prompt below.

Load the status cache (JSON, keyed by board_id; each entry is { "status_col_id": "<id>", "labels": { <label>: <bucket> } }): ${MONDAY_WEEKLY_REPORT_STATUSES:-$HOME/.config/monday-weekly-report/statuses.json}. Read with the Read tool (treat a missing file as {}).

Decide who to prompt: a board needs confirmation if it is not in the cache, OR --reconfirm-statuses was passed. If interactive and confirmation is needed, use AskUserQuestion — one question per ambiguous label (batch ≤ 4 per call), header = the label (≤ 12 chars), options = the five buckets with the auto-detected default listed first and " (detected)" appended. Labels whose auto-detection is unambiguous (exact "Done"/"Stuck"/"Not Started") can be accepted without prompting; only prompt for the uncertain ones.

Persist the board's entry — the chosen status_col_id (Step 3) plus the confirmed labels mapping — back to the status cache (mkdir -p the parent dir first). Non-interactive / --send runs never prompt — use the cache if present, else auto-detection, and note in the header how many boards used auto-detected mappings.

Step 4: Confirm owner roles (cached)

Every owner (person appearing in the people column across the selected boards) has a role that determines how they are tracked. Confirm once, cache, reuse — including on headless --send runs.

Role catalog

Exactly three roles — each has a genuinely distinct treatment (no two are tracked the same way), set along two axes: is the owner rated on weekly movement? and are their overdue/at-risk items surfaced?

The one difference between Owner and External is the cadence flag: both are rated and both have overdue surfaced, but an External is never marked stalled for a slow week. Other is the only role excluded from rating and overdue attribution entirely.

Load the role cache

Roles persist as JSON keyed by monday user_id: ${MONDAY_WEEKLY_REPORT_ROLES:-$HOME/.config/monday-weekly-report/roles.json}. Read with the Read tool (missing → {}). Each entry:

{ "12345678": { "name": "Dana Lee", "role": "owner", "confirmedAt": "2026-06-19" } }

Decide who to prompt

An owner needs confirmation if they are not in the cache, OR their cached entry is auto: true (written by a prior --send run, never human-confirmed), OR --reconfirm-roles was passed. If every owner has a human-confirmed cache entry and the flag was not passed, skip prompting and reuse the cache.

In an interactive preview run, prompting for any owner who needs confirmation is mandatory — do not silently auto-default to avoid asking. Auto-defaulting only happens on a --send / non-interactive run (see the fallback below). The auto-detected role is proposed (pre-selected) in the prompt so the human usually just confirms with one tap; it is a proposal, not a substitute for asking. (This mirrors the weekly-dev-report role flow: propose once interactively, then cache and reuse.)

Auto-detected default (proposed, pre-selected): default every owner to owner — there is no reliable API signal for who is external or untracked, so owner is the safe proposal and the human downgrades to external (part-time / outside the org) or other (don't track) where they know it applies. A cached role always wins as the pre-selection unless --reconfirm-roles forces a fresh choice.

Prompt (interactive preview runs — required)

When the run is a preview and the session is interactive, you must present the proposed roles for confirmation — even when there are many owners. Use AskUserQuestion, batching owners ≤ 4 per call and looping until every owner who needs confirmation has been asked (do not stop after the first batch). Do not skip the prompt because the proposals "look obvious" or to save turns.

• One question per owner. header = first name (≤ 12 chars). question = e.g. What is Dana Lee's role on this project? — include the signal behind the proposal in the question or option description (e.g. "owns 12 active items") so the human can judge.
• Options (multiSelect: false), all three: Owner, External, Other (don't track). List the proposed default (owner) first with " (proposed)" appended so it is the obvious pick. Three roles fit the picker's 4-option limit directly — no free-text fallback needed.

Persist

Merge answers into the role cache and write it back (mkdir -p the parent dir first). Stamp confirmedAt with today's date and drop any auto flag on the entries the human just confirmed (they are now human-confirmed). Never delete entries for owners not in scope this run; only add/update.

Non-interactive fallback (--send or no TTY)

Do not prompt. Use the cached role if present, else the auto-detected default — and when you write an auto-defaulted role to the cache, mark it auto: true so the next preview re-proposes it. In the report header, disclose how many owners used an auto-default, e.g. Roles: 7 confirmed, 2 auto-defaulted (run a preview to confirm).

Carry the resolved owner_role for every owner into Steps 6–7.

Step 5: Pull items and weekly movement

For each board, fetch items with their status, owner, date/timeline values, updated_at, and latest update text. Page all items via all_monday_api (items_page) when the dynamic API is available; otherwise fall back to get_board_items_by_name for the items/groups of interest and note the limited coverage in the header. Verify the page total against items_count (e.g. boards { items_count items_page { … } }): the first page returns up to 500 items plus a cursor — keep calling next_items_page(cursor) until cursor is null, and confirm the collected unique-id count equals items_count before computing (a mismatch means a pagination bug — dedupe by id and re-page, do not silently report inflated counts). Record per item:

• id, name, group, board_id, board_name
• status_label → mapped status_bucket (Step 3.5)
• owner_ids → owner display names → owner_role
• due = end of timeline, or the date column value (or null)
• updated_at
• last_update = most recent update/comment { author, created_at, text } if any

Subtasks (always pulled)

In the same items_page query, also pull each item's subtasks and their values from the subitem-board columns resolved in Step 3 — never skip them, and never re-use the parent's column ids on a subitem:

items_page(limit: 500) { cursor items {
  id name updated_at group { title }
  column_values(ids: ["<status>","<people>","<date|timeline>"]) { id text }
  subitems {
    id name updated_at
    column_values(ids: ["<sub_status>","<sub_people>","<sub_date>"]) { id text }
  }
} }

Record per subtask: id, name, parent_id, sub_status_label → sub_status_bucket (reuse the parent board's Step 3.5 mapping unless the subitem board has distinct labels — confirm/cache separately if so), owner(s) → role, due, updated_at. If subitems comes back with empty column_values, the subitem column ids were wrong — re-resolve them by type (Step 3) rather than treating the subtask as having no status. Subtasks feed the subtask rollup in Step 6; the report evaluates parents and subtasks.

Weekly movement (hybrid)

• Activity-log mode: from activity_logs(from, to), collect per owner the status changes they authored in the window: → done (completed), → in_progress (started), → stuck (flagged blocked), and item creations. Attribute to the user_id on the event.
• Snapshot mode: an item is "touched this week" if updated_at ∈ [week_start, week_end]. Attribute to the current owner(s). Bucket coarsely: items now in done and touched this week → "completed this week"; items now in stuck and touched → "flagged stuck this week"; others touched → "advanced this week".

Subtask movement counts too. A status change on a subtask is real progress on its parent — include it in the owner's weekly movement and in "items moved this week" (rendered as <parent> › <subtask>). In activity-log mode, subtasks live on the subitem board, so their status events come from that board's activity_logs (query the subitem board id, or rely on the subtask updated_at falling in the window when the subitem activity log isn't reachable, disclosed as snapshot for subtasks). In snapshot mode, a subtask counts as "touched this week" when its own updated_at is in the window.

In current (week-to-date) mode, exclude changes whose only timestamp is today from any per-day rate (today is in progress); they still appear in the "moved this week" counts.

Step 6: Compute health, risk, and flags

Subtask rollup (always applied)

Subtasks are evaluated alongside parents — a parent can look fine while its subtasks slip, so fold subtask state into the parent before computing health and risk:

• Effective done. A parent counts as truly done only when its own bucket is done and every subtask is done/cancelled. A parent in done with ≥ 1 non-done subtask is not counted as done in completion_pct; instead it is flagged parent done but N/M subtasks open and surfaced in the at-risk list.
• Subtask completion ratio. Per parent with subtasks, compute done_subtasks / total_subtasks (excluding cancelled). Render it next to the parent (e.g. (3/5 subtasks done)).
• Subtask overdue / stuck. An overdue subtask (sub.due < today, bucket ∉ {done, cancelled}) or a stuck subtask makes its parent at risk even if the parent's own status/date look clean — list it as <parent> › <subtask> in the overdue/at-risk and 🚩 stuck sections with the parent as context.
• Status-mismatch flag. When a parent's bucket is ahead of its subtasks (e.g. parent In Review/Approval while a recording subtask is still not_started), flag parent ahead of subtasks — it usually means the parent status was advanced prematurely.
• Parent movement roll-up (judge a container by its subtasks, not the wrapper). A parent with subtasks is a container/ownership wrapper — it is expected to sit parked on its owner (often a product owner) and cannot be effective-done until its subtasks finish, so the parent's own updated_at going quiet is not a stall signal. For each such parent compute:
  • parent_is_moving = any subtask had a status change in the trailing 14 days (activity-log mode) or any subtask's updated_at is within 14 days (snapshot mode), OR any subtask is in an active (in_progress) status. → The parent is healthy ("parked, subtasks in flight") and must not be flagged stuck or stale, and its owner must not be flagged stalled on its account.
  • parent_is_blocked = the parent can't complete and every subtask is itself stalled (no subtask change in 14 days and none in_progress) — usually one or more subtasks are stuck or not_started. → The real problem is those subtasks. Surface the blocking subtask(s) with their own owner(s) as the stuck/at-risk entry (rendered <parent> › <subtask>), noted blocks parent — parked on <owner> (product owner). Attribute the action to the subtask owner, never to the parent's product owner. A parent with no subtasks is a leaf — its own updated_at remains the signal, unchanged.
• Counting model. Primary board/group counts stay item-level (one row per top-level item) so totals match the board; subtask state is layered on via the rollups above. Add a per-board subtask coverage line (X parents have subtasks; Y subtasks total, Z% done) so the reader sees the depth behind the headline counts. Do not silently merge subtasks into the top-level bucket totals (that double-counts) — keep them as a rollup and an explicit coverage line.

Per-board / per-group health

For each board (and each group within it):

• counts by bucket: done, in_progress, stuck, not_started, cancelled (item-level; a parent with open subtasks is not counted done per the rollup above)
• completion_pct = effective_done / (total − cancelled) (effective-done applies the subtask rollup)
• overdue_count, due_soon_count (see below; include parents made at-risk by an overdue subtask)
• subtask coverage line (parents-with-subtasks, total subtasks, % subtasks done)
• board health: 🔴 if stuck_count > 0 and overdue_count > 0, or if the board's project-goal status (Delivery risk below) is 🔴 Off track; 🟡 if any overdue or any stuck (parent- or subtask-level); 🟢 otherwise.

Delivery risk (date-driven — the project-goal analog)

Risk is measured against due dates / timelines (the decision for this skill). Compute per board, then roll up:

1. Overdue = items with due < today and status_bucket ∉ {done, cancelled}.
2. Due-soon = items with today ≤ due ≤ today + 7 days and status_bucket ∉ {done, cancelled}.
3. Slip risk per item = overdue, OR due-soon while still not_started/stuck, OR (only when the board has a dependency column) stuck while blocking a dependent item.
4. Project-goal status (per board, then worst-of for the rollup):
   • 🔴 Off track — any overdue item that is not_started/stuck, OR overdue_count ≥ 20% of non-done items, OR a milestone (Step "Milestones") is past its target and not done.
   • 🟡 At risk — due-soon items still not_started/stuck, OR overdue_count between 1 and 20% of non-done items.
   • 🟢 On track — no overdue and no at-risk due-soon items.
   • Board with no date column: status = "n/a — no date column"; still report health and stuck/stale.
5. At-risk items list — each with item, board, owner (+role), due, status, the reason, and a recommended action.
6. Catch-up plan — a short, prioritized list; every step names specific items and people. Levers: re-balance ownership (overloaded/stuck owner → owner with capacity), chase an external on a relaxed cadence for an overdue item, re-sequence dependencies (only when a dependency column exists), or recommend moving a low-priority item's due date / descope. Recommend only — never modify monday (read-only skill). If 🟢 with no at-risk items, the plan is a single "On track" line.

Items owned by an other-role owner are excluded from the at-risk list and the catch-up plan (that role is not tracked) — they still count in board totals but are not attributed or chased.

🚩 Stuck / blocked items

Items with status_bucket == stuck, OR items in in_progress/not_started with no updated_at change and no update/comment in the last 14 days (calendar days from today, independent of the window). Items owned only by an other-role owner appear here only as the untracked owner — item not moving rows the rendering rule below defines (leaf items or parent_is_blocked containers with no movement in 14 days) — they are never attributed or chased; owner- and external-owned items are both included normally.

Apply the parent movement roll-up first. A parent with subtasks that is parent_is_moving is not stuck no matter how quiet its own row is — skip it. A parent_is_blocked parent is represented by its blocking subtask(s) here (<parent> › <subtask>, with the subtask's owner), not the parked parent. A parent is listed in its own right only when it has no subtasks (a leaf) or is genuinely stuck at the parent level.

🐢 Stale items

Top items (across boards) with the oldest updated_at among non-done/cancelled items — the "nothing is happening here" list. Exclude items already shown in the 🚩 Stuck / blocked section so the same item isn't double-listed. Also exclude any parent_is_moving container — a Story-style parent parked on its owner while its subtasks advance is not stale, even though its own updated_at is old; rank it by its newest subtask activity, not the wrapper's timestamp. Cap at the 10 oldest and say so.

Stalled owners

Flag only an owner (full-time) who owns ≥ 1 non-done item and authored zero weekly movement (activity-log mode) or had zero touched items this week (snapshot mode) across both the week and the trailing 14 days. Exclude owners whose only non-done items are parent_is_moving containers — a product owner parked on Stories whose subtasks (often owned by others) are advancing is doing ownership, not stalling. They must own ≥ 1 non-moving leaf (or a parent_is_blocked container with no other owner to attribute to) before the stalled flag fires; a blocked parent's stall is attributed to the blocking subtask's owner, not the product owner. external owners are not flagged as stalled (relaxed cadence — they are part-time/outside), though their overdue items still surface in the delivery-risk section. other owners are not tracked at all.

Step 7: Render the report

Write PROJECT_REPORT.md to the current directory and print the same content. Use <br> for every visual line break inside header/stat blocks so renderers don't collapse lines. Every monday item is rendered with its name and ID (and a board reference when ambiguous): **<item name>** (id <ID>, <board>). Format:

# Weekly Project Report

**Boards:** <board A>, <board B> <br>
**Weekly window:** <week_start> → <week_end> (<window_mode>: <"previous completed Mon → Sun" | "week-to-date, this Mon → today — partial, today in progress">; <N> working days<, provisional if early-week>) <br>
**Project health:** <🟢 On track | 🟡 At risk | 🔴 Off track> — <overdue_count> overdue, <due_soon_count> due within 7 days <br>
**Attribution:** <activity-log (precise) | snapshot (updated_at) — board activity log unavailable> <br>
**Roles:** <K confirmed, X auto-defaulted (run a preview to confirm)> <br>
**Status mapping:** <K boards confirmed, X auto-detected>

<Two-sentence overall summary: overall health, the biggest risk, and the single most important catch-up action.>

## 🎯 Delivery risk & recommended actions

**Project goal status:** <🟢 On track | 🟡 At risk | 🔴 Off track> <br>
**Due-date posture:** <overdue_count> overdue, <due_soon_count> due in ≤ 7 days, across <board count> board(s) <br>
**Verdict:** <one sentence: on pace, or "N items overdue, M due-soon still not started — needs action on X">

### At-risk items

| Item | Board | Owner (role) | Due | Status | Why at risk | Recommended action |
| --- | --- | --- | --- | --- | --- | --- |
| **Vendor contract sign-off** (id 998877, Ops) | Ops | Sam (owner) | 2026-06-15 | Stuck | 4 days overdue, blocks launch | Escalate; set a decision deadline this week |
| **Landing page copy** (id 112233, Marketing) | Marketing | Priya (external) | 2026-06-22 | Not started | Due in 3 days, not begun | Chase the vendor for a start date today |

### Catch-up plan (prioritized)

1. <concrete action naming items + people>
2. <…>

If 🟢 on track with no at-risk items, replace both subsections with: "🟢 **On track** — no delivery risks flagged. All dated items are on schedule." Do not omit the section.

## Roles

The full roster of owners and the role each is tracked under (from Step 4). Always render this list so the reader can see — and challenge — how every owner is being evaluated. `Source` is `confirmed` (human-confirmed in a preview) or `auto-proposed` (auto-defaulted on a headless run, not yet confirmed — re-proposed next preview).

| Owner | Role | Source | Open items | Note |
| --- | --- | --- | ---:| --- |
| Sam | Owner | confirmed | 9 | full-time, accountable |
| Priya | External | confirmed | 3 | part-time vendor — relaxed cadence, overdue still tracked |
| Jordan | Other | auto-proposed | 1 | not tracked — confirm in a preview |

If every owner is `auto-proposed`, add a one-line note: "_All roles auto-proposed — run a preview (or `--reconfirm-roles`) to confirm._"

## Project health at a glance

Per board (and a roll-up row). `Completion` excludes cancelled items.

| Board / group | Health | Done | In progress | Stuck | Not started | Completion | Overdue | Due ≤7d |
| --- | --- | ---:| ---:| ---:| ---:| ---:| ---:| ---:|
| Ops | 🟡 | 12 | 5 | 1 | 3 | 57% | 1 | 2 |
| Marketing | 🔴 | 4 | 6 | 2 | 8 | 20% | 3 | 4 |
| **All boards** | 🔴 | 16 | 11 | 3 | 11 | 39% | 4 | 6 |

## Owner activity this week (role-aware)

`owner` and `external` are both rated on weekly movement (External on a relaxed cadence — never flagged stalled for a quiet week). `other` is not rated — its cell shows `—` and the row appears only if it has activity. `other`-owned items are not surfaced as risk.

| Owner | Role | Items completed | Items advanced | Flagged stuck | Items owned (open) | Note |
| --- | --- | ---:| ---:| ---:| ---:| --- |
| Sam | Owner | 3 | 4 | 0 | 9 | On track |
| Priya | External | 1 | 1 | 0 | 3 | External — relaxed cadence; overdue still tracked |
| Jordan | Other | — | — | — | 1 | Not tracked |

(In snapshot attribution mode, "completed / advanced / flagged stuck" are derived from `updated_at` + current status and are approximate — the header states this.)

## Items moved this week

Grouped by board. New items, completions, and status changes inside the window.

- **Ops** — completed: **Server migration** (id …); started: **Q3 budget draft** (id …); flagged stuck: **Vendor sign-off** (id …)
- **Marketing** — …

## Overdue & due-soon

| Item | Board | Owner (role) | Due | Status | Days |
| --- | --- | --- | --- | --- | ---:|
| **Vendor contract sign-off** (id …) | Ops | Sam (owner) | 2026-06-15 | Stuck | +4 overdue |
| **Landing page copy** (id …) | Marketing | Priya (external) | 2026-06-22 | Not started | −3 (due soon) |

## 🚩 Stuck / blocked items

| Item | Board | Owner (role) | Status | Last movement |
| --- | --- | --- | --- | --- |
| **Vendor contract sign-off** (id …) | Ops | Sam (owner) | Stuck | 2026-05-30 |

Include `other`-owner items with no movement in 14 days, noted `untracked owner — item not moving` — but only **leaf** items or `parent_is_blocked` containers (rendered as the blocking `<parent> › <subtask>` with the subtask's owner); a `parent_is_moving` container parked on an `other` owner is not listed. Omit the section if empty.

## 🐢 Stale items (no movement)

Top 10 oldest non-done items by `updated_at`. Omit if empty.

| Item | Board | Owner (role) | Status | Last updated |
| --- | --- | --- | --- | --- |

## Milestones / upcoming deadlines

Items flagged as milestones. A board's **milestone column** is a Step 3 schema column of `type: status`/`color` or `type: checkbox` whose title — lowercased, surrounding whitespace trimmed — equals `milestone` or `milestones`; when several qualify, use the first in the board's column order. An item is a milestone when that column's value is checked / non-empty. A board with **zero** qualifying columns falls back to items due within the next 14 days. Show readiness vs target date.

| Milestone | Board | Target date | Status | On track? |
| --- | --- | --- | --- | --- |

## Per-owner detail

Each heading: `### <Name> — <Role>`. For `external` (relaxed cadence) and `other` (not tracked), note the role so low movement is not misread.

### Sam — Owner

_On track. Completed 3 items, advanced 4._

- **Server migration** (id …) — **Done** (moved Wed)
- **Q3 budget draft** (id …) — In progress, due 2026-06-30

---

<Repeat per owner: 🔴/at-risk owners first, then on-track owners/externals, then `other` (not rated) last>

Rendering rules:

• Every item is shown with its name and ID; add the board when the same name could appear on multiple boards.
• Subtasks: parents with subtasks show their completion ratio inline (e.g. (3/5 subtasks done)). Subtask-level risks render as **<parent>** (id …) › **<subtask>** (id …) so the parent is always the anchor. Add the per-board subtask coverage line under the health-at-a-glance table, and in the per-owner detail list a parent's open/overdue/stuck subtasks beneath it. Surface parent done but N subtasks open and parent ahead of subtasks mismatches in the 🎯 at-risk list.
• Dates in local timezone, `YYYY

…(truncated)