Add default `past-conversations` skill for recalling previous chats

[benjaminshafii]

Problem

OpenWork can’t reliably recall prior user conversations unless prompted with ad-hoc instructions. This hurts continuity and makes memory-dependent requests brittle.

Proposal

Add a built-in default skill named past-conversations that is strongly prioritized when the user asks to recall previous conversations. Triggering should be heavily biased toward recall-style prompts (e.g. “what did we discuss before?”, “find our earlier chat about X”).

Suggested skill content:

---
name: past-conversations
description: Find and inspect past conversations. Use when the user asks you to recall a previous conversation.
---

Discovery of past conversations

All past conversations exist in the sqlite database at ~/.local/share/opencode/opencode.db.

Use sqlite3 and query the part table:

CREATE TABLE `part` (
  `id` text PRIMARY KEY,
  `message_id` text NOT NULL,
  `session_id` text NOT NULL,
  `time_created` integer NOT NULL,
  `time_updated` integer NOT NULL,
  `data` text NOT NULL
);

Only search rows where data JSON has type = "text", and search within the text field. Sort by time_created, then group by session_id (conversation-level grouping).

Reference implementation notes: https://gist.github.com/jlongster/059741f0d2384eb9d41836dfffcb9cc7

Acceptance Criteria

• past-conversations exists as a first-class default skill.
• Skill trigger routing is biased toward recall/introspection prompts by default.
• Skill queries only text message parts (type: "text") from part.data.
• Results are ordered by time_created and grouped by session_id.
• Output makes it easy to inspect relevant conversation snippets and sessions.
• Add test coverage for trigger routing and query behavior.

[caoergou]

Hi, I've submitted PR #796 to implement this feature. During the implementation, I noticed a potential design consideration regarding the npm publishing strategy.

Current prepublishOnly Behavior

Looking at packages/server/package.json:

"prepublishOnly": "pnpm build:bin"

This means npm publish runs build:bin, which creates a single-file executable (~100MB) rather than JS files (~1MB). This results in:

1. Large package size - Platform-specific binary vs cross-platform JS
2. Single platform per publish - Binary only works on the build platform

Question

Is this intentional? For npm package distribution, would it make more sense to use:

"prepublishOnly": "pnpm build"  // publishes JS files + dist/builtin-skills/

And reserve build:bin for GitHub releases (multi-platform binaries)?

I'd be happy to adjust the PR if the maintainers prefer a different approach. The builtin-skills implementation I added works with both:

• build (tsc + copy script for npm)
• build:bin (embedded content for single-file executable)