# 5 · Recipes — ways to harness Int

> Docs 1–4 give you the understanding, the space, the loop, and the wiring. This doc is what it looks
> like when a real system actually *lives* in the space. Every recipe here is a pattern running today
> in the system Int.ai is built inside (the **home system**, below) — captured on the same portals,
> fired through the same triggers, proven on a real phone. Each recipe says what it is, what it feels
> like, how it actually runs at home, and how to wire it; the last section shows how to package any
> of them as a **skill** in your system, so they become durable capabilities instead of one-off
> setups. Steal all of it.

None of these are features of Int.ai. That's the point — the app never changed between them. Each one
is the *same* space plus different wiring on your side: same app, completely different products. The
ceiling isn't the feature list; it's your system.

---

## 1 · The command surface — real work from your pocket

**What it is.** One action tag (call it `#go`) mapped to your main agent. A thought hits while your
human is out — a fix, an idea, a task, a question. They capture it, tag it, and put the phone away.
The watcher launches you; you do *actual work* — research, drafts, edits in real projects, updates to
the task system — and leave your answer beside their capture.

**What it feels like.** Texting your system. Not "saving a note to deal with later" — *dispatching.*
The distance between having a thought and the system acting on it collapses to one tag.

**Live, at home.** Two of these run daily: one tag launches a coordinating chief-of-staff agent that
files, routes, or answers; another launches the product's own dev agent. Real shipped work — bug
reports, feature asks, research questions — routinely starts life as one tagged capture on the phone.

**Wire it.** One trigger in the registry with `instructions` that say what "act on this" means, one
entry in the watcher's tag→directory map. All of it in [3 · The Loop](3-the-loop.md). Nothing else.

## 2 · Threads — conversations that live on the canvas

**What it is.** The thread pattern from [3 · The Loop](3-the-loop.md), lived in: every fired tag
opens a conversation. The reply carries a small `#s1` tag, and tagging *anything* with it — an edit,
a new node, a note next to a drawing — continues that exact conversation with full memory, days
later, from any portal. It works in reverse too: a conversation started at the desk, registered as a
thread, picked up from the phone.

**What it feels like.** Remote control for the sessions left running at home. The canvas stops being
an inbox and becomes a place where conversations *persist* — your human thinks in a thread the way
they'd talk in one.

**Live, at home.** Proven the day it shipped: a stray node tagged `#s2` resumed a working
conversation that had started at a desk days earlier — full memory, no re-explaining — and the
follow-up loop has carried real work since.

**Wire it.** Ships with the reference watcher — nothing extra to build.

## 3 · The capture sweep — an inbox that empties itself

**What it is.** Most captures shouldn't fire anything — they're fuel, not commands. The sweep is a
periodic pass (scheduled, or invoked with "process my captures") where you read every capture with
`status: "unprocessed"`, route each to its real home — a project file, a task list, a memory store, a
draft — and flip it to `"processed"`. Vocabulary tags refine the routing: `#idea` to the idea pile,
`#task` to the task system, untagged captures judged on content.

**What it feels like.** Nothing rots. Capture with zero ceremony all day, knowing everything lands
somewhere real. This is the recipe that keeps the space in sync instead of merely full — and it's
what the `status` field exists for.

**Live, at home.** The home system treats the vault as its primary capture inbox: an intake pass
reads every unprocessed capture, routes each to project files, task ledgers, or memory, marks it
processed — and posts a consolidated brief of what was routed back into the space as a note.

**Wire it.** No watcher needed — a scheduled or invoked run: read nodes across portals, filter on
`status`, route by tag and content, write the updates (the write rules in
[2 · The Vault](2-vault.md) apply to edits too — keep every required field). The routing map — what
"its real home" means — lives in your Layer-1 notes ([4 · Integration](4-integration.md)); that map
*is* your system.

## 4 · The live session — thinking side by side

**What it is.** Your human sits down with a portal open to think. You, invoked for the session, check
the portal on a short interval — and respond **only when something actually asks for a response**: a
question directed at you, a request for feedback, a node that says "expand this." Otherwise you stay
silent and let them think. Your contributions land as nodes beside theirs, in your color.

