/Harvest

metadata:
  short-description: "Mine content for LifeOS improvements and/or save it to Cortex. Use Cortex for existing notes."
name: Harvest
version: 1.3.3
evals:
  manual:
    reason: "Harvest quality depends on the supplied source and its correct routing into Cortex; a generic fixture cannot establish relevance."
    falsifier: "The saved record lacks source provenance, lands outside the requested route, omits a material insight from the supplied content, or duplicates an existing record without disclosure."
description: Mines one piece of content for LifeOS and/or ingests it into Cortex. USE WHEN harvest, harvest this, /harvest, /ha, mine this for the system, anything useful in this for us, what can LifeOS take from this, should we adopt anything from this, ingest to knowledge, save to knowledge, drop into knowledge, route to knowledge, add to the knowledge archive, archive this signal, capture this to knowledge, classify and route to knowledge. NOT FOR Cortex note ops, Upgrade / lu scans, Cortex recall, X PullBookmarks sweeps.

Harvest

**Contents:** Ideal State · Intent Routing · Tool contract · Data & Config · Gotchas · Examples

Two halves of one motion. **Mine:** read one piece of content and analyze it properly — what it is, where it is strong and weak — and, as one section of that report, what LifeOS should adopt from it (adoption report-only), with any further sections (such as the DA's own commentary) set by the install's preferences. **Ingest:** land the source in Cortex as a proper note — one CLI detects the source type, fetches the body or transcript, sends it through the Workflows classifier for TELOS-graded routing, then writes a schema-correct note with typed cross-links and a sidecar audit trail.

Saving signal by hand skips the cross-links, guesses the wrong folder and forgets the source URL, so capture is one command that routes through the same classifier and writer every time.

Ideal State

• Every harvested source lands in Cortex as one schema-correct note with its source URL, typed cross-links and an audit trail, written only by the canonical pipeline.
• A mined source's output carries analysis of the source ahead of its LifeOS adoption candidates, plus the sections the install's `PREFERENCES.md` asks for, and those candidates are recommended, never applied.
• Failures, duplicates and thin fetches are reported as what they are; nothing is filed as a stub or garbage body that only looks like a capture.

Intent Routing

| Intent | Trigger | File | |----------|---------|------| | **Mine** (general analysis + LifeOS-upgrade pass, then ingest) | `harvest <input>`, `/ha`, "mine this for the system", "anything useful in this for us" | `Intents/Mine.md` | | **HarvestUrl** (ingest an article, blog, LessWrong, Substack, news) | "ingest <URL>", "save this <URL> to knowledge" | `Intents/HarvestUrl.md` | | **HarvestYoutube** (ingest any youtu.be / youtube.com link) | "ingest <youtube URL>", "save this video to knowledge" | `Intents/HarvestYoutube.md` | | **HarvestText** (ingest raw paste, no URL) | "ingest the following:", "save this text to knowledge" | `Intents/HarvestText.md` |

The bare word "harvest" routes to **Mine** (mine → then ingest). "Ingest"/"save to knowledge" routes straight to the matching ingestion intent. If the input is ambiguous (URL is a YouTube link), `Tools/harvest.ts` auto-detects host and routes itself.

References

| File | Read when | |------|-----------| | `Setup.md` | first-time setup: build the harvest service, set the address and token, install the format tools |

Tool contract

• **One CLI does the work:** `bun ~/.claude/skills/Harvest/Tools/harvest.ts <input> [--type auto|article|youtube|x|text|pdf|image|audio] [--url <url>] [--dry-run] [--body-out <file>]` (the type list is `harvest.ts --help`'s; `--url` names the canonical source for a text signal; `--body-out` writes the fetched title and full body to a file before any POST, so a caller analyzes the same text the note is built from)
• **The harvest classifier worker** (cloud; built per `Setup.md` § 3. Build the service; URL in `Config.md` / `HARVEST_API_BASE` env) — accepts a normalized signal at `/ingest-and-classify`, persists it idempotently in its D1 database, and returns `{id, classification, confidence, reasoning, routed_actions}`.
• **`LIFEOS/TOOLS/HarvestExecutor.ts`** (local) — polls Workflows' `/items`, dispatches `routed_actions` through typed handlers (`create_knowledge_idea_entry`, `create_knowledge_source_entry`, `create_learning_queue_entry`), and writes the actual KNOWLEDGE note with `harvest_item_id` linkage.
• The skill never writes to `MEMORY/KNOWLEDGE/` directly. It always routes through Workflows then the executor.
• **Idempotency:** Workflows enforces `UNIQUE(source, external_id)` — re-harvesting the same URL returns `output.status: "duplicate"`. The executor sidecar at `MEMORY/STATE/harvest-executor-state.json` makes the local write idempotent too. On a `duplicate`, look up the existing item with the `source` and `external_id` the summary block printed: `curl -H "Authorization: Bearer $TOKEN" "$HARVEST_API/items?source=<source>&external_id=<id>"`. YouTube captures use `source=web` (the video id is the external id); articles, X posts, files and pasted text use `source=manual`.
• **Output:** `MEMORY/KNOWLEDGE/{Ideas,People,Companies,Research}/<slug>.md` with `source_url:`, `source_harvest_id:`, ≥2 typed `related:` entries, and 1-3 body `[[wikilinks]]`.

The summary block `harvest.ts` prints to stdout contains:

• `source` — `manual:lesswrong-<id>` or similar canonical external_id
• `workflows.id` — D1 row id (used to look up the harvest item later)
• `classification` — `knowledge` / `learning` / `blog_seed` / etc.
• `confidence` — Workflows' confidence score
• `routed_actions` — the action verbs Workflows decided
• `executor.paths_written` — actual file paths created in `MEMORY/KNOWLEDGE/`
• `executor.status` — `executed` / `backfilled` / `deferre