Ben Willett Get in touch

Claude plugin · v2.3.1

Event Ops & Intelligence Suite

Know what needs attention across every event.

A tradeshow calendar lives across inboxes, spreadsheets and memory, so what is overdue is whatever someone remembers. This plugin turns updates into one current view of deadlines, priorities and follow-ups.

  1. 11

    Skills

  2. 6

    Subagents

  3. 1

    Writer

  4. 37

    Tests

Counted from the plugin's own source, not from its use. There are no adoption or time-saving figures for this project and none are claimed.

See what it returns Follow an approval Project details Explore the system Engineering decisions

The morning brief

What it returns on a given day. Every flag carries the rule that raised it.

What you say

  1. We're exhibiting at Atlas Logistics Summit, March 15–17 in Phoenix.

    New event record, phase APPROVED — a go decision, so it needs an explicit yes on file.

  2. Artwork went up Friday. Still waiting on the rep for the final headcount.

    One item closed, one parked on someone else, both stamped with who said so and when.

  3. Is the badge-scanner order confirmed?

    An open question on the record, so the next brief can ask it back.

What comes back

evt brief today --today 2027-03-04

Event Ops: Thu Mar 4

2 active · 2 at risk · 0 on track · 1 in pipeline

Top 3

  1. Status check on Atlas Logistics Summit 2027 (about 10 minutes) P0

    Atlas Logistics Summit 2027, in 11 days

    Why: Record last verified 2027-01-15 (48 days ago); the event is in 11 days with 3 open item(s) and 1 open question(s).

  2. Post-event report P0

    Meridian Operations Forum 2027, +13 days

    Why: hard deadline tomorrow

  3. Confirm (or do): Event sales alignment meeting P0

    Atlas Logistics Summit 2027, in 11 days

    Why: required milestone not done and the event is in 11 days

Critical

  • Event sales alignment meeting P0 19 days overdue

    Atlas Logistics Summit 2027, in 11 days

    Why: required milestone not done and the event is in 11 days

    Added by the system after its due date — if it already happened, say so and it gets closed.

  • Post-event report P0 tomorrow

    Meridian Operations Forum 2027, +13 days

    Why: hard deadline tomorrow

The full run continues with Events, Due this week and To confirm — including two items the rule engine raised on its own, a post-event debrief and leads not yet confirmed in the CRM.

A real run of the engine over three invented events, with the date fixed so the result is reproducible. Every priority, reason and overdue count is the engine's; the page does not run it.

One approval, end to end

Three scenarios, one path. Pick the sponsorship commitment to see the engine refuse the write until an approval is recorded.

Interactive walkthrough using sample event data. No live business actions are performed.

What we used it on

Two people used this: my manager and me. Those are two different kinds of use, and they are worth keeping apart.

Five live events ran through it. Deadlines, booth details, vendors, line items and approvals for shows we actually operated — the records the morning brief above is drawn from, and the work the four approval tiers were built for.

More than 200 prospective events were researched through it, and not run. For an event we were only considering, the research skills scored industry fit and pulled leads, opportunities and ROI from our Salesforce records, which reach the plugin through the HubSpot sync. Set against total event spend and the KPIs for the program, that is enough to say whether a show is worth attending. It is an input to a decision a person makes, and no revenue is claimed for it.

Project details

My role

I built all of it: the data model, the Python state engine that is the only thing allowed to write, the four-tier approval model, eleven skills and six read-only subagents, and the 37 tests that hold it together. I specified it, directed the build with Claude Code and reviewed every part of it. No collaborators on the plugin itself.

Built the same way I built the RFP plugin: specified by me, assembled with Claude Code, reviewed line by line. Unlike the RFP and Sales Intelligence modules, this is not part of the internal application — it is a plugin my manager and I installed and shared, and it ran on our real event work. The employer is a Human Capital Management B2B SaaS company and is not named here, and no real event, client or colleague appears on this page.

Project status