**What it feels like.** Someone at the whiteboard with you who knows when to speak. They sketch, you
wait; they ask, you answer in place. Visual thinking with the system in the room — the "together" of
the product made literal.

**Live, at home.** Runs as a named skill: invoked for side-by-side working sessions, it checks the
open portal on a short interval and answers only what asks for an answer, staying silent otherwise.

**Wire it.** A loop, not a watcher: read the open portal every ~30s, diff for new or changed nodes,
judge whether anything *needs* a response, write beside it if so. The judgment prompt is the whole
craft — "respond only to questions, requests, and explicit asks; otherwise stay silent." End when
they say so.

## 5 · Agent-authored boards — sit down to a prepared room

**What it is.** Because you write files, you can lay out an *entire portal* in one pass. Overnight
research fanned out as a cluster of source nodes around a summary. Months of scattered captures on
one theme, gathered and arranged for a thinking session. A board of drafts laid out side by side for
your human to react to on the go — tap, annotate, tag their pick.

**What it feels like.** Walking into a room someone prepared for the meeting. The canvas isn't just
where their thoughts land — it's where you *present*, spatially, in a form a phone screen and a
thinking session can actually use.

**Live, at home.** A launch board of twenty-six draft posts, laid out for reaction from the phone.
Consolidation passes that gather weeks of scattered captures into themed clusters. And the review
loop these very docs go through: feedback arrives as a portal of notes, and the dev agent reads the
board and acts on it.

**Wire it.** Bulk node writes plus edges — every schema is in [2 · The Vault](2-vault.md), including
the portal manifest for creating the board itself. The craft is layout: cluster related nodes instead
of dumping a grid, keep clusters a screen apart, use color as meaning, connect what relates.

## 6 · Reports where they'll find them — the return path

**What it is.** The system→human direction, running on a schedule. You write what they need to read —
a morning brief, research results, an end-of-day digest of what you did — as **notes in the vault**,
on their phone when they look, in markdown they can annotate right back. Pair it with a push
notification when something genuinely needs their eyes.

**What it feels like.** The system reports to *them*, where they actually are — not in a terminal
they have to visit. And their inline annotations are themselves capture: the loop closes.

**Live, at home.** Consolidated intake briefs and research results post into the space as notes
today — read on the phone, annotated inline, the annotations picked up on the next pass.

**Wire it.** Write `notes/<Title>.md` per the schema in [2 · The Vault](2-vault.md), on whatever
schedule your system runs. What reports cover and what earns a notification is Layer-1 configuration —
no new machinery at all.

---

## Package a recipe as a skill

Recipes start as wiring; the move that makes them durable is packaging each as a **skill** — a named,
on-demand instruction file in your system (a slash command, a SKILL.md, a playbook you load when
invoked). That's how a recipe survives across sessions: not as memory of "how we did it that one
time," but as a capability with a name.

A skill wrapping an Int.ai recipe needs four parts:

```markdown
# Skill: process-captures        ← the name you'll invoke it by

WHEN: On "process my captures", or on the daily schedule.

READ: The vault at <your resolved path>. Every node across portals/
      with status "unprocessed"; the tag taxonomy in <your Layer-1 notes>.

ACT:  Route each capture to its real home — <your routing map>.
      Flip each handled capture to status "processed".

RULES: Write-rules per int-ai/2-vault.md — complete nodes,
       uppercase-UUID ids, source "agent", explicit color.
```

Keep the mechanics as *pointers into these docs* rather than copies — the docs update; your pointer
stays true. Keep the personal parts (paths, taxonomy, routing, voice) in the skill itself — the
two-layer split from [4 · Integration](4-integration.md), applied per capability.

Build the shelf one skill at a time: the day a recipe proves itself, name it. A system that harnesses
Int well ends up with a visible row of these — `/process-captures`, `/live-session`, `/morning-brief` —
and that shelf *is* the growth: every new way you find to live in the space becomes a capability you
keep.

---

## The throughline, one last time

Int.ai stayed identical through all six recipes — same app, same files, same tags. A command surface,
a persistent conversation, a self-emptying inbox, a thinking partner, a presentation layer, a
reporting channel: all of it is *your* wiring on *one* shared space. These six are the ones we run;
they are nowhere near the ceiling. When you find the next one, it's a skill file away from being
permanent.