From 60a054167df0f6f25f140ed15672ec18bc109f38 Mon Sep 17 00:00:00 2001 From: "Bryan Gilliom (via Claude)" Date: Tue, 22 Sep 2026 22:32:13 +0000 Subject: [PATCH] Add feedback-loop instruction and Echo Memory/Goldbrain as an optional source Bryan's request: set up a channel for field usage (by anyone at MPM using an installed copy of this skill, not just Bryan talking directly to Claude) to feed back into plugin maintenance. Added: - A Drive folder, 'Brief - Feedback Log', with a _SCHEMA.md defining the trigger (the person had to ask for something the skill's instructions didn't already cover) and format (one small file per entry, not one shared growing document -- avoids concurrent-write clobbering when many different Claude sessions across the org write to the same folder). - A new SKILL.md section instructing this skill to write an entry there whenever that trigger fires. - Echo Memory / Goldbrain (personal Obsidian vaults some MPM staff keep) added as an optional, per-person-checked data source -- never another person's vault, never assumed present. This pattern (the feedback folder + the SKILL.md instruction to use it) needs to be part of every future Brief skill from the start, not bolted on later -- noted in CW-027's Concept.md. --- skills/internal-meeting-brief/SKILL.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/skills/internal-meeting-brief/SKILL.md b/skills/internal-meeting-brief/SKILL.md index 416ab5e..4ce0f7c 100644 --- a/skills/internal-meeting-brief/SKILL.md +++ b/skills/internal-meeting-brief/SKILL.md @@ -63,6 +63,13 @@ Other tools this skill uses: `_INDEX.md` first — it's the routing table — then only the specific files a claim actually needs. This is where part numbers, model codes, and product/technical claims get verified; it is not this skill's content to maintain, only to reference. +- **Echo Memory / Goldbrain (if the current person has one — check, don't assume)** — + Obsidian-based personal memory vaults some MPM staff maintain across Claude/CoWork + sessions. Not universal, and strictly personal: if available, only ever check the + *current* person's own vault, never someone else's. If the topic or its attendees + come up in the person's vault, that's real context (prior decisions, relationship + history, things they've noted about this project) worth pulling in — but this is a + bonus source, not one to block on if the person doesn't have one connected. If any of these fail outright (not just "returns nothing," but errors or times out), say so plainly in the generated brief's Notes & Flags section rather than silently @@ -286,6 +293,19 @@ customer. Hand the file to the person. Don't silently skip presenting it even if archived — the person needs to actually see and review it, not just trust it happened. +## Feedback loop — write back when the person had to ask for something + +If the person running this skill has to ask you to do something the skill's +instructions don't already cover — pull from a source not listed above, add a +section, change a structural default, anything that's a gap rather than a one-off +factual fix to that single brief — **write a short entry to the shared feedback log** +in Drive: `CW-027 — Brief` coordination folder → `Brief — Feedback Log/`. Read +`_SCHEMA.md` there for the exact format before writing your first entry. This is how +gaps found by anyone using an installed copy of this skill make it back to whoever +maintains the plugin, rather than being fixed once in that person's conversation and +then lost. Write the entry regardless of whether you also fix the immediate request — +those are two different things. + ## Hard rules - **Never fabricate.** No matching Plaud recording, no linked Odoo data, an empty