scratch

name	scratch
description	Organize knowledge from an agent session into a scratchpad — a folder of files plus a scratchpad.json manifest. Use when a task generates notes, snippets, command output, diagrams, or artifacts worth keeping together for a session/activity.

scratch — session scratchpads

A scratchpad is a folder with a scratchpad.json manifest; the folder path is its identity (no central store). The CLI never authors, copies, or moves content — you write files with your normal tools, then register them for metadata + preview. Use it for session knowledge worth keeping together, not for the project's real source files.

scratch is on your PATH — run it directly. The skill's base dir is not where the CLI lives; don't look there for an entrypoint to invoke.

The loop

1. CREATE (default parent _scratchpads; create it if absent):
     scratch new "<name>" --dir _scratchpads [--id <session-id>]
   → creates <parent>/<slug>/ + scratchpad.json.

2. WRITE files into the pad dir with your normal tools (e.g. <slug>/notes.md).

3. REGISTER each file to track (group multi-doc pads with --group):
     scratch add "<name>" <file> --title "..." --desc "why it exists" \
       --type note --tag a,b --group "Findings"

4. INSPECT:  scratch ls           # pads under root
             scratch ls "<name>"  # files in a pad
             scratch show "<name>" <file>
             scratch comments "<name>"   # inline comments left in the viewer
             # add --json to `ls`/`show <file>`/`comments` for machine-readable output (agents)

5. BROWSE:   scratch ui "<name>"  # see viewer note — launch backgrounded

To extend an existing pad later, skip step 1 — ls to find it, write, add.

Scripting (--json)

ls and show <pad> <file> accept --json for parseable output (paths are relative, forward-slashed — never absolute, safe across shells/platforms):

• scratch ls --json → { root, pads: [{ name, rel, files }] }
• scratch ls "<name>" --json → { name, id, rel, files: [<entry>] }
• scratch show "<name>" <file> --json → { metadata, content } (metadata null if unregistered)
• scratch comments "<name>" [<file>] --json → { pad, comments: [...] } (see below)

Errors stay as text on stderr; stdout carries only the JSON, so pipe to jq freely.

Choosing a location (--dir)

Default to _scratchpads at the repo root unless the user names another parent (e.g. --dir _plans to co-locate with planning work). The same name under two parents = two distinct pads; an existing slug in one parent makes new refuse without --force.

Registering files (scratch add)

• --desc — why this file exists / what it captures. The most valuable field.
• --title — human label (defaults to path); --tag a,b,c — comma-separated.
• --type — note | snippet | output | artifact | reference (default note).
• --group — group header in the viewer; files sharing a name list together. Always set it once a pad holds more than ~3 files — it's the only structure the viewer shows. To set/change a group on existing entries, edit the group field in scratchpad.json in place — that's cheaper than re-running add per file and preserves the other metadata.

Write the file first, then add. Re-running add on the same path updates its metadata. add warns (doesn't fail) if the file is missing or outside the pad dir.

Group order (layout)

Groups list in first-appearance order by default. To control the order, add a top-level layout to scratchpad.json — an ordered list of groups (edit the file directly; there's no CLI flag):

"layout": { "groups": [{ "name": "plan" }, { "name": "research", "collapsed": true }, { "name": "" }] }

• Order follows the array. Names match the group field case-insensitively.
• Groups you omit sort after the listed ones (first-appearance order); the ungrouped bucket is { "name": "" } and sorts last unless you position it.
• "collapsed": true folds that group by default in the viewer.
• Applies to both the viewer sidebar and scratch ls. A layout entry with no matching files is skipped.

Addressing & roots

Pads resolve by name (within a scanned root) or by path. Root order: --dir <root> → $SCRATCH_DIR → current directory. ls/ui with no pad scan the root for all pads.

The viewer (scratch ui)

Read-only and blocking — keeps a local server alive until Ctrl+C. Always launch it backgrounded (don't await it) so the session keeps moving, then report the URL. Native glimpse window with automatic browser+server fallback (--browser forces it); shows all files in the pad (unregistered ones dimmed), renders markdown/code/mermaid, TeX math, embeds HTML diagrams (below), raw↔rendered toggle, auto light/dark.

Diagrams (mermaid)

A fenced ```mermaid block renders to an SVG in the viewer (flowcharts, sequence, state, ER, gantt, class). Reach for it when the shape of a system is the point and you'd rather describe the relationship than draw it — it's the default for architecture, data-flow, and state diagrams in a note, and reads far better than an ASCII sketch. The viewer themes the diagram for light/dark automatically, so don't hardcode colors.

```mermaid
graph TD
  A[Request] --> B{Cache hit?}
  B -->|yes| C[Return cached]
  B -->|no| D[Fetch + store]
```

When mermaid can't express it (bespoke layout, a chart, interactivity), embed an HTML diagram instead (below).

Math notation (TeX)

Markdown docs may use TeX/LaTeX math — inline $…$ and display $$…$$ — rendered by KaTeX in the viewer. Reach for it when a note needs a real formula instead of prose or ASCII (e.g. $$\text{tokens} = \operatorname{round}(W/28) \times \operatorname{round}(H/28) + 2$$). No setup needed; just write the math in the doc.

Footnotes / citations

Markdown footnotes are supported — an inline [^id] reference plus a [^id]: … definition (Pandoc/GFM style). The viewer numbers each reference and renders a linked definitions list at the bottom. Use it for sources/citations in research notes (definitions render inline markdown, so links inside them work).

Embedding HTML diagrams

For anything markdown + mermaid can't express — a UI sketch, a custom chart, an interactive explainer — write a standalone .html file in the pad and embed it from a markdown doc with image syntax:

![Cache layout](diagram.html)

The viewer renders diagram.html live in a sandboxed iframe right where the embed sits. The .html is just a loose file next to the doc — resolved by its relative path, not something you scratch add. Keep the markdown as prose; let the diagram be its own file. The embed is self-contained (baked into the page), so it survives scratch export and offline viewing.

Write the file as a complete standalone HTML document (it then also opens in a plain browser). Scripts run isolated — no access to the viewer page. Every embed gets a built-in kit baked in (theme-aware CSS variables, pre-styled controls, SVG utility classes + an #arrow marker) so diagrams stay consistent and match the viewer's light/dark theme without hand-rolled CSS.

Before authoring one, always read references/HTML_DESIGN_GUIDE.md for the kit reference and the styling/structure contract.

Reading viewer feedback (scratch comments)

Reviewers attach inline comments to rendered text in the viewer. scratch comments "<name>" reads them back (--file <path|glob|substring> to narrow files; --json for agents) so you can act without opening the UI: each item gives the note, the quoted text, and the enclosing markdown context block to edit. matched: false = the quoted text was edited away (orphaned); reconcile manually.

Cleanup

• scratch rm "<name>" <file> — unregister (file on disk is left untouched).
• scratch rm "<name>" --force — delete the whole pad directory.

Pads persist until removed — nothing is auto-deleted.