slack-project-update

name

slack-project-update

description

Draft a project status update to an Orderful customer project Slack channel — EOD recaps, milestone updates, post-call summaries, weekly status notes. Use whenever the user asks to post an update, recap, status, or note to a customer project channel (typically #{customer}-mts-project). Triggers: 'push an update to slack', 'slack the team on [customer]', 'post EOD status for [customer]', 'recap today on [customer]', 'send a status update', 'push a slack note to the team'. The skill enforces Slack-native formatting (single-asterisk bold, real @mentions for assigned owners), keeps updates high-level and skimmable (not engineering logs), and always saves as a draft so the user can review before sending. Anchors progress in real comparables and confident framing rather than hedged 'drafted, ready to file' language.

Slack Project Update

What this skill does

Drafts a tight, scannable project status update for an Orderful customer project Slack channel — usually #{customer}-mts-project — formatted for the team to read in 30 seconds. Captures who acted, what landed, who's next, and what's blocking, in language that works for AMs / AEs / engineers without dumping engineering minutiae.

Always uses slack_send_message_draft (never slack_send_message) — the user reviews and sends.

When this fires

Use whenever the user asks for any kind of Slack project update. Typical triggers:

• "Push an update to slack about [customer]"
• "Slack the team on [customer]"
• "Post EOD status for [customer]"
• "Recap today on [customer]"
• "Send a status update on [customer]"
• "Push a slack note to the team on [customer]"
• After a customer call, kickoff, milestone, or significant change in state

Don't fire for:

• Direct messages to a single person (those need different tone — more conversational)
• Messages to external customer channels (this skill is for internal project channels)
• One-off questions ("ping Kelly to check X") — those don't need this structure

Inputs to gather

1. Customer name + Slack project channel ID. Usually #{customer-slug}-mts-project; use slack_search_channels to confirm.

2. Audience — typically the project team: AE, AM, technical driver / CEA, project lead, anyone with active ownership in the channel. Look up Slack user IDs via slack_search_users for everyone who'll get tagged.

3. What happened today / since last update — review:

   • Recent project channel messages (slack_read_channel)
   • Recent customer-thread emails (search_threads)
   • Recent platform changes (new trade requests, partnerships, etc. if relevant)
   • Onboarding profile, kickoff prep doc, or other workspace artifacts that anchor the update

4. What's next — assignment per person. Be specific about who drives what.

5. What's blocked / waiting on — usually customer-side asks (access, vendor numbers, commercial decisions).

Structure — required sections (in this order)

<@tag-primary-recipients> — {Customer} {timeframe} status:

*Today:* {1–2 sentence narrative of what happened. Lead with customer activity if any.}

*Pre-staged / Progress:* {What's been done, framed confidently with anchors to real comparables or production data where applicable.}

*Next:*
• <@tag1> drives {workstream A} ({key sub-steps})
• <@tag2> drives {workstream B} ({key sub-steps})
• Both/All gated on {external blocker, untagged if outside the Slack workspace}

{Optional closing: watcher status, escalation path, or "ping me if X."}

Sections are non-negotiable: Today / Pre-staged / Next + blockers. Optional closing line for context.

Formatting rules — Slack native, NOT markdown

This is the highest-leverage thing the skill prevents. Slack does not render **bold** — it renders literal asterisks. Always:

Element	Correct (Slack)	Wrong (markdown)
Bold	*bold* (single asterisk)	**bold**
Italic	_italic_	*italic*
Code (inline)	`code`	`code` (same — works)
Bullets	• item (or - item, both render)	* item (renders literally)
User mention	<@U083V3TTYN8>	@ashwath (doesn't notify)
Channel mention	<#C0ABNJL5LSV>	#daydream-mts-project (no link)
Inline link	<URL|label>	[label](URL)

When in doubt, use single asterisks for bold and the <@USERID> form for mentions. Both are required for the message to look right and for the right people to get notified.

Tagging rules — who and where

• Top of message (audience tags): tag the people who need to see the update. Usually AE + AM + technical driver. Acts as the notification.
• "Next" section (owner tags): tag each person in their assigned bullet, not just at the top. This makes ownership unambiguous. People skim — they look for their @mention and read what's next to it.
• External parties (customer, SI): don't @tag — they're not in the Orderful Slack workspace. Refer by first name only ("Kalyan to grant NetSuite access"). Don't fake-tag with an @ symbol; that doesn't notify anyone and reads as broken.

Tone — high-level project status, not engineering log

The audience is the project team. They care about:

• What changed
• Who's doing what
• What's blocked
• Whether they need to do anything

They do NOT care about (in a status update):

• Specific transaction IDs, partnership IDs, ediAccount IDs (unless someone needs to look one up)
• API shapes (JSON v3, Mosaic API, etc.)
• Channel IDs, poller bucket URLs, timeout values, version numbers
• Step-by-step technical reasoning
• AOC profile corrections (those go elsewhere)

If you find yourself writing "JSON v3 / Live + Test Poller Buckets, Deliver Acks on, 120m timeout for all six TX types" — stop. That's owner-internal config detail, not status-update content. Replace with the higher-level outcome: "Partnership configured and pre-staged."

Confidence framing — anchor in comparables, not hedges

When work is informed by data — comparable customers, production patterns, internal references — say so. It's more credible AND more actionable than tentative phrasing.

Hedged (avoid)	Confident with anchor (use)
"Trade request drafted, ready to file once we have the vendor number"	"Partnership configured based on how Olipop, Reser's Fine Foods, and House Foods trade with KeHE today — defaults applied from real production patterns."
"We think the doc set is probably standard OTC"	"Standard OTC doc set staged (matches Reser's LIVE configuration)."
"Started looking at the KeHE setup"	"KeHE deep-dive done — found {N} corrections to AOC-230; structure validated against real KeHE production traffic to Olipop."

The hedge sells the team short. If you did the work, say what you did.

Length — max 6-8 bullets total across all sections

Status updates are skim-first. If the message is taller than two phone-screens, it's too long. Cut.

Common cuts:

• Drop transaction IDs unless someone needs them. (If they do, link to the doc that has them.)
• Drop the "what happened" detail and keep only the outcome. "Sent outreach to Randy. He replied" — not three paragraphs about Randy's reply content.
• Drop config specifics (see Tone section).
• Compress "we're waiting on X, Y, Z" into a single line where possible.

Save as draft, never send directly

Always use slack_send_message_draft. The user reviews, edits, and sends. Reasons:

• The user often wants to attach a file (Google Doc, .docx) before sending — Slack MCP can't upload files directly.
• The user may want to add a follow-up sentence or tweak phrasing.
• Live-sending automated content to a customer project channel without review is a trust risk.

After saving, tell the user:

1. That the draft is saved (mention the draft ID).
2. Link to the channel so they can open and review.
3. Any prerequisite they need to handle before sending (e.g., "attach the kickoff prep .docx before hitting send").

Multiple drafts in a channel

Slack only allows one attached draft per channel at a time. If the user has been iterating (you sent draft v1, they asked for changes, you sent v2, etc.), accumulated drafts pile up in Slack's drafts panel. Mention this when delivering: "You now have N drafts in #{channel}; delete the older ones before sending. The keeper is {newest_draft_id}."

Reference: canonical example (Day Dream EOD, May 19 2026)

This is the structure pattern. Save as references/day-dream-eod-example.md in the skill bundle.

<@U08P359RZE0> <@U02GHQ0D91Q> <@U07RAR1NBUY> — Day Dream EOD status:

*Today:* Sent the pre-kickoff outreach to Randy. He replied within an hour — confirmed Day Dream is new to EDI, looped in Kalyan and a colleague from Global Apps, and has a KeHE call tomorrow where he'll surface their vendor number, ISA, and SPS testing portal status.

*Pre-staged on the Orderful side:* Partnership setup and configured based on how comparable CPG customers (Olipop, Reser's Fine Foods, House Foods) trade with KeHE today — entity, ISA, transaction set, and comm channel all defaulted from real production patterns. Sample test 850s already injected so the NetSuite Connector has something to ingest the moment we're wired up.

*Next:*
• <@U083V3TTYN8> drives the Orderful side (partnership → scenarios → SPS testing setup)
• <@U07RAR1NBUY> drives the NetSuite side (customer + item master, connector wiring)
• Both gated on Kalyan granting Orderful access to Day Dream's NetSuite

Watcher's running on the thread + email; anything from Randy or Kalyan surfaces here automatically.

Things this example does right:

• Tags the audience (Jon AE, Kelly AM, Isaiah technical) at top — they all get the ping
• "EOD status:" framing tells them the timeframe at a glance
• "Today" is one sentence: what happened externally (Randy replied) + the key facts
• "Pre-staged" uses the confident framing with three real comparables (Olipop, Reser's, House Foods) as anchors
• "Next" tags each person on their bullet so ownership is unambiguous
• External party (Kalyan) is named, not @-tagged
• Closing notes the watcher so the team knows automation will surface activity

Things this example deliberately doesn't include:

• Transaction IDs (921777640, 921778959) — owner-internal detail
• Version corrections (v005010 vs. v4010) — goes to AOC-230, not the team channel
• Specific config values (JSON v3, poller buckets) — owner-internal
• The full ask list for Randy's KeHE call — that's in the email, not the update

Anti-patterns to avoid

• Markdown **bold** — Slack renders this as literal asterisks. Use single *bold*.
• Untagged assigned owners. If you say "Isaiah drives the NetSuite side" without a real <@USERID> mention, Isaiah doesn't get pinged. Always tag in-channel owners.
• Sending without review (slack_send_message) — always draft. Even if the user said "push it," the safe path is draft + tell them where to send from.
• Engineering log dump. If the update reads like a commit message, it's wrong. Cut config specifics, IDs, version numbers unless someone explicitly needs them.
• Untagged hedged framing. "Drafted, ready to file" sells the work short. If you've done informed work, say "configured based on {real anchor}."
• Fake @-tags for external parties (e.g., @Kalyan for someone outside the workspace). Doesn't notify, looks broken. Use first name only.
• Burying the lede. "Today" should be the first content section — not a long preamble about background.
• Long status updates after small days. If nothing material happened today, skip the update or do a one-liner ("Day Dream — quiet, waiting on Kalyan + Randy's KeHE call tomorrow. Watcher will surface activity.").

Final sanity check before saving the draft

• All *single-asterisk* for bold (no **)?
• All in-channel owners tagged with <@USERID>?
• External parties named only, not @-tagged?
• Three sections present (Today / Pre-staged / Next + blockers)?
• Total length ≤ 6-8 bullets?
• No transaction IDs, channel IDs, version numbers unless directly relevant?
• Saved as draft, not sent?
• User told where the draft is and any prerequisites (e.g., attach a file) before sending?