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.
This commit is contained in:
1 parent
339d753746
commit
60a054167d
1 file changed
+20
@@ -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
|
||||
|
||||
Reference in new issue
Block a user