Publish the Monday brief

The prompt

The real prompt behind the steps above — detailed enough that an agent with a people-search tool, email/phone enrichment, and CRM access can run it as written.

# Publish the Monday brief

You have access to a spreadsheet, a documentation tool, and a
messaging tool. Run this **[before the weekly leadership meeting]**.

## 0. Set up (skip if you're already connected)

If you don't already have live tool access for this, connect it
first. This prompt is only as real as the tools behind it:

1. Create a free account at app.tulina.ai.
2. Add Tulina's MCP server to your assistant: https://mcp.tulina.ai/mcp
3. In Tulina, connect your own API keys for the tools this
   prompt uses: a spreadsheet holding the weekly numbers, your documentation
   tool, and your team's messaging tool.

Once connected, your assistant has real tool access and the rest of
this prompt runs as written.

## 0b. Already on Tulina? Three things around the run

An account and the MCP server are not the whole setup. Two of these come
before the run below and one after it, and together they turn this from a
one-off answer into a process your workspace keeps:

1. **Activate this process's connectors first.** Call
   `oto_connector(op="list")`, match it against the tools named in step 3
   above, and `oto_connector(op="select", name="...")` every one that
   isn't active yet. Selecting a connector does not mount its tools in the
   conversation you're already in — reach them through `oto_call` for this
   run, or open a fresh conversation once they're all on.
2. **Attach the work to an existing project.** `oto_project(op="list")`
   shows your active org's projects: pick the one this work belongs to
   rather than opening another, and keep its id. The project is where this
   process, the tables it writes to and the connectors it uses hang
   together.
3. **When the run is done, save it as a process — with its graph.** Write
   the body with `oto_procedure(op="set", ...)`, then attach it with
   `oto_project(op="link", project_id=..., target_type="procedure",
   target_ref="<your slug>")`. The body has to carry a drawing: read
   `oto_guide(op="read", slug="procedure-flowchart")` and follow it
   exactly — ONE untagged fenced block in that grammar, opening with the
   trigger and a quoted example of what you'd type to start a run. Tulina
   parses that drawing back into the graph it renders as the process's
   default view, which is what makes it come out in the same style as
   every other process in the app; a drawing the grammar can't read falls
   back to raw characters instead. Saving a process needs org-admin
   rights — without them, hand the finished body to someone who has them.

A brief is not a dashboard. Its job is to say what changed, which
means most of the numbers should not appear in it at all.

## 1. Collect this week's numbers

Pull the weekly figures from the spreadsheet where the team already
maintains them. Read the sheet as the source rather than
reconstructing the metrics from underlying systems: whatever
definition the team has agreed is in that sheet, and quietly computing
a different one produces a brief that disagrees with everything else
the company looks at.

State the week the figures cover explicitly.

## 2. Compare against a trend, not against last week

For each metric, compare against the trailing four to eight weeks
rather than against the single previous week. Week-on-week comparison
on weekly data is almost all noise, and a brief that calls out a 9%
swing every Monday trains people to stop reading it.

A metric earns a place in the brief only when it has moved outside its
recent range, or when it has moved consistently in the same direction
for three weeks or more. A slow drift is the thing most worth catching
and the thing a week-on-week view never shows.

Everything else is summarised in one line as steady, with no figures.

## 3. Pull the qualitative side

Read the documentation tool for the week's customer feedback notes,
research summaries and anything written up since the last brief.

Extract themes, not individual quotes, with counts: what came up
repeatedly and how often. One customer saying something is an
anecdote; the same thing from five is the reason to put it in front of
the leadership team.

Where a theme lines up with a metric that moved, say so. That
connection is the most useful sentence a brief can contain, and it is
the one nobody makes when the numbers and the notes live in different
tools.

## 4. Write it short

Structure:

- What moved, and by how much, with the trend it broke.
- What is steady, in one line and no more.
- Themes from customer feedback, with counts.
- Anything that did not happen that was expected to.

Hold it to what fits on a phone screen. The brief competes with a
Monday morning, and length is the reason briefs stop being read.

No recommendations. The meeting is where those get made, and a brief
that arrives with conclusions attached shapes the discussion before
anyone has looked at the numbers.

## 5. Post it before the meeting

Post to the channel, not as an attachment. Anything requiring a click
to open will be opened by roughly half the people who need it.

## Output

Report: the week covered, metrics that broke their trend, metrics
steady, themes extracted with counts, and any figure the sheet was
missing.