panaversity WORKPLACE MEMORY WORKFLOW
STEP 1 — LOAD CONTEXT
Read work.local.md in the current working directory.
If it does not exist, tell the user to run /agentic-office:setup first.
STEP 2 — IDENTIFY REQUEST TYPE
TYPE 1: ADD PERSON Input: Name, role, reporting line, communication style, current focus, any sensitivities Output: Formatted person entry for work.local.md Layer 2 + confirmation
PERSON ENTRY FORMAT:
- name: "[Full name]"
role: "[Job title]"
reports_to: "[Manager name]"
communication: >
[How they prefer to receive information; what works; what annoys them]
current_focus: "[What they are working on right now]"
priorities: "[Their current top 1-3 priorities]"
note: "[Anything important about working with this person]"
sensitivity: "[Optional — anything that must not be shared broadly]"
TYPE 2: ADD PROJECT Input: Project name, codename, status, priority, owner, description, current milestone, risks, decisions already made Output: Formatted project entry for work.local.md Layer 3 + confirmation
PROJECT ENTRY FORMAT:
- name: "[Project full name]"
codename: "[Internal codename if different]"
status: "[PLANNING / IN PROGRESS / AT RISK / BLOCKED / COMPLETE]"
priority: "[P1 / P2 / P3]"
owner: "[Named person]"
description: >
[What this project is; why it matters; key context]
current_milestone: "[What is happening now]"
next_milestone: "[What comes next; by when]"
at_risk: "[What could go wrong; what is currently stalled]"
decisions: ["[Decision made; date]"]
key_contacts: ["[Person; role in project]"]
TYPE 3: ADD TERM Input: Term, definition, when to use, when NOT to use, related terms Output: Formatted terminology entry in Layer 4 + confirmation
TERMINOLOGY ENTRY FORMAT:
"[Term]": >
[Definition in plain language — what it means in this organisation]
Use: [When this term is appropriate]
Not: [When NOT to use it — external comms? formal docs? pre-announcement?]
Related: [Synonyms or near-synonyms]
TYPE 4: PERSON BRIEF Input: Person name (or "everyone I'm meeting today" with list) Output: Structured brief per person
PERSON BRIEF FORMAT:
--- [NAME] — [Role] -----------------------------------------------
Reports to: [Name]
Current focus: [What they are working on]
Communication: [How to approach them today]
Today's context: [Anything live that affects this interaction]
How to approach: [Specific guidance for today]
Watch for: [Anything to be aware of]
Do not: [Any specific sensitivities]
-------------------------------------------------------------------
TYPE 5: POST-MEETING UPDATE Input: Meeting name, decisions made, new actions, status changes, new information about people Output: Proposed updates to work.local.md across all relevant layers
PROPOSED UPDATES FORMAT:
MEMORY UPDATE PROPOSAL — [Meeting Name] — [Date]
================================================================
1. UPDATE: [Section]: [What changes]
Current: "[Old text]"
Proposed: "[New text]"
[Continue for each update]
Confirm to apply all? Or specify which updates to apply.
================================================================
TYPE 6: TERMINOLOGY QUERY Input: "What does X mean?" or "What do we call Y?" Output: Load from terminology dictionary in work.local.md; apply in the response; if not found, offer to add
STEP 3 — EXECUTE AND CONFIRM
For ADD operations (Types 1-3): Draft the entry, present for confirmation, then write to work.local.md only after user confirms.
For QUERY operations (Types 4, 6): Load from work.local.md and present.
For UPDATE operations (Type 5): Propose all changes, let user select which to apply.
Sensitivity Handling
Some entries contain sensitive information:
- Succession planning (who is being considered for a role)
- Personal information about employees
- Commercial sensitivities (unannounced projects; pricing)
- Interpersonal dynamics (conflict; performance concerns)
RULES for sensitive entries:
- Add to work.local.md with a
sensitivity: RESTRICTEDflag - Never surface in outputs where the subject might see them
- Never include in shared briefings or group outputs
- Apply only when directly relevant to the specific interaction
Memory Maintenance Rules
STALE MEMORY DETECTION: Flag any entry in work.local.md that has not been updated in >90 days and prompt user to confirm or update.
Common staleness patterns:
- Person's role has changed but work.local.md has old title
- Project status is "IN PROGRESS" but it was completed months ago
- Terminology entry references a product or team that no longer exists
NEVER DO THESE
- NEVER add a person entry without confirming the communication style observation is accurate (not assumed)
- NEVER apply a person entry's sensitivity notes in a group output where the subject might see it
- NEVER mark a project as COMPLETE without noting what was delivered and what (if anything) was not delivered
- NEVER add a terminology entry without defining BOTH when to use and when NOT to use the term
- NEVER propose memory updates without the user's explicit confirmation