SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsreports-client-status

reports-client-status

General & other

View repository

Updated 10-15 23:49

About this skill

Client Status Update Skill

Purpose

Auto-generate a short, client-ready status update for any project by scanning all live sources. Output is shown in chat — not posted anywhere — for review before sending.

Tone: Professional, direct, concise. No filler. No internal jargon. Length: ~200–300 words total. Scannable. No walls of text.

Step 0: Resolve project context and cadence

If not already clear from conversation, determine:

  • Project name and client name
  • Cadence — weekly, sprint, or monthly? (ask if not specified)
  • Jira project key (or search for it)
  • Slack channels to scan (or search for them by project name)
  • Confluence space (for finding the last status/meeting page)
  • Audience — who is this update for? (affects tone and what to include/exclude)

Execution Workflow

Step 1: Determine the scan window

The scan window depends on the chosen cadence:

Weekly: Find the last two weekly Confluence pages for the project:

CQL: space = "<project_space>" AND title ~ "Weekly" ORDER BY created DESC
limit: 2
  • Normally: use createdAt of the most recent page as the scan start date.
  • Edge case: if the most recent page was created today, use the second most recent.
  • If no page exists at all, default to 7 days ago.

Sprint: Find the active or most recently closed sprint in Jira:

JQL: project = <KEY> AND sprint in openSprints()
  • Use the sprint start date as the scan start.
  • If no open sprint, use the most recently closed sprint's start date instead.
  • Default fallback: 14 days ago.

Monthly: Use the first day of the current calendar month as the scan start date.

  • If today is the 1st–3rd of the month, use the first day of the previous month instead (to avoid an almost-empty report).
  • Default fallback: 30 days ago.

Convert the chosen start date to both ISO 8601 (for Fireflies) and Unix timestamp (for Slack).

Step 2: Scan sources in parallel

Run all of the following simultaneously:

Fireflies — find meetings within the scan window:

  • Primary: keyword: "<project_name>", fromDate: <scan_start>, limit: 10, format: text
  • Fallback: search by participants: [<pm_email>], then filter manually to project-relevant meetings
  • For each relevant meeting found, call fireflies_get_summary
  • Extract: what was built/discussed, decisions made, action items, blockers raised

Slack — search project-related channels:

slack_search_public_and_private(query="in:#<channel_name> after:YYYY-MM-DD", limit=20)

Scan the main operational channel, UI/design feedback channel, and any partner-specific channels. Fallback: slack_read_channel with oldest: <unix_timestamp> if search returns no results.

For messages that appear to contain a decision, client confirmation, or partner update, read the full thread:

slack_read_thread(channel_id: "<channel-id>", thread_ts: "<ts>")

Client approvals and confirmations are frequently given as replies to questions, not as standalone messages. Extract: decisions confirmed, client responses, partner updates, blockers raised.

Jira — fetch recent project activity within the scan window:

Weekly / Sprint:

JQL: project = <KEY> AND updated >= "<scan_start_date>" AND issuetype in (Story, Task) ORDER BY updated DESC
fields: summary, status, assignee, issuetype
maxResults: 30

Monthly:

JQL: project = <KEY> AND updated >= "<scan_start_date>" AND issuetype in (Story, Task, Epic) ORDER BY updated DESC
fields: summary, status, assignee, issuetype
maxResults: 50

Sub-tasks excluded in all cases — their titles carry no meaning without parent context. Extract: tickets moved to Done (shipped this period), tickets In Progress (active dev), newly created stories indicating scope added this period.

Step 3: Synthesise and write the update

Cross-reference all sources and produce the output using the format below. Ruthlessly prioritise: only include things that moved, changed, or matter this period. Do not pad. If a section has nothing material to report, omit that section entirely rather than using placeholders.

Output Format

Present in chat, ready to copy. Use plain text with light markdown only. Replace [Cadence] with the actual label: Weekly Update, Sprint Summary, or Monthly Summary.

📋 [Project Name] [Cadence] — [DD.MM.YY]

**Development**
• [specific thing built or shipped]
• [specific thing built or shipped]

**Design**
• [specific design completed, shared, or feedback received]

**Decisions**
• [Decision] — [who confirmed it, date if known]

**Blockers & Pending**
• [What is blocked] — [what is needed, from whom]

Tone Calibration by Audience

Adjust language based on who receives the update. If audience was not specified, ask.

Audience Tone What to include What to avoid
Technical client (dev team, CTO) Direct, precise, can use tech terms Specific component names, API names, infra decisions Business fluff, over-explaining
Non-technical client (CEO, founder, PM) Plain language, outcome-oriented What changed for users, business impact Tech stack, ticket numbers, internal tool names
Internal stakeholder (PM, PMO) Concise, can use project shorthand Team dynamics, risks, resource signals Over-polishing — they want signal, not spin

When in doubt: write for a smart person who doesn't work on the project day-to-day. No internal shorthand (ticket IDs, team nicknames, tool names) unless the audience is internal.

Rules for Each Section

Development — 2–4 bullets. Name the specific feature or component, not just "frontend work continued". Source from: Fireflies meeting summaries, Jira tickets Done or In Progress, Slack mentions of shipped work.

  • ✅ Good: "Cart flow implemented — quantity controls, promo code input, empty state"
  • ❌ Bad: "Development work progressed this week"
  • If multiple small items shipped: group them into one bullet by theme rather than listing each.

Design — 2–3 bullets. What was delivered in Figma, shared with client, or approved. Include any client feedback received and how it was actioned.

  • If the project has no dedicated designer or nothing design-related happened: omit this section entirely — don't write "Nothing to report."
  • If design and dev are tightly coupled (e.g. design handoff and implementation happened together): merge into the Development section.

Decisions — confirmed decisions only, not open discussions. Attribute to a person or confirmed source. If none this period, write: "• No formal decisions this period."

  • A decision must be resolved and communicated — "we're still discussing" is not a decision.
  • Include decisions made about the project even if made by the client alone.

Blockers & Pending — items actively blocking progress or awaiting client input. Write as a clear ask: what is needed and from whom. Do not list routine pending items that aren't actually blocking anything right now. Partner items should only appear here if there was a concrete development this period. If there was no movement, omit rather than placeholder.

  • Distinguish: a blocker stops work now. A pending item will block future work if not resolved.
  • If something has been pending for 2+ updates without movement, flag it: "⚠️ Carried over from last update — needs resolution."

First-Ever Update (No Historical Anchor)

When there are no previous weekly/sprint pages in Confluence to anchor the scan window:

  • Default to the last 7 / 14 / 30 days (depending on cadence)
  • Add a note at the top of the output: "(First status update — scan covers [start date] to [today])"
  • Don't try to summarise the entire project history — focus only on what's concretely evidenced in sources within the window

Quality Checks

Before presenting, verify:

  • Total length under 300 words
  • Every bullet is specific and evidenced from a source
  • No vague statements ("work continued", "progress was made")
  • Decisions are attributed to a person or source
  • Blockers name what is needed and from whom
  • Tone matches the audience — no internal shorthand for external updates
  • Partner updates only appear if something concrete happened this period
  • Header label matches the actual cadence (Weekly / Sprint / Monthly)
  • Design section omitted entirely if not applicable (not written as empty)
  • Carried-over blockers flagged with ⚠️ if 2+ updates without movement

Drop any bullet that can't pass these checks. Never invent progress not found in sources.

After Presenting

Ask: "Anything to add or change before you copy this?"

Never post anywhere automatically. If asked to send it to Slack, use the Slack draft tool and wait for explicit confirmation before sending.