Playbook

Playbook: Build a Weekly Operations Update Skill

It is Sunday night. Your operations manager opens their personal ChatGPT, pastes in the week's tickets, the deployment log, and the metrics dashboard screens...

Agent Skillsagent-skills / playbook-weekly-operations-update

It is Sunday night. Your operations manager opens their personal ChatGPT, pastes in the week's tickets, the deployment log, and the metrics dashboard screenshot, and types "draft a weekly update for leadership." They edit the output, add a couple of paragraphs by hand, and send it Monday morning. The report goes out. Leadership reads it. Nobody asks how it was made.

Then the manager goes on PTO. The senior on the team tries to produce the same report and discovers there is no canonical prompt, no agreed format, no rules about which metrics get cited with source links and which get described qualitatively. They write something. It is fine. It is also different enough that the VP notices the format changed and asks "is everything okay this week?"

This playbook walks you through building a reviewed Agent Skill that codifies the weekly operations update — the format, the required metrics, the escalation language, the cadence — attached to your operations agent so the report keeps going out the same way whether the manager is at their desk or on PTO. The personal ChatGPT habit becomes shared company infrastructure.

What you will build

By the end of this playbook, you will have:

  • A workspace Agent Skill named Weekly Operations Update with a SKILL.md procedure, the required-metrics policy, the escalation language rules, an output template, and worked examples for green / yellow / red weeks.
  • An approved version of that skill, attached to your Operations Agent with a readable mount path.
  • A repeatable workflow: any member of the operations team can ask the agent to produce the weekly update, the agent pulls or accepts the same set of metrics, applies the same format, and produces the same shape of report leadership has come to expect.
  • A scheduled trigger so the update gets produced every Monday morning whether someone explicitly asks for it or not.

What you need before you start

  • An Assist workspace where you can create workspace-scoped Agent Skills.
  • A workspace admin who can review and approve versions.
  • An Operations Agent in your workspace — the operational agent your ops team uses, ideally with tools that can read the systems the report depends on (ticketing, deploy logs, observability, internal metrics). If you do not have one, create a subagent and connect the operational tools first.
  • The current operations manager available to define the format, the required metrics, and the escalation rules. This is the most important prerequisite — the skill encodes the manager's judgment, not a generic template.
  • One or two old weekly updates to use as references. Bring the actual sent versions, not the drafts.

Step 1: Reverse-engineer the format from real reports

Before authoring anything, find what the manager actually sends. Ask for the last four to six weekly updates. Pay attention to:

  • The structure. Does the report start with a TL;DR? A scorecard? A narrative? A list of items?
  • The metrics. Which ones are cited every week? Which are conditional (only mentioned when they cross a threshold)?
  • The qualitative content. What does the manager say about risk, escalations, asks for leadership? How are open issues phrased?
  • The tone. Is leadership reading bullets and tables, or reading a memo? Are escalations stated directly or buried in qualifiers?
  • The cadence assumption. Does the report start with "Last week..." or with "This past week..."? Are dates explicit?

Write down the consistent pattern. Note the parts that vary — those are the parts where the manager's judgment shapes the report, and the skill needs to capture that judgment, not just the format.

Step 2: Create the draft skill

Open Assist and go to Workspace > Agent Skills. Click New Skill and set:

  • Name: Weekly Operations Update
  • Slug: weekly-operations-update
  • Scope: Workspace
  • Description: Produces the team's weekly operations update for leadership using the agreed format, required metrics, and escalation language. Replaces the personal-account drafting habit.

Or scaffold it from chat:

"Create a workspace Agent Skill called Weekly Operations Update. Slug: weekly-operations-update. It produces the weekly operations report leadership expects every Monday. Start a draft SKILL.md and folders for templates, policies, and examples."

The skill is created as a draft. Nothing is mounted yet.

Step 3: Write the main procedure

Open /SKILL.md. The first line tells Assist when to pick this skill up:

Use this skill when a user asks to produce the weekly operations update, the Monday report for leadership, or the operations summary for the executive team.