Version 2.3.1, packaged and installed in the Claude desktop app — one install covers both Claude Code and Cowork. Two people used it, my manager and me: we ran five live events through it, and used it to research more than 200 prospective ones. Not every shipped capability was exercised on that work — the communication sweep is a preview that proposes and writes nothing without a yes, and the drafting workflows need their connectors authorized.

Validation and scope

  • It sends nothing — no email, no chat message, no social post. The content skills produce drafts a person sends, and no component holds a tool that could send.
  • CRM writes need an explicit, recorded approval. Marketing email exists only as a draft.
  • The plugin file contains no event data. The records live in a folder on our own machines.
  • Researching an event is not winning one. The 200+ prospective events were evaluated, not run, and no revenue is attributed to that research anywhere on this page.
  • It is a plugin, not an application: no web interface, no server, no database. Files, one command-line tool and a set of skills — which is what lets one install run in two different Claude surfaces.
  • The brief on this page is a recorded run over invented events. The site does not run the engine.

Built with

  • Claude plugin
  • Python 3 (standard library)
  • JSON Schema
  • Claude Code
  • Cowork
  • Microsoft 365 (read-only)
  • HubSpot
  • Salesforce (via HubSpot sync)
What the engine computes, and what it only stores

Facts are stored: dates, booth details, vendors, line items, work items, notes, captures, open questions. Status is not. Phase, overall status, priority, which bucket an item falls into and the next best action are recomputed on every run and cached separately, so a recomputation can never corrupt a fact.

Every flag carries a rule identifier and a reason, and every item carries where it came from. That is why the brief can say why it is telling you something, and why an explain command can answer the same question about any single item.

Deadlines that are real but unknown are represented as such, rather than dropped. "There is a hotel cutoff and nobody knows the date" is a different state from "there is no hotel cutoff", and the first one is the one that loses a room block.

How the sample brief on this page was produced

A throwaway folder was created, three invented events were added through the same operations path the plugin uses, a handful of updates were applied, and the brief command was run with a fixed date. The output is transcribed into the page as data.

Two things were removed and nothing was added: the warning the engine prints when the date it was given differs from the machine's, and the sections after Critical, which list the same items again under different headings. The priorities, the reasons, the overdue arithmetic and the two items the rule engine raised by itself are all its own.

What I'd do next
  • Let well-sourced inbox items apply automatically, once I have compared what the sweep proposes against what gets accepted. It ships as a preview for that reason.
  • Re-plumb CRM metrics into the event records as dated snapshots, so per-event performance is part of the record rather than a report beside it.
  • Swap the storage layer for a database behind the same interface. The records, journal and audit log were shaped to map onto tables — what a second user would need.
  • Establish a time baseline before claiming any time saved. There is no measured before-and-after here and the page does not imply one.

Explore the system

The orchestrator, the specialist skills, and the one engine allowed to write.

What it does

Eleven skills, grouped by the job they do.

  • Know where everything stands

    You say
    Catch me up. What am I forgetting? What is waiting on someone else?
    You get
    A prioritized brief with a reason beside every flag, and a weekday morning version that runs on a schedule.

  • Record a change by saying it

    You say
    The artwork went up Friday. The alignment meeting moved to the 9th.
    You get
    A line back saying exactly what changed, and a record that still agrees with itself a month later.

  • Capture the floor

    You say
    Rough notes from the booth — who you met, what they said, who follows up.
    You get
    Structured captures against the event, and follow-ups summarized by owner once the show ends.

  • Find what the inbox already told you

    You say
    Check my email for event deadlines.
    You get
    A list of proposals to accept or reject. In this release nothing is written until you say yes.

    Needs a connected mailbox

  • Research, report and draft

    You say
    Should we go to this one? How did that show perform? Draft the follow-up.
    You get
    A fit scorecard, a per-event performance view, and drafts. Nothing is sent, posted or scheduled.

    CRM views need a connected account

Key engineering decisions

Pick one to read it. The constraint, the implementation and the cost are behind each.

Choose an engineering decision to read

One command-line engine makes every change to event state

