kesslernity/awesome-copilot-cowork-bots

# Brand Answer Monitor

Tracks what a researcher finds when they look you up, week over week.

🔴 **Read this before using it.** The original idea was to track the brand's position inside
ChatGPT, Gemini and Perplexity answers. **This skill does not do that, and cannot.** Those are
competitor products behind their own interfaces, not open-web sources, and nothing in Cowork's
documentation establishes that Deep Research can query them. Shipping an "AEO tracker" on that
assumption would be inventing a capability.

What this does instead is honest and still useful: it records **what Deep Research surfaces about
the brand on a fixed set of questions**, week over week, so movement in sources and framing is
visible. Treat it as a proxy for what a research tool sees, not as a measurement of any specific
assistant's answer. If you later confirm a way to query those assistants, this skill's trend sheet

# Competition Monitor

Reports a material change and nothing else. **The suppression is the product.**

**How this differs from a news digest.** A digest finds five to eight items because five to eight
is the target. This finds zero items most weeks, and that is the correct output. A monitor that
always reports something is a monitor its reader stops opening within a month.

## Inputs
- **Deep Research** over the competitor list
- `references/config.md` for competitors, the watch list and what counts as material
- The prior run's output, read from the output folder, which is how "changed" is possible at all

## Procedure

# Internal Newsletter Builder

Builds the round-up from what actually happened, and leaves a section out rather than filling it.

## Inputs
- **Enterprise Search**, **Email** and **Meetings** over the period
- `references/config.md` for the sections, the audience and what is never included

## Procedure
1. **Gather** the period's material: shipped work, decisions taken, documents published, meetings
   that produced an outcome, new joiners if config allows it.
2. **Place each item in exactly one section** from config. An item that fits none is dropped, not
   relocated into the nearest.
3. **For each item, write**: one sentence on what happened, one on why it matters to this

# Leadership Update Drafter

Writes the upward update in a fixed shape, with the uncomfortable parts kept in.

**How this differs from `write-like-me`.** That skill learns a voice and writes in it. This one
imposes a structure and protects the honesty of the content. If both are installed, this provides
the skeleton and that provides the register.

## Inputs
- **Email**, **Meetings** and **Enterprise Search** over the period
- `references/config.md` for the structure, the audience and the escalation bar

## Procedure
1. **Gather** the period's evidence for each section of the configured structure.

# Calendar Defender

Finds the week's conflicts and the meetings that should not exist, and proposes, never acts.

## Inputs
- **Calendar Management** for the week ahead
- **Email** and **Meetings** for whether an agenda exists and what each meeting is for
- `references/config.md` for focus-time targets, working hours and meetings never touched

## Procedure
1. **Load the window** from config, normally the next seven days.
2. **Find hard conflicts**: overlapping accepted meetings. For each, say which has more attendees,
   which is recurring, and which has an agenda, so the user can choose.
3. **Find meetings with no stated purpose**: no agenda in the invitation, no linked document, no

# Budget Variance Explainer

Writes the story behind a number somebody else owns.

🔴 **This skill never produces a figure.** The user supplies the variance. The skill explains it.
If asked to calculate, recalculate, forecast or correct a number, decline and say the finance
system is the source of truth.

## Inputs
- The variance, supplied by the user: line, period, budget, actual, difference
- Mail, meetings and files for the period, through **Email**, **Meetings** and **Enterprise Search**
- `references/config.md` for the cost-centre vocabulary and the house commentary structure

## Procedure

# Cloud Cost Digest

Explains what moved on the bill, with the question to ask each owner.

## Inputs
- A billing export the user supplies, through **Excel**
- Provider alert and budget emails, through **Email**
- `references/config.md` for the materiality floor, owner mapping and the comparison period

## Procedure
1. **Load the export.** Without it, say so and stop. Alert emails alone cannot produce a digest;
   they can produce an alert summary, which is a different and lesser thing.
2. **Compare** the current period against the comparison period in config, by service and by the
   tag or account that config names as the ownership dimension.

# Expense Reconciliation

Finds the gap between what was claimed and what was evidenced, before someone else does.

## Inputs
- Mailbox, through **Email**, for receipts, card statements and claim confirmations
- A claims export the user supplies, through **Excel**
- `references/config.md` for the period, the materiality threshold and the policy rules to check

## Procedure
1. **Load the claims export.** If none is supplied, say so and stop: reconciliation without the
   claim side is not reconciliation, it is a receipt hunt. Offer that instead.
