Vault Assist

0a: Ingest Fresh Data (if triggered)

If the user triggers an ingest ("ingest", "fetch messages", "pull teams", etc.):

1. Run ingest scripts/skills to populate inbox. The exact mechanism depends on your integrations (Microsoft Graph API, IMAP, Slack API, etc.). Output should be markdown files in <vault>/inbox/ with frontmatter:

   ---
   source: teams  # or outlook, slack, etc.
   type: ingest
   date: YYYY-MM-DD
   ingested_at: ISO-8601-timestamp
   lookback: 2d
   ---
   

2. Continue to 0b to process the inbox.

0b: Process Inbox Files

If the user says "process inbox", "check inbox", or references an inbox file:

1. List files in inbox/:

   ls <vault>/inbox/
   

2. If multiple files, present them as numbered choices and ask which to process (or process all).

3. Read the selected file.

4. Triage by hub engagement. For each topic/thread in the input:

   • Map it to a hub note in <vault>/hubs/
   • Check the hub's engagement property
   • Apply processing depth:

   Engagement	Processing Depth
   active	Full: create context objects, draft replies, track actions
   involved	Medium: create context objects when relevant, replies only when asked
   tracking	Light: only create context objects for significant state changes, no replies

   What counts as "significant state change" for tracking-level hubs:

   • Project status changes (shipped, cancelled, blocked, pivoted)
   • Leadership or ownership changes
   • New hard deadlines or commitments that affect other hubs
   • Metric shifts >20% from last known baseline

   What does NOT qualify (skip for tracking hubs):

   • Routine status updates within an existing plan
   • Meeting scheduling or logistics
   • Minor metric fluctuations
   • FYI messages with no action required

   If a topic doesn't match any existing hub, flag it and ask the user.

5. Continue to Step 1 with the triaged contents as input.

6. Archive the processed file (Tier 2). After extracting context objects and surfacing the triage summary:

   mv <vault>/inbox/file.md <vault>/archive/<source>/file.md
   

   If the triage identified items needing user response (@mentions, unanswered questions, action items assigned to the vault owner), create a lightweight interaction_outcome context object with status: active tracking those items, so they don't fall through the cracks.

   Mention what was archived and what review items were created.

Step 1: Accept Input

The user pastes a message (from Teams, email, Slack, or any source). Parse it to identify:

• Sender - who sent it
• Topic/Project - what it's about
• Intent - what they're asking for or communicating
• Key entities - people, dates, commitments, decisions mentioned

Step 2: Retrieve Context

Using vault-ops, search the vault for relevant context:

1. Identify the hub. Match the topic to a hub note. Check backlinks:

   obsidian backlinks file="Project Alpha"
   

