Update

Update

Ingest external information into this ops repo's knowledge base. Two modes depending on whether arguments are provided.

Detect Mode

• If $ARGUMENTS is non-empty → Inline mode: the arguments contain the information to integrate.
• If $ARGUMENTS is empty or blank → Inbox mode: process files from .update/.

---

Inline Mode

The user provided content directly: $ARGUMENTS

1. Load context. Read CLAUDE.md and MEMORY.md to understand the repo structure, goals, and current state.

2. Classify the information. Apply the whole-file test from CLAUDE.md — fact about the world, or decision/framework?

   • Fact about the world (status, metric, inventory) → state/
   • Decision / strategy / framework / guardrails / research → references/
   • Specific actions to do next → backlog/
   • Delivered output → artifacts/
   • Strategic insight → may also warrant a MEMORY.md Key Learnings update
   • Mixed → split

   Trap: "current strategic posture" content feels state-shaped but is forward-looking strategy → references/.

3. Integrate. For each piece of information:

   • Read the target file first — never overwrite blindly. Merge or append.
   • When updating state files, update the _Last updated: YYYY-MM-DD_ line.
   • When adding backlog items, insert in priority order (highest first), not at the end.
   • If placement is genuinely ambiguous, ask the user before proceeding.

4. INDEX.md cascade. For every file created or significantly changed, update that folder's INDEX.md. If the folder's overall summary changed, cascade to the parent INDEX.md.

5. MEMORY.md check. If the information shifts the project's strategic understanding — a new constraint, a key learning, a changed goal — add or update an entry under Key Learnings. Don't add specific data points (those belong in state/references); only add general insights.

6. Summarize. Tell the user what was placed where.

---

Inbox Mode

Process all files in the .update/ directory.

1. Load context. Read CLAUDE.md and MEMORY.md.

2. List files. Check .update/ for files (skip .gitkeep). If empty, tell the user "No files in .update/ to process" and stop.

3. Process each file. For each file in .update/:

   a. Read and understand the file's contents. Consider the filename, format, and content to determine what it is.

   b. Classify — same categories as inline mode (status update, research, task, deliverable, mixed).

   c. Extract and integrate relevant information into the knowledge base:

   • Create or update files in state/, references/, backlog/, or artifacts/ as appropriate.
   • Read target files before writing — merge, don't overwrite.
   • Update _Last updated:_ dates on state files.
   • Insert backlog items in priority order.

   d. INDEX.md cascade — update every affected INDEX.md.

   e. Dispose of the source file:

   • Delete if all useful information has been extracted into structured knowledge (the common case — raw notes, status emails, data dumps).
   • Move to references/ if the file itself is a useful reference to keep (e.g., a PDF report, a detailed analysis document).
   • Move to artifacts/ if the file is a deliverable or work product (e.g., a submitted application, a finalized spec). Date-prefix it if it's been delivered.
   • If unsure whether to keep or delete, ask the user.

4. MEMORY.md check — same as inline mode. Update Key Learnings if warranted.

5. Summarize. List each file processed, where its information was placed, and whether the file was deleted or moved.

---

Rules

• State vs. backlog separation — facts about current reality go in state/. Actions and opportunities go in backlog/. Don't mix them.
• Don't duplicate — before creating a new file, check if an existing file already covers that topic. Extend the existing file rather than creating a parallel one.
• Preserve structure — follow the repo's existing organizational patterns. If grants info lives in references/grants/, new grant research goes there too.
• Cite sources — if the incoming information references external sources (URLs, documents, people), preserve those citations in the integrated output.
• Be conservative with MEMORY.md — most updates don't warrant a Key Learnings entry. Only add entries that change the project's strategic understanding.