From 2f8ba0b80b82ac687b6cb551a5619460b7bb3295 Mon Sep 17 00:00:00 2001 From: "Bryan Gilliom (via Claude)" Date: Tue, 22 Sep 2026 21:40:21 +0000 Subject: [PATCH] Add end-agency enrichment and the channel/pricing confidentiality rule Bryan, two related requests: 1. When a topic has a real end-client agency, the skill should resolve its full identity -- not just whatever name got said in the meeting. Added as a new standing step: check the MPM Technical Reference System first (agency-roster.md, clients-and-partners.md -- cheap, already-vetted), fall back to public web research, resolve BOTH the legal entity name and the separate transit brand name distinctly (validated pattern, confirmed against MPM's own FTA filings for Oshkosh: 'City of Oshkosh, Wisconsin, dba: GO Transit'), re-host the logo as a data URI rather than hotlinking it, and capture general agency contact info. Gets its own 'End Agency' card, separate from individual attendees. 2. Pricing shown in the Oshkosh brief was correct for an internal audience, but Bryan flagged that an external-facing version must never show the end agency MPM's price to the reseller -- they aren't privy to it. Documented as a new Hard Rule, grounded directly in the Technical Reference System's own reseller-channel.md (MPM's contract of record is with the reseller, not the agency, on channel accounts) rather than invented from scratch. Doesn't change internal-meeting- brief's current behavior (it's internal by definition) -- recorded here as the binding rule for vendor-partner-brief and kickoff-brief's external-client variant, neither built yet. --- skills/internal-meeting-brief/SKILL.md | 39 +++++++++++++++++++ .../references/section-structure.md | 5 +++ 2 files changed, 44 insertions(+) diff --git a/skills/internal-meeting-brief/SKILL.md b/skills/internal-meeting-brief/SKILL.md index a836bbb..416ab5e 100644 --- a/skills/internal-meeting-brief/SKILL.md +++ b/skills/internal-meeting-brief/SKILL.md @@ -178,6 +178,31 @@ fixed list per brief type: here, or flag it `open` if the registry doesn't resolve it (e.g. a variant with no assigned code yet). This registry is a genuine dependency, not this skill's own content to maintain — see Dependencies. +- **End agency / client organization — identify and enrich it, not just the people.** + When a topic has a real end client (a transit agency, most commonly), resolve its + full identity, not just whatever name got said in the meeting: + 1. Check the MPM Technical Reference System first — `60-proof/agency-roster.md` + (is this agency already a known MPM deployment? gives HQ city/state) and + `60-proof/clients-and-partners.md`. Cheap, already-vetted, check before the web. + 2. If not found or incomplete, search the public web for the agency's official + site. Resolve **both** names, distinctly — most transit agencies have a legal/ + governmental name and a separate public transit brand, and both matter for + different reasons (contracts use the legal name; everything rider-facing uses + the brand). The precise, correct pattern — confirmed against MPM's own FTA + filings for Oshkosh — is **"[Legal Entity], dba: [Transit Brand]"** (e.g. "City + of Oshkosh, Wisconsin, dba: GO Transit"). Don't collapse these into one name or + guess which is which. + 3. Pull the agency's logo and re-host it as a data URI embedded in the brief — do + not hotlink to an external image URL. This is the same "own content at + creation" principle already applied to fonts/tokens elsewhere in Brief: the + brief must survive as a standalone file even if the agency's website changes. + 4. Capture the agency's general contact info (main line, address) alongside — not + a replacement for a named individual contact (see attendee resolution above), + supporting information for anyone reading the brief who needs to look the + agency up independently. + Present this as its own clearly-labeled card/section (see + `references/section-structure.md`), separate from the internal attendee list — + this is organizational identity, not a meeting participant. Helpdesk ticket review is still a deliberate, manual exception (see below) — not pulled automatically regardless of topic type. @@ -268,6 +293,20 @@ person needs to actually see and review it, not just trust it happened. correct; a brief with invented content to fill them is not. - **Bounded queries only.** Gmail/Chat scans are scoped by project keyword + date window from the manifest. Never an open-ended search. +- **Channel/pricing confidentiality by audience.** internal-meeting-brief is internal + by definition, so this doesn't block anything it currently does — but it's the rule + that must govern any future external-facing brief type (vendor-partner-brief, + kickoff-brief's external-client variant), so it's recorded here where the pattern + first came up. Grounded in MPM's own Technical Reference System + (`60-proof/reseller-channel.md`): on a reseller-sold account, **MPM's contract of + record is with the reseller, not the end agency** — the agency is not privy to + what MPM charged the reseller, only to whatever the reseller separately agreed + with them. A brief ever shown to the end agency must exclude MPM's own SO/PO + pricing entirely on a channel account, not just redact the total — line-item + pricing implies the same thing. This is not "hide pricing from external + audiences" generically: a *direct* account (no reseller) showing an agency its own + figures is normal. The dividing line is whether there's a reseller between MPM and + the reader, not whether the reader is external to MPM. - **No live publishing yet.** This skill produces a local file only. Hosting/publishing (a shareable link, external access control) is CW-029 (Brief Server) — deliberately separate, deliberately not built yet. Don't attempt to stand up delivery diff --git a/skills/internal-meeting-brief/references/section-structure.md b/skills/internal-meeting-brief/references/section-structure.md index 8023c2c..717e0d7 100644 --- a/skills/internal-meeting-brief/references/section-structure.md +++ b/skills/internal-meeting-brief/references/section-structure.md @@ -18,6 +18,11 @@ structure per meeting. This is the contract — read it before generating a brie When external counterparts are named in discussion but weren't present, give them their own card group ("Named in discussion, not present") with resolved contact info (see SKILL.md step 4) rather than omitting them or burying them in prose. + **If the topic has a real end-client organization** (an agency, most commonly), + give it a distinct "End Agency" card of its own — separate from individual + people — showing the legal-name/brand-name pair (e.g. "City of Oshkosh, dba: GO + Transit"), a re-hosted logo, website, and general contact info. See SKILL.md + step 5. 3. **Topics Covered** — a `cards` grid, one card per distinct subject actually discussed. Card count and grid density (c2/c3/c4) follow the number of real topics — don't pad to hit a round number, don't force unrelated topics into one card to save