2. Pull related context. From the backlinks, identify relevant objects:

   • Recent project_state objects (current status)
   • Relevant decision objects (what's been decided)
   • Active constraint objects (what limits apply)
   • Relevant preference objects (communication style, priorities)

3. Keep it small. Size the retrieval bundle by hub engagement level:

   Hub Engagement	Bundle Size	What to include
   active	5-8 objects	Recent states, key decisions, active constraints, preferences
   involved	3-5 objects	Latest state + most relevant decisions
   tracking	1-2 objects	Latest state only, or skip if nothing changed

   Exclude status: superseded and status: archived objects unless the user asks about history. Prefer objects from the last 14 days.

4. Summarize what you found. Briefly tell the user:

   Retrieved context for Project Alpha:
   - 3 recent decisions (auth flow, caching strategy, release timeline)
   - 1 project state (last updated Feb 28)
   - 1 constraint (compliance deadline March 15)
   

5. Map organizational context. If the message involves resource allocation, timelines, or feasibility:

   • Look for org-structure context objects (team mappings, squad ownership)
   • Identify which team or person owns the topic
   • If the vault doesn't have team structure data, flag it as a gap in Step 3

Step 3: Identify Gaps

Check if you have enough context. If not, ask 1-3 clarifying questions:

• Prefer multiple-choice framing when possible
• Target decisions, commitments, or metrics - not open-ended exploration
• Use answers as authoritative context for the reply

Examples:

Before I draft the reply, a couple questions:

1. The deadline mentioned - is this the March 15 compliance deadline
   already in the vault, or a new one?

2. Should I reference the caching decision from last week, or has
   that changed?

If context is sufficient, skip to Step 4.

Step 4: Draft Reply

Produce a reply draft that:

• Directly addresses what the sender asked
• Incorporates vault context naturally (don't dump raw facts)
• Matches the communication medium (Teams = concise, email = slightly more formal)
• Includes commitments or next steps clearly
• Is ready to paste with minimal editing
• Follows the user's writing style - check for type: preference objects related to writing style or communication tone

Present the draft clearly:

Draft Reply:
---

[The draft reply text here]

---

Step 5: Propose Follow-Up Actions

If the exchange implies follow-up work, list it:

Follow-up actions:
- Schedule sync with Jane re: auth flow decision
- Update release timeline after March 15 review

Step 6: Propose Vault Updates

Determine if durable information should be written back. Only propose writes for:

• New decisions made or confirmed
• Updated project state
• New constraints or commitments
• Preference changes
• Significant insights

Present proposed changes using the vault-ops Change Set format:

Proposed Vault Updates:
---

1. CREATE context/decision-2026-03-02-auth-flow.md
   type: decision | project: Project Alpha | confidence: high
   "Confirmed PKCE auth flow. Security team approved."
   Links: [[Project Alpha]], [[Jane Smith]]

2. UPDATE context/state-2026-02-28-project-alpha.md
   Set updated: 2026-03-02
   Append: release timeline shifted to March 20

---
Apply these changes? (y/n)

If no vault updates are needed, say so explicitly:

No vault updates needed - routine exchange with no new decisions or state changes.

Step 7: Apply on Approval

When the user approves, apply changes using vault-ops procedures. Confirm what was written:

Applied:
- Created context/decision-2026-03-02-auth-flow.md
- Updated context/state-2026-02-28-project-alpha.md

Guidelines

Tone

• Be direct and efficient
• Don't over-explain vault mechanics - just use them
• Present context retrieval results concisely
• Focus on reply quality, not process

Context Quality

• If retrieved context seems stale (>30 days old), note it
• If retrieved context contradicts the pasted message, flag the discrepancy
• If no relevant context exists, say so and work from the message alone
• Token efficiency: Load metadata first when hub has >15 backlinks, then read full content only for the most relevant candidates

When NOT to propose vault updates

• Trivial exchanges ("thanks!", "sounds good", scheduling logistics)
• Information already captured in the vault
• Raw conversation text (extract structured facts instead)
• Speculative or unconfirmed information
• Routine status updates for tracking-level hubs (unless material state change)
• Insight that restates what an existing object already says
• Session already produced 3+ context objects - pause and ask before more
• Information only useful for current reply with no future retrieval value

When to create a new hub note

• If the message references a project/person/initiative with no existing hub, suggest creating one
• Hub notes are lightweight - just a title and brief description, backlinks do the rest

Example Session

User pastes:

From: Jane Smith Re: Project Alpha Auth

Hey, I talked to the security team and they confirmed we should go with PKCE for the auth flow. They also flagged that we need to support biometric fallback for devices without secure enclave. Can you update the spec and loop in James?

Agent:

Retrieved context for Project Alpha:
- 1 decision: "Evaluating auth options" (Feb 25, confidence: medium)
- 1 project state: "Phase 2 - authentication" (Feb 28)
- 1 constraint: "Compliance deadline March 15"

Draft Reply:
---
Got it - PKCE confirmed, and I'll add the biometric fallback
requirement to the spec. I'll loop James in on the updated spec
by EOD tomorrow.

Quick question: does the biometric fallback need to land before
the March 15 compliance deadline, or is it a fast-follow?
---

Follow-up actions:
- Update auth spec with PKCE + biometric fallback
- Loop James into spec review

Proposed Vault Updates:
---
1. CREATE context/decision-2026-03-02-pkce-auth.md
   type: decision | project: Project Alpha | confidence: high | source: meeting
   "Confirmed PKCE for auth. Security team approved.
    Biometric fallback required for devices without secure enclave."
   Links: [[Project Alpha]], [[Jane Smith]]

2. CREATE context/constraint-2026-03-02-biometric.md
   type: constraint | project: Project Alpha | confidence: high
   "Biometric fallback required for devices without secure enclave."
   Links: [[Project Alpha]]

3. UPDATE context/decision-2026-02-25-auth-options.md
   Set status: superseded (replaced by decision-2026-03-02-pkce-auth)
---
Apply these changes? (y/n)