Then walk through the procedure. A useful SKILL.md for this skill includes:

  1. Confirm the reporting period (the week being summarized) and the audience (leadership, executive team, or board, if those differ in your company).
  2. Gather the required metrics defined in /policies/required-metrics.md. If the agent cannot pull a metric from its tools, refuse to fabricate — flag the gap explicitly in the output and ask the operator to provide the number.
  3. Compare each metric to its threshold defined in /policies/required-metrics.md. Classify the week as green, yellow, or red based on the threshold rules — do not let the agent decide the color from feel.
  4. List the operational events of the week: deploys, incidents, customer-impacting issues, vendor changes, capacity events. Source each from the tools, with a link or reference.
  5. Apply the escalation-language rules in /policies/escalation-language.md. State risks directly. Do not soften commitments. Phrase asks for leadership clearly.
  6. Identify the top three asks or decisions needed from leadership. Skip this section if there are none — do not invent asks to fill space.
  7. Produce the output in the strict format defined by /templates/weekly-update.md.
  8. Flag the report for manager review before sending if the week is classified red, if any required metric could not be sourced, or if a customer-impacting incident occurred.

The procedure is what stops the report from drifting toward "professional-sounding" prose without substance. Every metric has a source. Every risk has a name. Every ask has an owner.

Step 4: Add the supporting files

  • /templates/weekly-update.md — the strict output format. Required sections: Headline (one sentence, color), Scorecard (metrics with values, deltas, thresholds), Operational Events, Risks and Open Issues, Asks for Leadership, Source Links. The format is what makes the report comparable week over week.
  • /policies/required-metrics.md — the metrics that must appear every week. For each: definition, source, threshold for yellow, threshold for red, what evidence the agent must cite. Examples: weekly ticket volume, mean time to resolution, deploy count, incident count by severity, SLO budget remaining, on-call paging events.
  • /policies/escalation-language.md — how risks and asks are phrased. Examples: "We need a decision on X by date Y" is acceptable; "We'd appreciate guidance" is not. Be opinionated about tone — leadership reports lose credibility when language hedges.
  • /examples/green-week.md — a fully worked example for a green week: all metrics within threshold, no incidents, routine operational events. Show what "nothing to escalate" looks like.
  • /examples/yellow-week.md — a yellow week: one metric crossed threshold, one minor incident, one ask for leadership. Show how the threshold breach is explained and how the ask is phrased.
  • /examples/red-week.md — a red week: an outage, a missed SLO, a vendor issue, a customer escalation. Show how the report leads with the headline, how risks are stated, and how the asks are prioritized.

Drive the work from chat:

"Draft /policies/required-metrics.md for the Weekly Operations Update skill. Include weekly ticket volume, MTTR, deploy count, P0/P1 incident count, SLO budget remaining, and on-call paging events. For each, write the definition, the source the agent should pull from, and the green/yellow/red thresholds."

Review every file before submitting. The skill is the file. If the policy is vague, the report is vague.

Step 5: Submit for review and approve

From the skill detail page, click Submit for review. The operations manager and a workspace admin walk through the files:

  • Do the required metrics match what leadership actually wants to see every week?
  • Are the thresholds realistic given how the team has been operating?
  • Does the escalation language match how leadership wants to be addressed?
  • Do the worked examples (green, yellow, red) look like the right reports for each week shape?

When approved, the version becomes available to mount. If rejected, the feedback comes back as comments on the version, and you author a new draft. The reviewed file is the contract — the next person who runs the report uses what is in the file, not what was discussed in the rejection.

Step 6: Attach the skill to the Operations Agent

Open the Operations Agent and attach the approved version with a readable mount path:

/skills/weekly-operations-update

The Operations Agent is now pinned to this version. Anyone on the operations team can ask the agent to produce the weekly update and get the reviewed workflow. The manager's personal ChatGPT habit becomes optional.

Step 7: Validate against the last four weeks

The best validation for this skill is reproducing recent reports. Pick the last four weekly updates and ask the Operations Agent:

"Produce the weekly operations update for the week of [date]. Source the metrics from the tools. The audience is leadership."

