From Prompt Reuse to Personal Retrieval: Preference Memory Without Accounts

What changed

Prompt Hotbar started by reducing the friction of retyping repeated AI instructions. Search, Workflow Sets, reviewed Discovery, and a local MCP pilot gradually made retrieval more structured and available in more contexts.

The next friction was different: finding something once was not the same as being able to return to what mattered.

Version 0.6.0 therefore added a small preference layer. A card can stay neutral, be marked Like, or be marked Love this. Those positive choices feed My Picks, a browser-local view for returning to selected Prompt, Tool Box, and LAB items without creating an account.

국문 요약: Prompt Hotbar v0.6.0에서는 좋아요 / 최고예요와 My Picks를 추가해, 한 번 찾은 항목 중 다시 쓰고 싶은 것을 브라우저가 기억하도록 했습니다. 이 개인 선호 상태를 위해 계정이나 서버 DB를 추가하지 않았고, 제품 학습에 필요한 최소 행동 신호만 privacy-bounded PostHog 이벤트로 분리했습니다.

The product decision: positive memory, not social voting

The preference model is intentionally narrow:

• none — no explicit preference
• like — useful enough to want again
• love — especially useful or recommendable

The two positive states are mutually exclusive. Selecting the same state again returns the card to neutral; selecting the other state switches the preference.

There is no dislike state. A missing reaction is not treated as negative evidence, because a card may simply not have been seen, needed, or evaluated yet.

There are also no public reaction counts. At this stage, the purpose is personal retrieval rather than social proof or popularity ranking. Showing sparse public counts would add a herd signal before the underlying usage sample is strong enough to justify one.

The architecture decision: keep preference state local

The useful product behavior did not require a server profile.

Prompt Hotbar stores the preference map behind a versioned local preference abstraction in the browser. That gives the same browser profile persistence across reloads and restarts while keeping the feature independent from login, account recovery, or cloud synchronization.

This is a deliberate boundary rather than a missing backend implementation.

A server-side state layer becomes useful when the requirement changes to something that must leave the browser, such as:

• PC ↔ mobile synchronization
• recovery after local browser data is cleared
• account-level personalization across browsers
• server-side recommendation based on a durable user profile
• robust public aggregate counts or server-enforced one-user-one-vote behavior

Until one of those requirements is real, adding auth and a preference database would increase system and privacy complexity without increasing the immediate retrieval value.

My Picks turns preference into retrieval

A reaction button alone would be a weak feature. The useful part is what the state enables next.

My Picks is derived from the positive preferences and gives each main product surface a fast way to return to selected items. Local personal prompts participate in the browser-local experience too, but their local identifiers and content do not become analytics dimensions.

This keeps the product model coherent:

find an item
→ mark it useful
→ return through My Picks
→ copy, place, or use it again

Preference is therefore not a third bookmark database. It is the memory layer for retrieval.

The measurement boundary

Personal product state and aggregate product learning are separated.

The browser owns the preference itself. Production analytics receives a small allowlisted set of behavioral metadata instead of the stored preference map or personal prompt content.

For curated public-safe assets, card_preference_changed records the canonical asset type and ID plus the preference transition. Local personal-prompt IDs are rejected by the analytics sanitizer rather than being forwarded as identifiers.

my_picks_toggled records whether My Picks was opened or closed, which surface it happened on, and only a coarse pick-count bucket (0, 1, 2–3, 4–7, 8+) rather than an exact personal inventory.

Those signals can be read alongside existing actions such as prompt copy, Quick Slot assignment, Tool Box command copy, or LAB prompt copy. The useful product question becomes:

positive preference
→ My Picks reuse
→ downstream action

The current analytics setup intentionally does not maintain a persistent person identity across browser sessions, so it should not be used to make strong cross-day retention or one-user-one-vote claims.

What was deliberately not built

The milestone stayed bounded:

• no dislike
• no public reaction totals
• no account or authentication flow
• no Supabase preference database
• no cross-device synchronization
• no automatic ranking change based on raw reaction counts
• no server-side personal taste profile

This matters because raw preference totals are exposure-biased. A frequently displayed card has more opportunities to collect positive reactions than a rarely seen one. Immediate reranking would create a feedback loop before exposure, minimum sample size, and actual-use signals are modeled carefully enough.

What this can unlock next

If enough preference evidence accumulates, the local browser already has enough information for a first personalization experiment without a server or an AI call.

A future local recommender could combine curated metadata affinity, explicit Like/Love signals, and actual use such as copy or Quick Slot placement. Neutral items should remain neutral rather than being treated as disliked, and some exploration should remain so the system does not collapse into the user’s earliest choices.

If ranking ever becomes shared or public, stronger measurement would be needed: exposure-normalized rates, minimum samples, Like/Love weighting, downstream action conversion, smoothing, and exploration.

The product lesson

The milestone changed the product boundary without making the architecture much larger.

Prompt Hotbar’s evolution can now be read as:

prompt storage
→ structured retrieval
→ in-client retrieval
→ preference-aware retrieval

The local MCP pilot asked how the reviewed catalog could move closer to the AI client. The preference layer asks how the browser can remember what was useful without turning the product into an account system.

Both are examples of the same product rule: expand the retrieval layer when recurring use exposes a real friction, but add infrastructure only when the new user requirement actually depends on it.

---

Related: Prompt Hotbar project · A Prompt Library Is Not Enough · Local MCP pilot · Scope & Acceptance Criteria