2. **Gather evidence** from the mailbox over the period: receipts, invoices, card statements.
3. **Match** each claim to evidence on amount, date within the config tolerance, and merchant.

# Invoice & Vendor Follow-up

Finds the invoice threads that stopped, with age and amount, and drafts the nudge.

## Inputs
- Mailbox, through **Email**
- `references/config.md` for the ageing buckets, the chase ladder and who is never chased

## Procedure
1. **Find invoice threads** over the window: invoices sent or received, payment queries, disputes,
   remittance advice.
2. **Determine the state of each thread** from the last message only: awaiting their reply,
   awaiting ours, resolved, or ambiguous. Ambiguous is a valid answer and must not be guessed.
3. **Age** from the last message in the thread, not from the invoice date, and bucket by config.

# Subscription Hunter

Surfaces every recurring charge in the mailbox before it renews itself, with a drafted reply ready
for the ones that should stop.

## Inputs

- The user's mailbox, through the **Email** built-in skill
- Organization files and contracts, through **Enterprise Search**
- `references/config.md` for the lookback window, the value threshold and the ignore list

## Config

Read `references/config.md` first. If it is missing, use: 24-month lookback, report everything

# Change Advisory Board Prep

Builds the pack from what people actually wrote, and names every change that arrived without a
rollback plan.

## Inputs
- **Email** and Teams traffic about upcoming changes
- **Enterprise Search** for change records, runbooks and prior post-incident notes
- `references/config.md` for the board date, the required fields and the risk vocabulary

## Procedure
1. **Find the changes** proposed for the board window.
2. **For each change, extract the required fields** from config. The usual set: what changes, who
   owns it, the window, affected systems, risk rating as stated by the proposer, rollback plan,

# Defect Intake and Triage

Turns "it's broken" into something an engineer can act on, or says exactly what is still missing.

🔴 **This does not reproduce anything.** Reproduction needs a terminal, a staging environment and
arbitrary browser control, none of which Cowork has. The portable half of a bug-reproduction
pattern is the **intake and handoff**, and that is all this does. The card says so to the reader.

## Inputs
- The report itself, from **Email** or Teams
- **Enterprise Search** for prior reports of the same thing, and for the owning team
- `references/config.md` for the required intake fields and the severity vocabulary

## Procedure

# Incident Digest

Rebuilds what happened and when, from the traffic, so the review starts from a timeline instead of
from memory.

## Inputs
- **Email** and Teams traffic for the incident window
- **Enterprise Search** for any status page, runbook or change record referenced in the traffic
- `references/config.md` for the severity vocabulary and the channels that matter

## Procedure
1. **Establish the window.** First signal to last all-clear, from the traffic itself. If the
   incident is open, say so and mark the timeline as in progress.
2. **Build the timeline** in UTC and in the user's local time, one row per event that changed what

# Internal Expert Finder

Answers "who here has already solved this", with the evidence, before anyone reinvents it.

🔴 **Internal only.** This skill never sources candidates externally, never reads professional
networks, and never touches recruitment. That boundary is the whole design: it is the portable
half of an external-sourcing pattern that does not belong inside a tenant.

## Inputs
- **Enterprise Search** across documents, sites and shared files
- **Meetings** for who presented or led on a topic
- `references/config.md` for the evidence bar and groups to exclude

## Procedure

# Interview Loop Coordinator

Makes a panel cover the whole bar once, instead of four people asking the same question.

## Inputs
- The role's written bar, supplied by the user or found via **Enterprise Search**
- Panel availability, through **Calendar Management**
- `references/config.md` for the competency list and the scoring scale

## Procedure
1. **Load the bar.** Without a written bar, stop and say so. A loop scored against an unwritten
   bar is not a loop, it is a series of opinions, and the pack would launder that into a decision.
2. **Map competencies to interviewers**, so every competency is covered at least once and no
   interviewer carries more than the config maximum. State any competency with no coverage.

# Onboarding Buddy

Turns "they start Monday" into a dated plan built from what the team actually has.

## Inputs
- **Enterprise Search** for the team's existing material: handbooks, architecture notes, runbooks
- **Calendar Management** for who is available in the first fortnight
- `references/config.md` for the role templates and the standing first-week items

## Procedure
1. **Establish** the start date, the role and the team. Missing any of these, ask once and stop.
2. **Find the real material.** Search for what this team has written: onboarding notes, decision
   records, runbooks, recent all-hands. Record what exists and, importantly, what does not.
