Daily accountability digest for PMs

The automation reads tasks from issue tracking, classifies them by urgency and risk, compiles them into a short digest, and sends it to the project manager in their communications channel. Each PM receives one card in the morning showing their entire operational scope in a minute — without switching between Jira, Notion, Slack threads, and personal notes. The digest replaces the manual morning-routine and removes the cognitive load of the first 30 minutes of the day from the PM.

What the process does, step by step

1. Collects open tasks from issue tracking where the current PM is an owner, assignee, or watcher on the relevant projects; the filter is configured to match the team structure.
2. Separates three categories: overdue items, tasks with a deadline ≤72 hours away, and items stuck without updates for ≥5 days.
3. Summarizes each ticket to a single line: status, blocker (if any), expected action, and responsible assignee.
4. Applies a rubric-check: flags tasks with potentially compliance-sensitive context — work involving client data, NDA obligations, legal deadlines, and regulatory mentions.
5. Groups the output by priority: "critical today", "this week", "keeping on the radar", "requires escalation".
6. Sends the digest to the PM's personal channel (Slack DM, Telegram, MS Teams) at the agreed time — 30 minutes before stand-up or at the start of the working day.
7. Maintains a log: which items the digest flagged and which were closed within 24 hours — material for retro and feedback on rubric accuracy.

What the automation does not do

• Does not replace the project manager. Decisions on prioritization, escalation, and work redistribution remain with the human — the digest only surfaces the relevant items.
• Does not modify the tickets themselves. The automation operates read-only with respect to issue tracking; status updates and comments are made by the PM manually.
• Does not provide compliance guarantees. The rubric-check highlights suspicious wording as a triage signal, but legal expertise and the final decision remain with the dedicated team.

The solution is built as a custom-code workflow: a daily cron trigger launches a pipeline that pulls tasks from issue tracking, runs them through an LLM for summarization and rubric-check, assembles a markdown digest, and publishes it via a communications API. The architecture is intentionally simple — one script, one queue, one log-store — so the PMO team can maintain it without a dedicated DevOps.

Technical flow

1. The cron trigger starts the pipeline at a scheduled time (default 08:00 in each PM's time zone).
2. The script queries the issue tracking API using filters: open tickets, assigned or watched by the PM, in projects from the whitelist.
3. The enrichment step loads comments from the last 7 days, status history, and metadata (deadline, labels, ticket relationships).
4. The AI model receives each ticket and returns a one-line summary in a strictly defined format.
5. The LLM runs tickets through a QA rubric: compliance criteria, quality of wording, presence of an owner and deadline, signs of a stuck state.
6. The aggregator assembles the final markdown: a header with day metrics, priority blocks, a list of flags with a brief explanation.
7. The communications integration sends the digest to the PM's personal channel.
8. The log module writes each run to an audit table: list of flags, digest size, generation time, LLM error rate.

Implementation steps

1. Define scope: list of PMs, issue tracking filters, schedule, delivery channels.
2. Set up API access to issue tracking and communications via a service account with the minimum required permissions.
3. Draft a rubric document: what counts as a compliance flag, what counts as a stylistic note, what counts as a blocker.
4. Develop LLM prompts: summary (with a strict length limit) and rubric review (with JSON output for validation).
5. Run the first pass in a sandbox and manually compare the digest against the actual picture for the pilot PM.
6. Run a pilot with 1-2 PMs for 2 weeks, collecting feedback on format, flag accuracy, and grouping usefulness.
7. Based on pilot results, refine the rubric, add whitelists/blacklists for wording, and roll out to all team PMs.

Key components

Typical configuration options

• One PM, one team. Minimal configuration: one workflow, one channel. MVP in 1-2 weeks.
• Multiple PMs, shared PMO. Shared rubric, separate filters per PM, a single log for rubric error analytics.
• With multi-level escalation. On top of the base digest, a weekly rollup is added for the PMO head with aggregated statistics on overdue items and closed flags.

Automation works on top of the existing issue tracking and communications stack. If the team already manages tasks in Jira/Linear/ClickUp and lives in Slack/Telegram — 80% of the infrastructure is already there, what remains is to connect the LLM and write a pipeline.

Access and data

• API access to issue tracking (Jira, Linear, ClickUp, GitHub Projects, Asana and similar) from a service account.
• Read permissions for tasks, comments, and status history in the relevant projects.
• API access to the communications channel for sending direct messages (Slack, Telegram, MS Teams).
• LLM provider key (AI model or equivalent) with sufficient rate-limit for the daily ticket volume.
• Environment for cron jobs: a workflow engine, serverless function, or a standard VPS with a systemd timer.

Team readiness

• One engineer with API integration experience (~10-20 hours for setup and maintenance of the MVP).
• One PM as a pilot user for calibrating the rubric and digest format.
• A sponsor from the PMO side to define scope and compliance criteria boundaries.

Timeline

• Week 1: access, basic workflow, first test run on sandbox.
• Week 2: rubric, LLM prompts, final markdown format, pilot start with one PM.
• Week 3-4 (optional): iteration based on feedback, rollout to the remaining PMs, connecting a log for flag quality analytics.