Prompt Stash · ⌘S

Copy Claude Code's "cmd+S to stash a prompt" into the T3 Code web composer: snapshot the in-progress prompt — text and image attachments — into a queue you can pull from later. Client-only, localStorage, scoped per connection method (provider instance).

What the user gets

Why this is easy here (repo findings)

The exploration confirmed every primitive already exists:

One thing "draft" can't mean: the composer already auto-persists a single live draft per thread (t3code:composer-drafts:v1). The stash is a separate, multi-slot, explicitly-saved queue layered on top — new store, new key, no changes to draft semantics.

Data flow

Design decisions

UI mocks

Four directions. A/B/C are retrieval surfaces; D is the save-moment micro-interaction and composes with any of them. Recommendation: D + A for v1 (delightful save, glanceable recall, zero new navigation), with B as a fast-follow since the command-menu plumbing already exists.

Mock A — The Shelf Recommended

A horizontal strip of stash cards that appears above the composer only when the current method's queue is non-empty. Cards show a 2-line snippet, image thumbnails, and age. Click (or ⌘S on empty composer, then arrows) to restore.

• Pro: zero-discovery recall — the queue is physically where your prompt went. Strong spatial metaphor.
• Con: costs vertical space when non-empty; needs a collapse affordance past ~4 items.

Mock B — Command-menu group Fast-follow

Stashed prompts appear as a group in the existing composer command menu (the $/@// picker), and ⌘S on an empty composer opens it pre-filtered. Keyboard-first, no new chrome.

• Pro: reuses ComposerCommandMenu + cmdk primitives wholesale; keyboard flow is ⌘S → arrows → ⏎, hands never leave home row.
• Con: invisible until invoked — users who forget they stashed something get no reminder.

Mock C — The Stash drawer If it grows into a library

A slide-out panel (right side, peer of the diff/preview panels) with full cards: bigger snippets, image thumbnails, provider scope tabs, drag-to-reorder. The heavyweight option.

• Pro: room for management (reorder, delete, cross-scope browsing); natural home if this evolves into a named-prompt library.
• Con: heaviest build; a whole panel for what's usually 1–3 parked prompts is overkill for v1.

Mock D — The save moment Composes with A or B

On ⌘S, a ghost of the prompt flies into a bookmark badge perched on the composer's shoulder; the count pops; a toast offers Undo. The badge is the persistent entry point when the shelf is collapsed. Press ⌘S (or click the composer below) to try it live.

• Pro: makes an invisible action legible — you see where the prompt went, and the badge doubles as the recall trigger.
• Note: repo rule — no continuous CSS animations (120 Hz perf). This is a one-shot, event-driven 550 ms animation, which complies; it must also respect prefers-reduced-motion.

Implementation plan

Sketch of the storage shape

// t3code:prompt-stash:v1 — Effect-Schema validated, versioned like every other store
const StashEntry = Schema.Struct({
  id: StashEntryId,
  createdAt: Schema.Number,
  prompt: Schema.String,
  images: Schema.Array(PersistedComposerImageAttachment), // { id, name, mimeType, sizeBytes, dataUrl }
  providerInstanceId: Schema.NullOr(ProviderInstanceId),
  modelSelection: Schema.optional(ModelSelection),
  droppedImageNames: Schema.Array(Schema.String), // images over the size cap — shown as placeholder chips
});

const PromptStashStorage = Schema.Struct({
  version: Schema.Literal(1),
  queues: Schema.Record({ key: Schema.String, value: Schema.Array(StashEntry) }), // ProviderInstanceId | "__none__"
});

Risks & open questions

Verdict: low-risk, well-contained feature. Everything hard (keybinding plumbing, schema-validated persistence, base64 image codec, provider identity, picker UI) already exists in the codebase; v1 is one new store, one command branch, and the Mock D + A surfaces.