Two assistants writing the same records had already produced two different shapes for the same thing, so writing became one small program's job.

The constraint, what I built, and what it cost
The constraint
The previous version let agents write event files directly. The same agent wrote two records with different field names for the same facts, item ids in two formats, and dates that disagreed with the index. Nothing was wrong with any single write; there was simply no one place where "what an event record looks like" was decided.
What I implemented
A Python command-line tool is the only thing that writes. Everything else proposes a batch of typed operations — seventeen kinds, no more — and the engine validates the batch against a strict schema, de-duplicates it, resolves which source wins, writes it and appends an audit line. A batch is all-or-nothing: if one operation is invalid, nothing is written at all.
What it cost
Every change costs a round trip through the engine, and a new kind of change means a new operation type, a schema field and a test rather than a sentence in a prompt. In exchange the records still agree with each other months later, which the previous version could not promise for a fortnight.

Instead ofletting each skill write the JSON it needed, which is what the previous version did.

"Today" is an input, not something the system reads off the clock

Everything the system says is a function of the files plus one date, so any answer can be reproduced and every rule can be tested against a future it has not reached yet.

The constraint, what I built, and what it cost
The constraint
Almost every useful statement here is about time — eleven days out, two days overdue, a report due at plus fourteen, a record last verified six weeks ago. Passing the date explicitly makes time-dependent behavior reproducible in tests; reading the clock makes the answer change underneath them.
What I implemented
One date is passed in on every run and nothing else reads the clock. Phase, status, priority, the rule evaluations and the reminder de-duplication are all pure functions of the stored files and that date, so the same inputs always produce the same brief. The test suite drives the real command-line tool through dated scenarios, including ones months ahead.
What it cost
Every caller has to supply the date, and a caller that supplies the wrong one gets a confidently wrong answer — so the engine warns when the date it was given disagrees with the machine's. The alternative is date arithmetic nobody can re-run.

Instead ofhaving each component ask the operating system for the current date when it needs it.

The system may add and raise things; it may not close, send, spend or decide

Four tiers, enforced by the engine rather than requested in a prompt — and the highest one is not a permission at all, it is a capability the system was never given.

The constraint, what I built, and what it cost
The constraint
A proactive assistant that can also close items is an assistant that can quietly decide something is finished. The useful behaviour and the dangerous behaviour are a single step apart.
What I implemented
Each operation carries a tier. Adding an item, raising a flag or saving a note is automatic and logged. Closing, re-dating or deleting needs a confirmation. Anything external-facing, financial, strategic or a go/no-go needs an explicit yes, quoted in the batch — and the engine rejects the operation outright if that record is missing. A scheduled or automated run is restricted to the automatic tier, in code. Sending, posting and paying are not a tier: no component is granted a tool that can do them.
What it cost
More prompts than an assistant that just acts, and a tiering table to maintain as the system grows. The approval records are also written by the assistant after the fact — auditable, but not tamper-proof, which is adequate for one user and would not be for a team.

Instead ofa single confirmation step before anything that looked destructive.

Subagents get a slice of context and return JSON

The parts that read mail, the web and the CRM cannot write anything, which keeps the single-writer rule true no matter how many of them run at once.

The constraint, what I built, and what it cost
The constraint
Research and extraction are the slowest parts of the work and the most worth running in parallel. They are also the parts reading text from outside — organizer emails, vendor notes, web pages — which cannot be allowed to act on the records they describe.
What I implemented
Each subagent is given exactly the slice of an event it needs and returns schema-valid JSON. None of them has a file-writing tool. Six of them run in parallel across candidate events, mailboxes or shows, and their output becomes proposed operations that go through the same engine as everything else. Outside text is treated as data: an email saying to reply today becomes a task with a source, never an instruction.
What it cost
The skill that dispatched them has to hold the conversation and apply the result, so the agents cannot finish a job on their own. That is the point — it is what stops a parallel sweep from becoming six parallel writers.

Instead ofgiving the agents file access so they could record what they found as they found it.