Compare each generated report to what was actually sent. The metrics should match (or the agent should flag where it cannot source). The classification (green/yellow/red) should match. The escalation framing should feel right — direct, named, owned.

Three things to look for:

  • Did the agent fabricate a metric it could not source? If yes, the procedure needs to refuse harder.
  • Did the agent classify a week as green when the manager would have called it yellow? The threshold rules in the policy need to be tighter.
  • Did the agent miss an incident or operational event that should have been flagged? The events-gathering step in the procedure needs to be more specific about where to look.

Iterate on the skill files, not on the agent in chat. The next report should benefit from what you learned, automatically.

Step 8: Schedule the update

The point of an Agent Skill is that the work no longer depends on one person remembering to do it. Schedule the Operations Agent to produce the report every Monday at the time the manager usually sends it. See Scheduling a subagent for how the scheduling works.

"Schedule the Operations Agent to produce the weekly operations update every Monday at 7:00 AM Eastern. Send the output to the operations-leads channel in Slack for manager review before it goes to leadership."

Now the report exists by 7:05 every Monday whether or not anyone asks. The manager reviews, edits if needed, and forwards. When the manager is on PTO, the senior on the team reviews and forwards. The report does not depend on a person remembering — it depends on an agent following a reviewed skill.

Step 9: Roll out and announce the change

Announce the change to the operations team and to leadership:

"Starting next Monday, the weekly operations update is produced by the Operations Agent using a reviewed workflow. The format, required metrics, and escalation language are now defined in a workspace Agent Skill that the operations team owns. The manager still reviews and sends, but the draft is consistent week over week and works whether the manager is in or out."

Stop drafting reports in personal accounts. The skill is now the canonical source for what a weekly update looks like.

Step 10: Improve the skill from real weeks

After four to six weeks of real use, patterns surface. Maybe leadership asks for a new metric. Maybe the team realized the deploy-count metric is misleading without a separate "rollback count." Maybe the threshold for yellow MTTR is too lenient given customer expectations.

Open a new draft of the skill, fix the policies and templates, submit for review. When approved, deliberately upgrade the Operations Agent's attachment using the workflow in Governing Agent Skill versions. Old reports stay as they were written. New reports get the improved skill. Leadership sees an explicit "what changed in this report's format" note the first week the new version runs.

What you built

You have a reviewed Agent Skill that produces the weekly operations update the way the team agreed it should be produced. The skill has:

  • A specific procedure with required metrics, sourced from real tools, with refusal conditions when sourcing fails.
  • A threshold rule that classifies the week — green, yellow, red — by evidence, not by feel.
  • Escalation language rules that keep the report direct and credible to leadership.
  • Worked examples for the three week shapes, so the agent has reference output for each.
  • A scheduled trigger so the report keeps going out regardless of who is on call.
  • A versioning path so the format can evolve deliberately as leadership's needs change.

More importantly, the weekly update stopped being the operations manager's personal habit and became shared company infrastructure. The next manager joining the team does not invent a new format. The next time the manager is on PTO, the report still goes out. The next time leadership wonders "is everything okay this week?" the answer is in the report, in the same shape it has been in for the last six months.

This is what bringing scattered AI use under one platform looks like in operations: one approved skill, one operational agent, one scheduled cadence, with the metrics actually sourced and the escalation language actually owned.

Where to go from here

  • Add a quarterly operations review skill. The weekly update aggregates into a quarterly view. Build a sibling skill that takes the last 12 weekly updates and produces a quarterly summary for the board.
  • Connect a sandcastle dashboard. Build a sandcastle that shows the weekly classification (green/yellow/red) over time, with drill-downs to the underlying metrics. The weekly updates this skill produces are the input data.
  • Add an incident response skill. When a P0 fires, the operations agent should produce an incident summary on the same cadence — same format discipline, different content. The patterns you wrote here transfer directly.
  • Standardize across functions. If product, marketing, or finance have their own weekly updates, the same playbook works. Each function gets its own skill, its own required metrics, its own escalation language — all reviewed, all versioned, all owned by the team that runs the function.