/inventory

description: "Track wiki-adjacent things the user cares about: items, Ideas, ingest candidates, entities, corpora, open questions, tasks, and other durable inventory records."
argument-hint: "list [--kind <kind>] [--status <status>] [--priority p0-p4] [--view summary|actions|items|ideas|records|sources] [--limit N] [--format table|list] | add <kind> \"<title>\" [--priority p0-p4] [--source <path-or-url>] | show <slug-or-path> | update <path> | save-view \"<name>\" [filters] | scan-outputs [--dry-run] | migrate-output <output-path> [--kind <kind>] [--dry-run|--apply] [--include-archived] [--wiki <name>] [--local]"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash(ls:*), Bash(wc:*), Bash(date:*), Bash(mkdir:*)

Your task

**Resolve the wiki.** Do NOT broadly search the filesystem — follow these steps: 1. Read `$HOME/.config/llm-wiki/config.json`. If it has `hub_path`, expand leading `~` only (not tildes in `com~apple~CloudDocs`) and prefer that path; use `resolved_path` only as a fallback cache when the expanded `hub_path` is unavailable and `resolved_path` is initialized. If config has only `resolved_path`, use it. If the configured path can be statted but reading `wikis.json` or listing `topics/` fails with `Operation not permitted`, stop and ask the user to grant Full Disk Access/iCloud Drive access to the launcher; do not fall back to `~/wiki` or `resolved_path`. Do not write machine-specific `resolved_path` into shared configs. 2. If no config → read `$HOME/wiki/_index.md`. If it exists → HUB = `$HOME/wiki`. If nothing found, ask the user where to create the wiki. 3. **Wiki location** (first match): `--local` → `.wiki/` in CWD; `--wiki <name>` → `HUB/wikis.json` lookup with portable path resolution (`<HUB>`, `~`, absolute, or HUB-relative); if the registry path is stale, fall back to `HUB/topics/<name>`; CWD has `.wiki/` → use it; else → HUB. 4. Read `<wiki>/_index.md` to verify. If missing → stop with "No wiki found. Run `/wiki init` first."

Archive rule: inventory commands operate on active topic wikis by default. If a named target is archived, stop and ask the user to restore it or rerun with `--include-archived`. When explicitly included, list/update records only inside that archived topic path and label the result as archived. Do not let archived inventory records from archived topics appear in default cross-wiki summaries.

After resolving the wiki, read the inventory reference at `skills/wiki-manager/references/inventory.md`, then run the requested subcommand.

Inventory records are durable tracking objects, not compiled articles and not raw sources. Use them for physical or digital items, Ideas, ingest candidates, important entities, corpora to watch, open questions, recurring tasks, or "things we want to keep inventory of." They live under `inventory/` and can point at raw/wiki/output files without moving them. Route `kind: idea` through `/wiki:idea` so it receives research, shaping, and explicit Project-promotion behavior.

Be opinionated. Before writing or migrating records, tell the user whether inventory is the right layer:

• Good fit: durable state with priority/status/next action, a physical/digital

item to own/use/compare, a source/corpus to evaluate later, an entity/watch item, a deliverable-oriented Idea to shape, or a follow-up that should survive the chat session.

• Too small: one-off source to ingest now, a factual question, or a note with no

future action. Route to ingest, query, or raw notes instead.

• Too big: hundreds of row-like items, datasets, message archives, snapshots, or

collections. Create one corpus inventory record plus a dataset manifest or collection ingest, not one inventory record per row.

• Out of scope: authoritative source text (`raw/`), synthesized knowledge

(`wiki/`), generated deliverables (`output/`), project goals (`WHY.md`), or secrets/private operational data.

For bigger pivots, show a sample table of 1-3 proposed records and the recommendation before asking to apply. Default to dry-run for migrations and bulk conversions.

Parse $ARGUMENTS

Subcommands:

• **list**: List inventory records, optionally filtered by `--kind`, `--status`, or `--priority`.
• **add <kind> "<title>"**: Create a new inventory record in the canonical subdirectory for `kind`.
• **show <slug-or-path>**: Read one inventory record.
• **update <path>**: Edit one inventory record based on the user's instructions.
• **save-view "<name>" [filters]**: Save a derived table/list under `inventory/views/`.
• **scan-outputs [--dry-run]**: Look for output artifacts that look like inventory but still live in `output/`.
• **migrate-output <output-path> [--kind <kind>] [--dry-run|--apply]**: Convert one legacy output artifact into an inventory record. Default is **dry-run**. `--apply` is required to write a new inventory file.

Kinds: `item`, `idea`, `ingest-candidate`, `entity`, `corpus`, `question`, `task`, `artifact`, `watch`.

For `add idea`, follow the dedicated Idea capture workflow rather than the generic record template. Preserve the original seed and check for duplicates.

Statuses: `proposed`, `active`, `blocked`, `ingested`, `superseded`, `archived`.

Priorities: `p0`, `p1`, `p2`, `p3`, `p4`, where `p0` is highest.

Archive flag: `--include-archived` explicitly allows the selected wiki itself to be archived. This is separate from inventory record `status: archived`.

Ensure Structure

Inventory structure is lazy. Do not create it during read-only operations, and do not populate empty category folders until a command needs them.

Before a write:

1. Ensure `inventory/` exists with `_index.md`. 2. Ensure only the target subdirectory exists with `_index.md`:

• `add item` → `inventory/items/`
• `add idea` → `inventory/ideas/`
• `add entity` → `inventory/entities/`
• `add corpus` → `inventory/corpora/`
• `add ingest-candidate`, `add question`, `add task`, `add artifact`, or `add watch` → `inventory/candidates/`
• `sav