Family Grocery

---
name: Family Grocery
description: "Shared family grocery list — multiple members add, remove, and view items organized by store. Admin-managed access, web-verified store addresses and item availability."
---

## When to Use

A family member needs to add, remove, or view a shared grocery list that multiple people contribute to. The list is organized by store (with address). Focus: what to buy and where, not meal planning.

## Architecture

Shared data lives in a user-configured local path accessible to all family members. See `memory-template.md` for file templates.

```
[shared-path]/
├── config.json    # Stores, primary store, fallback order, category→store map
├── users.md       # Family members and roles (admin/member)
├── list.md        # Current grocery list, grouped by store
└── history.md     # Log of all adds, removes, and merges
```

Skill reference files:

| Topic | File |
|-------|------|
| Data file templates | `memory-template.md` |
| List operations | `lists.md` |
| Store management | `stores.md` |
| User management | `user-management.md` |

## Startup Sequence

Run this every invocation, in order:

### Step 1 — Resolve user identity
1. Ask the agent for the name the user has set with it (read from OpenClaw memory key: `family_grocery_user`).
2. If no name is stored → deny: "No name found on this agent. Ask your admin to configure your agent with your name." Stop.

### Step 2 — Resolve shared path
1. Read shared path from OpenClaw memory (key: `family_grocery_path`).
2. If not found → this is a **first-time setup**. Go to **Admin Init Flow** below.

### Step 3 — Load config and verify access
1. Read `[shared-path]/config.json` and `[shared-path]/users.md`.
2. Look up the username (from Step 1) in `users.md`.
3. If not found → deny: "`[name]` is not on the family list. Ask your admin to add you."
4. If found → proceed. Note whether user is `admin` or `member`.

---

## Admin Init Flow

Only runs when no shared path is in OpenClaw memory.

1. Ask: "What shared path should I use for the family grocery data? (e.g. /Users/Shared/grocery)"
2. Create directory: `mkdir -p [path]`
3. Initialize files from `memory-template.md`: `config.json`, `users.md`, `list.md`, `history.md`
4. Write the current user to `users.md` as `admin`
5. Save path to OpenClaw memory as `family_grocery_path`
6. Confirm: "Setup complete. You are admin. Share the path `[path]` with other family members so they can connect their agents."

---

## Scope

This skill ONLY:
- Manages the shared grocery list (add, remove, view)
- Tracks stores and their addresses
- Assigns items to stores (by user input, category, or primary store default)
- Checks item availability and store addresses via web search (when available)
- Manages family member access
- Surfaces change history on request

This skill NEVER:
- Makes purchases or places orders
- Plans meals or suggests recipes
- Reads or writes files outside `[shared-path]`
- Accesses live store inventory systems
- Pushes notifications when the list changes

---

## Core Rules

### 1. Always reload config and users on every invocation
Never cache across sessions. Always re-read `config.json` and `users.md` at startup to pick up changes made by other family members.

### 2. Identity is resolved from OpenClaw memory
- Never ask the user for their name — always read it from the agent's OpenClaw memory. If absent, deny access.
- Never ask for the shared path if it's in memory.
- Save both on first encounter so they're never asked again.
- Name must match exactly (case-insensitive) what the admin registered in `users.md`.

### 3. Adding items — always resolve a store first
Resolution order: user input → category mapping → primary store.

See `lists.md` for full add flow including duplicate detection and web search.

### 4. Duplicate detection before every add
Before adding any item, fuzzy-match (case-insensitive, singular/plural) against `list.md`. If a match exists, tell the user who added it and when, then ask whether to merge quantities or add separately. Log merges in `history.md`.

### 5. Every write is attributed
Every entry in `list.md` and `history.md` must include the user name and ISO timestamp.

### 6. Web search is optional — always degrade gracefully
- If web search is available: use it to verify store addresses and item availability.
- If unavailable: proceed without it, note the limitation to the user once.
- Never block an action waiting for web search.

### 7. Store headings always include address
When displaying the list, format each store heading as:
`🏪 [Store Name] ([Full Address]) — [Store Hours]`

If store hours are missing, resolve them before displaying: web search → confirm with user → save to `config.json`. If search unavailable, ask user. If user skips, omit hours from heading. This ensures migration from older configs that lack store hours.

Always end the list with `Total items: [count]` across all stores including unassigned.

### 8. Admin-only actions
| Action | Who can do it |
|--------|--------------|
| Add a user | Admin only |
| Set primary store | Admin only |
| Set fallback order | Admin only |
| Update category→store map | Admin only |
| Add a new store | Any user |
| Add/remove list items | Any user |
| View list | Any user |
| View history | Any user |

If a member attempts an admin-only action: "Only the admin can do that."

---

## Common Traps

- Reading from a stale cached config → always reload `config.json` and `users.md` at startup
- Adding an item without resolving a store first → always confirm store before writing to `list.md`
- Showing a list dump without store grouping → always group by store with address heading
- Forgetting to attribute changes → every write must include user + timestamp
- Blocking on web search when unavailable → degrade gracefully, proceed without it
- Asking for user name or path every session → these must be in OpenClaw memory after first use