# Inbox

> Inbox

- Skill: `eugenezhangco-spec/inbox` (Agent Skill)
- Install (CLI): `npx skillmds@latest add eugenezhangco-spec/inbox`
- Raw SKILL.md: https://api.skillmd.com/api/skills/eugenezhangco-spec/inbox/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: eugenezhangco-spec (https://skillmd.com/u/eugenezhangco-spec)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/eugenezhangco-spec/inbox

---

# /inbox — Process New Context

When this skill is triggered, perform ALL of the following steps:

## Step 1: Check the inbox

List all files in `context/inbox/`. If empty, say "Inbox is empty — nothing to process" and stop.

## Step 2: Read every file

For each file in the inbox:
- **PDFs**: Read and extract all content
- **Word docs (.docx)**: Read and extract all content
- **Excel files (.xlsx)**: Read every sheet, every row, every cell
- **PowerPoint (.pptx)**: Read all slides and speaker notes
- **Email threads (.pdf/.eml)**: Read full thread, identify key decisions and action items
- **Markdown/text**: Read in full
- **Images/screenshots**: View and describe what's shown

## Step 3: Brief in plain English

For each file, provide:
- **What it is** (1 sentence)
- **What's new or important** (2-3 bullets)
- **Does it change our current plan?** (yes/no + why)
- **Action items** (if any)

Keep the briefing concise — just the highlights.

## Step 3b: Write AI Build Brief (if build-relevant)

If any inbox items contain new requirements, scope changes, feature requests, architectural decisions, or anything that affects what gets built:

1. Write a structured handoff file to `context/sessions/YYYY-MM-DD-HHMM-inbox-[topic].md`
2. Use the same format as a `/wrap` handoff (same frontmatter schema)
3. Set `status: ready` so `/pull` can load it

**File content must include:**
- **What This Session Was About** — why this inbox item matters to the build
- **What Was Decided** — any decisions or direction changes derived from the content, written as directives
- **Build Brief** — what needs to be built or changed, written for AI consumption. Specific and discrete. A fresh session must be able to plan from this without reading the original document.
- **Constraints and Boundaries** — what must not change, what assumptions must not be made
- **Open Questions** — anything that needs a decision before planning can start

4. Say: "I've written a build brief to `context/sessions/[filename]`. Run `/pull` in your build session to load it into planning."

**Do not write a build brief for purely informational items** (stakeholder profiles, historical docs, emails with no action items). Only write one when the inbox content has direct build implications.

## Step 4: Sort files to proper locations

Move each file from `context/inbox/` to the appropriate folder:

| File type | Destination |
|-----------|------------|
| Business plans, historical docs | `context/archive/business-plans/` |
| Technical specs, briefs | `context/archive/technical-briefs/` |
| Pitch decks, presentations | `context/archive/pitch-decks/` |
| Research, analysis, reports | `context/archive/research/` |
| Prep docs, confidential | `context/archive/prep-docs/` |
| Media files (audio, video) | `context/archive/media/` |
| Email threads, meeting notes | `context/communications/` |
| Requirements, schemas, strategies | `context/requirements/` |
| Stakeholder profiles | `context/stakeholders/` |

**Rename files** to be descriptive and kebab-case. Remove UUIDs and cryptic names.
Example: `6a485b84-e637-48dc...pdf` → `stakeholder-call-prep-march-2026.pdf`

**Create new subfolders** if needed. The structure is dynamic — if a file doesn't fit existing folders, create an appropriate one (e.g., `context/legal/`, `context/funding/`, `context/[partner-name]/`).

## Step 5: Update STATUS.md

Read `context/STATUS.md` and update with any new information:
- New decisions or direction changes
- Updated timelines or milestones
- New stakeholders or relationships
- Changed priorities or scope

## Step 6: Update ENGINEERING.md (if technical content)

If any inbox files contain technical specifications, schema changes, API details, or architecture decisions:
- Update `context/ENGINEERING.md` with the new technical details
- Note what changed and why in a changelog entry

## Step 7: Update EXPLAINED.md (if it affects the owner's understanding)

If new context changes the project direction, adds new concepts, or modifies how things work:
- Update `context/EXPLAINED.md` so the plain-English reference stays current
- Keep the plain-English style and teaching tone

## Step 8: Propose Backlog Items (if work-relevant)

If any inbox items contain new requirements, scope changes, feature requests, architectural decisions, bugs, or stakeholder asks that imply work the team will do:

1. **Query Graphify first** (if a graph exists) — `get_neighbors` on any module the inbox content seems to touch. This makes the proposed items concrete from the start.
2. **Query MemPalace** for prior decisions on the topic — has the user already scoped or rejected something similar?
3. **Propose** discrete backlog items to the user before writing them. Format:
   ```
   I see N candidate backlog items in this inbox:
   1. [Title] — [Type], [Priority], 1-line scope summary
   2. [Title] — ...
   Want me to draft these as backlog entries?
   ```
4. After the user approves: copy `context/backlog/_template.md` for each item to `context/backlog/<YYYY-MM-DD-slug>.md`. Fill the discipline fields per `.claude/rules/backlog-protocol.md`. Status starts as Drafted (or Approved if the user approved scope live in chat AND all required fields are filled).
5. For larger / more complex items, also write a brainstorm handoff to `context/sessions/YYYY-MM-DD-HHMM-inbox-[topic].md` (same format as a `/wrap` handoff, `status: ready`) so `/pull` can load it into a deep planning session. Reference the spawned backlog slug(s) in the handoff.

**Do not propose backlog items for purely informational content** (stakeholder profiles, historical docs, emails with no action implication). File those and move on.

## Step 9: Update memory

Save any important new context to the memory system:
- New stakeholder information → update or create stakeholder memory
- New project decisions → update project memories
- New technical decisions → update technical decision memories
- Changed timelines or priorities → update status memories

## Step 10: Confirm

After processing, provide:
- Summary of what was processed
- Where each file was moved
- What was updated (STATUS.md, ENGINEERING.md, EXPLAINED.md, backlog, memory)
- **Backlog:** N new items proposed/drafted, N existing items updated
- Any questions or decisions that need input

## When to trigger

This skill runs when you say any of:
- "/inbox"
- "check the inbox"
- "new stuff"
- "read the updates"
- "there's new files"
- "I dropped something in the inbox"
- "process the inbox"

## Verbal context

Verbal context may also be provided in chat instead of dropping files. When notes from conversations, calls, lunches, or text messages are shared:
1. Capture the key points
2. Create a markdown file in `context/communications/` with the date and topic
3. Update STATUS.md and memory as needed
4. Brief on what was captured to confirm accuracy
5. **If the verbal context has build implications** (new requirements, scope changes, feature requests, direction changes): also apply Step 3b — write an AI build brief to `context/sessions/YYYY-MM-DD-HHMM-verbal-[topic].md` with `status: ready`. Say: "I've written a build brief to context/sessions/[filename]. Run /pull in your build session to load it into planning."