3. **Find the people** the role should meet, evidenced by who owns the systems and documents the

# Document Transmittal Tracker

Answers "what did we send, and who still owes us a response", from the mail itself.

## Inputs
- **Email** for transmittal messages and their responses
- **Enterprise Search** for the transmittal register, if one exists as a file
- `references/config.md` for document-number patterns, response windows and the party list

## Procedure
1. **Find transmittals** by the document-number pattern in config, plus the usual vocabulary:
   "for approval", "for comment", "for construction", "IFC", "IFR", "transmittal".
2. **One row per document revision**, not per message. Revision B of a drawing is a different row
   from revision A, and conflating them hides the resubmission.

# Lessons Learned Harvester

Finds the lesson that has now been learned four times, which is the only kind worth acting on.

## Inputs
- **Enterprise Search** across close-out reports, retrospectives and project folders
- **Email** for the correspondence where problems were actually discussed
- `references/config.md` for the project list, the theme taxonomy and the lookback

## Procedure
1. **Gather** close-out and retrospective material across the configured projects and lookback.
2. **Extract individual lessons**, one per row, each with: the project, the date, what happened,
   what was recommended, and the source link.
3. **Theme them** against the config taxonomy. A lesson that fits no theme goes in `Unthemed`

# RFI and Query Tracker

Shows which open questions are actually blocking work, rather than which are merely old.

## Inputs
- **Email** and Teams traffic for queries and their answers
- **Enterprise Search** for the RFI log, if one exists
- `references/config.md` for the RFI numbering pattern and response windows by discipline

## Procedure
1. **Find queries** by the numbering pattern and the vocabulary: "RFI", "query", "clarification
   required", "please confirm", "awaiting your response".
2. **For each, extract**: reference, raised by, raised on, directed to, the question in one line,
   the response window from config, whether answered, and the source link.

# Account Expert

One skill, one customer, context rebuilt from the tenant rather than from a CRM.

**Why this exists next to the first-party Sales plugin.** Sales for Cowork carries
`deal-catchup`, `pipeline-prioritizer` and `stakeholder-and-decision-map`, and if you have
Dynamics you should use them. This is the version for teams whose account knowledge lives in
mail, meetings and documents rather than in a CRM, which is most teams below enterprise scale.

## Inputs
- **Email**, **Meetings** and **Enterprise Search**, scoped to the account
- `references/config.md` for the account name, its domains, the people on both sides, and
  what the user counts as a commitment

# One-to-One Prep

Walks into the 1:1 knowing what you owe them, which is the half most prep skips.

## Inputs
- **Email**, **Meetings** and Teams traffic between the user and that person
- `references/config.md` for the window and what counts as a commitment
- The prior brief, if one exists, so items do not reappear as new

## Procedure
1. **Scope to the two people.** Threads where both are present. A group thread counts only if the
   person contributed to it.
2. **Build four lists, in this order:**
   - **What you owe them.** Commitments the user made, quoted and linked. **This section is

# Project Decomposer

Turns a project into tasks somebody can actually finish, each with a stated way to tell it is done.

**This skill does no work.** It decomposes and stops. If a task it produces looks like something
Cowork could do, that is a separate request the user makes deliberately.

## Inputs

- A project description from the user, or a named document found through **Enterprise Search**
- Existing context: prior decisions, related threads, the people already involved
- `references/config.md` for team names, the default task size and the house verification bar

## Procedure

# Team Lead Mode

Runs the pack in order and assembles one review, rather than making you run four things.

🔴 **This is not multi-agent, and the distinction matters.** Grok Bot has a roster of Bots that
message each other and pass ownership. Cowork runs **one task that loads several skills**. This
skill calls others in sequence inside that single task. If you came here expecting agents
negotiating, that is the capability Cowork does not have, and pretending otherwise would waste
your afternoon.

## The skills it invokes, in order

1. `workstream-health` if installed, else read `project.md` files directly and say you did
2. `one-to-one-prep` for each direct report named in config

# <Bot name>

<One line: the repeatable outcome this owns. Not a category.>

## Inputs

- What the user supplies, if anything
- Which built-in skills this reads through: Email, Enterprise Search, Meetings, Deep Research,
  Calendar Management, Excel, Word
- Which config file it reads, if any

## Config the user edits

Read `references/config.md` at the start of every run. If it is missing, say so once and continue