Prompt Hotbar

Overview

Prompt Hotbar is a keyboard-first workspace for retrieving reusable AI instructions and operational references at the moment they are needed.

It began with a very small frustration: I kept typing the same short instructions.

“Looks good, proceed.”
“Stay within scope.”
“Verify the work when you’re done.”

Longer instructions increasingly moved to voice input, while the keyboard was still carrying these short approval, scope-control, verification, and handoff messages. I wanted those instructions close at hand without turning them into another document I had to search.

That became Prompt Hotbar.

Repeated use widened the problem. Prompt retrieval was only one part of the friction. I was also repeatedly looking up the same AI-tool commands, shortcuts, permission modes, setup paths, and diagnostic references across coding agents. The product therefore grew from a Hotbar and Prompt Library into three connected surfaces: Library, Toolbox, and LAB.

국문 요약: 반복해서 쓰는 AI 업무 지시를 1–9번 퀵슬롯에 넣고 필요한 순간에 바로 찾아 복사하는 데서 출발한 키보드 중심 워크스페이스입니다. 현재는 72개의 내장 Prompt와 11개의 Preset / Workflow Set을 제공하는 Library, Claude Code·Codex·Antigravity·Hermes Agent·OpenCode의 검증된 운영 레퍼런스를 다루는 134-card Toolbox, 그리고 모델·프롬프트 capability를 실험하는 LAB까지 확장되었습니다. 개인 Prompt와 선호 상태는 browser-local을 유지하며, Toolbox의 명령·설정 역시 복사만 제공하고 제품이 직접 실행하지 않습니다.

• Live product: prompt-hotbar.vercel.app
• Reviewed Discovery: Prompt, Workflow, and LAB assets
• Preference layer case-note: Preference memory without accounts
• Evidence-first Guide: Inspect, verify, and audit before asking AI to change anything
• Local MCP pilot: Testing Prompt Hotbar inside Claude Code
• Source status: private development repository
• Published LinkedIn post: From repeated instructions to Prompt Hotbar

What it does

The product still keeps retrieval separate from execution.

In Library, the core interaction remains deliberately simple:

1. Find a Prompt or choose a reusable Set.
2. Place it into one of nine Hotbar slots when it deserves a shortcut.
3. Click the slot or press its number key.
4. Paste the copied instruction into the AI conversation already in progress.

In Toolbox, the same retrieval principle applies to operational knowledge:

1. Filter or search by AI tool, purpose, or reference type.
2. Inspect a reviewed command, shortcut, Skill, or configuration reference.
3. Copy the exact reference when appropriate.
4. Run it yourself in the intended tool or environment after reviewing its source and risk context.

Prompt Hotbar does not perform the task for the user. It does not automatically send Prompts to an AI service, execute shell commands, run installers, or mutate tool configuration. The AI conversation or external tool keeps its own context and remains responsible for actual execution.

The workflow shown in the launch demo

The published demo connects Prompt Hotbar to an actual planning context rather than showing copy behavior in isolation.

• A feature is planned with ChatGPT.
• A reusable verification Prompt is found in Prompt Hotbar.
• The Prompt is placed into slot 4 and copied with the number key.
• It is sent back into the same conversation.
• The existing implementation plan is converted into a concrete verification checklist.

This remains a useful expression of the product boundary: Prompt Hotbar sits between planning and execution as a retrieval layer, while the AI conversation keeps its own context and performs the reasoning.

The LinkedIn-native demo is embedded on this page. The original LinkedIn post remains the canonical source for its bilingual launch copy, reactions, comments, and publication context. If LinkedIn does not allow the player to load in a particular browser, the original-post link remains available directly below it.

Current product experience

What started as nine shortcuts now includes three main product surfaces.

Library

• Nine configurable Hotbar slots with click and number-key copy
• 72 built-in public-safe Prompts for approval, verification, scope control, handoff, reporting, safety, writing, release, design, and other recurring AI work
• 11 built-in Preset / Workflow Sets for switching between recurring work modes
• Browser-local personal Prompts with CRUD and Hotbar placement
• Board / List browsing, search, category and workflow grouping, sorting, and display controls
• Browser-local positive preferences and My Picks for returning to useful Prompt, Toolbox, LAB, and local My Prompt cards without an account
• Already-equipped Quickslot controls with a light accent state so assigned shortcuts are easier to recognize
• Korean and English UI with a separate AI response-language preference
• Safe sharing based on stable public IDs and slot numbers rather than Prompt bodies
• Versioned local JSON backup / restore for My Prompts and Local Sets

Toolbox

The reviewed Production snapshot contains 134 unique cards. Product contribution counts overlap where a shared reference or multi-agent Skill applies to more than one tool.

• Claude Code: 46 Product contributions
• Codex: 41
• Antigravity: 26
• Hermes Agent: 54
• OpenCode: 1
• 49 Slash Commands
• 20 Keyboard Shortcuts
• 26 Agent Skills
• 3 Configuration references
• 36 CLI Commands

The Toolbox is not intended to be another bookmark list. Its working model is executable knowledge + provenance: a useful command or configuration recipe should be directly copyable, but the user should also be able to see where it came from, when it was reviewed, and whether its behavior carries additional risk.

That led to several curation and interaction decisions:

• Repeated-use operational references such as Update, Doctor / Status / Help, and reviewed permission/autonomy modes remain normal Toolbox cards where the provider actually supports them.
• Low-frequency Install / Setup does not occupy the normal card grid. It lives in each Provider utility menu and appears through explicit install/setup search.
• Provider utilities also link to the official site, documentation, and release notes. Desktop right-click and mobile long-press expose the same secondary menu as a shortcut, not as the only discoverable path.
• Permission/autonomy references distinguish scoped, auto-reviewed, auto-edit, and full-bypass behavior instead of flattening them into one generic “automatic” mode.
• OpenCode V2 is represented through its reviewed permission-rule configuration instead of inventing a YOLO command that the official reference does not support.
• Commands that look symmetrical across providers are not added merely for visual completeness. If an official equivalent cannot be verified, it is omitted.
• Installer and permission commands are references only. Prompt Hotbar does not execute them.

This is also why Toolbox source metadata matters. The useful asset is not just a string such as a CLI flag; it is the string plus enough provenance and risk context to decide whether it belongs in real work.

LAB and Discovery

LAB currently contains six reviewed capability challenges. It copies Prompt material for experiments but does not execute a Prompt Hotbar model backend.

Discovery publishes a deliberately small reviewed proof set rather than generating public pages for every built-in asset. Prompt Hotbar owns the canonical Prompt, Workflow, and LAB pages and their copy/open actions; this site keeps the project story, methodology, and proof-of-work context without duplicating their full bodies.

Preference memory and My Picks

Repeated use exposed another retrieval problem. Finding an item once did not make it easier to return to the items that mattered most.

Version 0.6.0 introduced a deliberately small positive-preference model: neutral, Like, or Love this. The states are mutually exclusive, and choosing the selected state again returns the card to neutral. There is no dislike state because no reaction is not reliable negative evidence; an item may simply not have been seen or needed yet.

The preference map stays in the browser behind a versioned local abstraction. My Picks is derived from those positive states and turns preference into a useful retrieval surface rather than a decorative reaction control. No account, Supabase database, or cloud profile is required for the same browser to remember the state.

That local boundary is intentional. A backend becomes justified when the requirement itself leaves the browser — for example PC↔mobile synchronization, recovery after local data is cleared, account-level personalization, or server-enforced public aggregation.

Product learning is separated from personal state. Production PostHog receives only allowlisted behavioral metadata for curated assets, such as a canonical preference transition and My Picks activation. Personal Prompt bodies and local prompt identifiers are not analytics dimensions. The analytics setup also avoids persistent person identity, so aggregate behavioral signals should not be interpreted as durable cross-day user profiles.

See From Prompt Reuse to Personal Retrieval for the product and architecture reasoning behind this milestone.

Local MCP pilot

A private local pilot tested whether Prompt Hotbar could provide the same reviewed retrieval layer directly inside an AI coding client.

Claude Code connected to a local stdio MCP server and exposed five read-only tools for Prompt search, Prompt retrieval, contextual recommendation, Workflow search, and Workflow retrieval. The runtime used a generated public-safe snapshot containing 23 reviewed Prompts and three Workflows.

The pilot successfully handled natural-language requests to:

• recommend a Prompt for resuming interrupted work
• suggest verification-stage Prompts and explain why they fit
• retrieve the nine-step coding-agent Workflow
• return the canonical body of a requested Prompt

The MCP did not read browser-local personal Prompts, clipboard data, Hotbar assignments, search history, accounts, or cloud state. It introduced no write tool and did not execute the retrieved Prompt.

This creates a complementary product boundary:

• Web product: visual discovery, organization, browser-local personalization, Prompt shortcuts, Toolbox references, and copy
• Local MCP pilot: read-only search, recommendation, and retrieval inside a compatible AI client
• AI client / external tool: task context, reasoning, and any actual execution

The package is prepared as a standalone artifact, but public npm publication remains intentionally withheld while personal-use value is evaluated. See the local MCP pilot proof note for the exact evidence and limitations.

Reviewed Discovery proof set

The Discovery Foundation publishes a small reviewed proof set rather than generating public pages for every built-in asset.

Prompts

• Inspect the current state before acting
• Keep the work within the minimum required scope
• Run a public/private safety check

Workflows

• Safe implementation workflow for a coding agent
• Business-model design and red-team workflow

Guide

• Before Asking AI to Change Anything: An Evidence-first Inspect, Verify, and Audit Workflow

LAB

• Pelican on a Bicycle — SVG capability check

The Toolbox itself remains a product surface rather than a duplicated PAOS catalog. Its individual commands, shortcuts, Skills, and configuration references stay canonical in Prompt Hotbar.

Privacy and product boundary

Personal Prompt content, clipboard contents, search text, Hotbar assignments, local settings, and the stored preference map stay on the device.

Shared links do not contain Prompt bodies or personal configuration. Production measurement is limited to a small allowlisted set of non-personal events; automatic pageviews, session recording, autocapture, and persistent person profiles are disabled. For curated assets, preference analytics uses canonical public IDs and bounded transition metadata; local personal-prompt identifiers and bodies are rejected from that transport. Public detail-page view labels use cached, nonlinear aggregate buckets rather than raw counts or unique-person claims.

The Toolbox adds another explicit boundary: copied commands, installers, configuration recipes, permission flags, and Agent Skill references are information products. Prompt Hotbar does not execute them, collect credentials for them, or silently change the external environment.

The public web product intentionally does not include:

• Automatic Prompt or command execution
• Accounts or cloud synchronization
• A server-side Prompt or preference database
• Browser-wide global shortcuts
• Public reaction counts or social ranking
• In-product payments, teams, or a Prompt marketplace

The local MCP pilot does not change those boundaries. It reads only the reviewed public-safe snapshot and does not access browser-local personal state.

Prompt Hotbar does not process payments inside the product. Future support links, if activated, remain an external Support Layer and do not change access to the Core Utility.

What changed through use

The first version treated the problem as Prompt storage. Using it repeatedly showed that retrieval was the harder part.

That changed the product direction. Similar Prompts needed to be grouped. The Library needed search. Sets needed to support different modes of work. New users needed to understand the placement and copy model quickly. Reviewed public asset pages became useful so that selected Prompt, Workflow, and LAB artifacts could be understood before opening the product.

The local MCP pilot extended retrieval outward: when the user is already inside an AI client, natural-language search or recommendation can be more useful than another browser round trip. The Preference Layer extended retrieval inward: when the user stays in the browser, the product can remember which items were explicitly useful without turning that memory into an account system.

Toolbox extended the same retrieval idea sideways across the operating environment. The repeated thing was no longer always a sentence to send to an AI. Sometimes it was a command, a permission mode, a diagnostic action, or a Skill that needed to be found again with enough evidence to trust it.

The product evolution is therefore less about accumulating features than about making retrieval more situated:

prompt storage
→ structured retrieval
→ in-client retrieval
→ preference-aware retrieval
→ cross-tool operational retrieval

The useful lesson was not that every repeated sentence or command should become a product feature. It was that a small, persistent friction can reveal a clearer product boundary once it is observed in real work, shipped narrowly, reviewed against evidence, and expanded only when the requirement justifies the added complexity.

---

Related reading: A Prompt Library Is Not Enough · Preference memory without accounts · Evidence-first AI Workflow · Local MCP pilot · From personal prompts to team capability

개요

Prompt Hotbar는 반복해서 쓰는 AI 지시와 운영 레퍼런스를 필요한 순간에 바로 찾아 쓰기 위한 키보드 중심 워크스페이스입니다.

처음 계기는 아주 단순했습니다. 같은 짧은 문장을 계속 다시 입력하고 있었습니다.

“좋아요. 이대로 진행하세요."
"범위를 벗어나지 마세요."
"작업이 끝나면 검증하세요.”

긴 지시는 점점 음성 입력으로 넘기게 됐지만, 승인이나 범위 통제, 검증, 인계처럼 짧고 자주 쓰는 문장은 계속 키보드로 입력하고 있었습니다. 문서 하나를 더 만들어 찾아다니지 않고, 이런 문장을 손 닿는 곳에 두고 싶었습니다.

그렇게 Prompt Hotbar를 만들었습니다.

계속 쓰다 보니 문제가 Prompt에만 있지 않다는 것도 보였습니다. Claude Code, Codex, Antigravity, Hermes Agent 같은 도구를 쓰면서 같은 명령어와 단축키, permission mode, setup 경로, 진단 명령을 반복해서 다시 찾고 있었습니다. 그래서 제품은 Hotbar와 Prompt Library에서 Library, Toolbox, LAB 세 영역으로 넓어졌습니다.

무엇을 하는 도구인가

제품의 기본 원칙은 지금도 같습니다. 찾아주는 것과 실행하는 것을 분리합니다.

Library에서는 다음 흐름으로 씁니다.

1. 필요한 Prompt를 찾거나 반복해서 쓰는 Set을 고릅니다.
2. 자주 쓸 가치가 있다면 1~9번 Hotbar 슬롯에 배치합니다.
3. 슬롯을 클릭하거나 숫자키를 눌러 복사합니다.
4. 이미 작업 중인 AI 대화에 붙여 넣습니다.

Toolbox에서도 같은 원칙을 운영 지식에 적용합니다.

1. AI 도구, 목적, 레퍼런스 유형으로 필터하거나 검색합니다.
2. 검토된 명령어, 단축키, Skill, configuration을 확인합니다.
3. 필요한 레퍼런스를 그대로 복사합니다.
4. 출처와 위험도를 확인한 뒤 실제 도구나 환경에서 직접 실행합니다.

Prompt Hotbar 자체가 업무를 수행하지는 않습니다. Prompt를 AI에 자동 전송하지 않고, shell command나 installer를 실행하지 않으며, 외부 도구의 설정도 자동으로 바꾸지 않습니다. 실제 실행과 판단은 사용 중인 AI 대화나 외부 도구가 담당합니다.

런치 데모에서 보여준 흐름

공개한 런치 데모는 단순히 “복사 버튼이 동작한다”는 장면보다 실제 작업 맥락을 보여주는 데 초점을 맞췄습니다.

• ChatGPT에서 기능을 기획합니다.
• Prompt Hotbar에서 검증용 Prompt를 찾습니다.
• 해당 Prompt를 4번 퀵슬롯에 넣고 숫자키로 복사합니다.
• 같은 대화로 돌아가 Prompt를 붙여 넣습니다.
• 기존 구현 계획을 구체적인 검증 체크리스트로 바꿉니다.

지금도 이 흐름이 Prompt Hotbar의 경계를 잘 설명합니다. Prompt Hotbar는 기획과 실행 사이에서 필요한 지시를 꺼내 주고, 실제 맥락과 추론은 AI 대화가 계속 가지고 갑니다.

이 페이지에는 LinkedIn에 공개한 원본 데모를 그대로 임베드했습니다. 브라우저 정책 때문에 플레이어가 열리지 않는 경우에는 아래 원문 링크에서 게시물과 댓글을 확인할 수 있습니다.

현재 제품 구성

처음에는 9개의 퀵슬롯이 전부였지만, 지금은 세 가지 주요 영역으로 나뉩니다.

Library

• 클릭과 숫자키 복사를 지원하는 9개의 Hotbar 슬롯
• 승인, 검증, 범위 통제, 인계, 보고, 안전, 글쓰기, 릴리즈, 디자인 등 반복 작업에 쓰는 내장 공개-safe Prompt 72개
• 반복 작업 모드를 한 번에 바꾸기 위한 Preset / Workflow Set 11개
• 개인 Prompt를 추가, 수정, 삭제하고 Hotbar에 배치하는 browser-local 기능
• Board / List 보기, 검색, category와 workflow grouping, 정렬, 표시 옵션
• 계정 없이도 유용했던 Prompt, Toolbox, LAB, My Prompt를 다시 찾게 해주는 browser-local Like / Love this / My Picks
• 이미 퀵슬롯에 배치된 항목을 쉽게 알아볼 수 있는 연한 accent 상태 표시
• 한국어와 영어 UI, 별도로 지정할 수 있는 AI 응답 언어
• Prompt 본문 대신 안정적인 public ID와 slot 번호를 쓰는 안전한 공유 방식
• My Prompt와 Local Set을 위한 버전 관리형 local JSON backup / restore

Toolbox

검토된 현재 Production 기준으로 unique card 134개가 있습니다. 하나의 공통 Skill이나 레퍼런스가 여러 도구에 걸쳐 쓰일 수 있기 때문에 제품별 기여 수의 합은 unique card 수와 다릅니다.

• Claude Code: 46
• Codex: 41
• Antigravity: 26
• Hermes Agent: 54
• OpenCode: 1
• Slash Commands 49개
• Keyboard Shortcuts 20개
• Agent Skills 26개
• Configuration 3개
• CLI Commands 36개

Toolbox를 공식 문서 링크 모음으로 만들고 싶지는 않았습니다. 실제로 다시 찾게 되는 것은 “문서가 어디 있지?”보다 “그 명령어가 정확히 뭐였지?”인 경우가 많았습니다. 그래서 현재 기준은 executable knowledge + provenance입니다. 명령어나 configuration은 바로 복사할 수 있어야 하지만, 동시에 공식 출처와 마지막 검토 시점, 위험도도 확인할 수 있어야 합니다.

이 기준에서 몇 가지 제품 원칙이 정해졌습니다.

• Update, Doctor / Status / Help, permission/autonomy처럼 반복해서 다시 쓰는 항목은 해당 Provider가 실제로 지원할 때 일반 Toolbox 카드로 둡니다.
• 한 번 설치하면 자주 볼 일이 없는 Install / Setup은 카드 그리드를 차지하지 않습니다. Provider 메뉴와 명시적인 install/setup 검색에서만 접근합니다.
• Provider 메뉴에서는 공식 사이트, 문서, Release Notes, Install / Setup으로 이동할 수 있습니다. PC의 우클릭과 모바일의 길게 누르기는 같은 메뉴를 여는 보조 경로입니다.
• permission/autonomy는 전부 “자동”이라는 한 단어로 묶지 않고 scoped, auto-reviewed, auto-edit, full-bypass처럼 실제 위험 수준을 나눠 보여줍니다.
• OpenCode V2는 공식 문서에서 확인되는 permission-rule configuration으로 표현합니다. 확인되지 않은 YOLO 명령을 다른 도구와 모양을 맞추기 위해 만들어 넣지 않습니다.
• Provider 간에 비슷해 보이는 명령이라도 공식 근거를 확인할 수 없으면 넣지 않습니다.
• Installer나 permission command도 어디까지나 레퍼런스입니다. Prompt Hotbar가 직접 실행하지 않습니다.

결국 가치가 있는 것은 CLI 문자열 하나가 아닙니다. 그 문자열을 실제 업무에 써도 되는지 판단할 수 있을 만큼의 출처와 위험 맥락이 함께 있어야 합니다.

LAB과 Discovery

LAB에는 현재 6개의 capability challenge가 있습니다. 실험용 Prompt를 복사해 쓸 수 있지만 Prompt Hotbar 자체에서 모델을 실행하지는 않습니다.

Discovery는 모든 내장 asset을 페이지로 공개하지 않고, 검토할 가치가 있는 일부 Prompt, Workflow, LAB만 골라 공개합니다. 개별 asset의 canonical page와 copy/open 동작은 Prompt Hotbar가 소유하고, PAOS에는 프로젝트의 맥락과 방법론, proof-of-work만 남깁니다.

Preference memory와 My Picks

제품을 계속 쓰면서 또 다른 retrieval 문제가 보였습니다. 한 번 찾은 항목이 실제로 유용했더라도 다음에 더 빨리 찾을 방법은 없었습니다.

v0.6.0에서는 이 문제를 아주 작은 positive preference 모델로 풀었습니다. 상태는 neutral, Like, Love this 세 가지입니다. Like와 Love this는 동시에 선택되지 않고, 이미 선택된 상태를 다시 누르면 neutral로 돌아갑니다. dislike는 넣지 않았습니다. 사용하지 않았다는 사실이 곧 싫다는 뜻은 아니기 때문입니다.

선호 상태는 versioned local abstraction 뒤에서 browser-local로 저장합니다. My Picks는 이 positive state를 모아 다시 찾을 수 있게 만드는 실제 retrieval surface입니다. 같은 브라우저라면 계정, Supabase, cloud profile 없이도 상태를 기억합니다.

이 경계는 의도적으로 정했습니다. PC와 모바일 간 동기화, 로컬 데이터 삭제 후 복원, 계정 단위 personalization처럼 요구사항 자체가 브라우저 밖으로 나가는 순간에 backend를 검토하면 됩니다.

제품 학습과 개인 상태도 분리합니다. Production PostHog에는 curated asset의 preference 전환이나 My Picks 활성화처럼 allowlist에 포함된 행동 메타데이터만 보냅니다. 개인 Prompt 본문과 local Prompt ID는 analytics dimension으로 보내지 않습니다. persistent person identity도 쓰지 않기 때문에 집계 데이터는 장기간 동일 사용자를 추적하는 profile처럼 해석하지 않습니다.

이 결정의 배경은 From Prompt Reuse to Personal Retrieval에 별도로 정리했습니다.

Local MCP 파일럿

브라우저를 다시 열지 않고 AI coding client 안에서 같은 retrieval layer를 쓸 수 있는지도 개인 파일럿으로 확인했습니다.

Claude Code에서 local stdio MCP server를 연결하고 Prompt 검색, Prompt 조회, 맥락 기반 추천, Workflow 검색, Workflow 조회를 위한 read-only tool 5개를 노출했습니다. runtime에는 검토된 공개-safe snapshot만 넣었고, 당시 기준으로 Prompt 23개와 Workflow 3개가 포함됐습니다.

실제로 다음 요청을 처리할 수 있었습니다.

• 중단된 작업을 다시 시작할 때 적합한 Prompt 추천
• 검증 단계에 맞는 Prompt 추천과 이유 설명
• 9단계 coding-agent Workflow 조회
• 특정 Prompt의 canonical body 반환

MCP는 browser-local My Prompt, clipboard, Hotbar 배치, 검색 기록, 계정, cloud state를 읽지 않았습니다. write tool도 없었고, 가져온 Prompt를 대신 실행하지도 않았습니다.

그래서 현재 제품 경계는 다음처럼 나눌 수 있습니다.

• Web product: 시각적 탐색, 정리, browser-local personalization, Prompt shortcut, Toolbox reference, copy
• Local MCP pilot: 호환되는 AI client 안에서 read-only 검색, 추천, 조회
• AI client / external tool: 실제 작업 맥락, 추론, 실행

package는 standalone artifact로 준비돼 있지만, 개인 사용 단계에서 가치가 충분히 검증되기 전까지 공개 npm 배포는 보류하고 있습니다. 자세한 검증 범위와 한계는 local MCP pilot proof note에 정리했습니다.

검토된 Discovery proof set

Discovery Foundation은 모든 내장 asset을 자동으로 공개하지 않고, 작은 검토 세트만 운영합니다.

Prompts

• Inspect the current state before acting
• Keep the work within the minimum required scope
• Run a public/private safety check

Workflows

• Safe implementation workflow for a coding agent
• Business-model design and red-team workflow

Guide

• Before Asking AI to Change Anything: An Evidence-first Inspect, Verify, and Audit Workflow

LAB

• Pelican on a Bicycle: SVG capability check

Toolbox도 마찬가지입니다. 개별 command, shortcut, Skill, configuration은 Prompt Hotbar가 canonical owner이고 PAOS에 다시 복제하지 않습니다.

Privacy와 제품 경계

개인 Prompt 본문, clipboard 내용, 검색어, Hotbar 배치, local setting, preference map은 기기에 남습니다.

공유 링크에는 Prompt 본문이나 개인 설정을 넣지 않습니다. Production analytics는 소수의 non-personal event allowlist로 제한하고, automatic pageview, session recording, autocapture, persistent person profile은 끕니다. curated asset의 preference analytics도 canonical public ID와 제한된 transition metadata만 사용하며, local personal Prompt ID와 본문은 transport 단계에서 거부합니다. 공개 상세페이지의 view label은 raw count나 unique-person claim 대신 캐시된 비선형 bucket을 씁니다.

Toolbox가 생기면서 경계가 하나 더 명확해졌습니다. 복사 가능한 command, installer, configuration recipe, permission flag, Agent Skill은 정보 제품입니다. Prompt Hotbar가 이를 대신 실행하거나 credential을 수집하거나 외부 환경을 조용히 바꾸지 않습니다.

현재 공개 Web product에는 다음 기능을 넣지 않습니다.

• Prompt 또는 command 자동 실행
• 계정이나 cloud synchronization
• server-side Prompt / preference database
• browser-wide global shortcut
• 공개 reaction count나 social ranking
• in-product payment, team 기능, Prompt marketplace

Local MCP 파일럿도 이 경계를 바꾸지 않습니다. 검토된 공개-safe snapshot만 읽고 browser-local 개인 상태에는 접근하지 않습니다.

Prompt Hotbar 안에서 결제를 처리하지도 않습니다. 향후 Support 링크를 활성화하더라도 Core Utility 접근 권한과 분리된 외부 Support Layer로 유지합니다.

실제 사용을 통해 바뀐 것

첫 버전에서는 문제를 Prompt 저장으로 봤습니다. 직접 계속 써보니 더 큰 문제는 저장보다 retrieval이었습니다.

비슷한 Prompt끼리 묶을 필요가 있었고, Library에는 검색이 필요했습니다. Set은 작업 모드를 바꾸는 데 도움이 돼야 했고, 처음 쓰는 사람은 placement와 copy 방식부터 이해해야 했습니다. 검토된 일부 Prompt, Workflow, LAB은 제품을 열기 전에 내용을 이해할 수 있는 공개 페이지도 필요했습니다.

Local MCP 파일럿은 retrieval을 바깥으로 넓혔습니다. 이미 AI client 안에서 작업 중이라면 브라우저를 다시 여는 것보다 자연어로 검색하고 추천받는 편이 더 나을 수 있었습니다. Preference Layer는 반대 방향으로 안쪽을 넓혔습니다. 브라우저 안에서는 계정을 만들지 않고도 “이건 다시 쓰겠다”고 표시한 항목을 기억할 수 있게 했습니다.

Toolbox는 같은 원리를 작업 환경 전체로 넓혔습니다. 반복해서 다시 찾는 것이 항상 AI에 보낼 문장인 것은 아니었습니다. command, permission mode, diagnostic action, Skill도 충분한 근거와 함께 다시 꺼내 쓸 필요가 있었습니다.

그래서 지금까지의 변화는 기능 수를 늘린 역사라기보다 retrieval이 점점 실제 작업 맥락에 맞춰진 과정에 가깝습니다.

prompt storage
→ structured retrieval
→ in-client retrieval
→ preference-aware retrieval
→ cross-tool operational retrieval

작은 반복 불편을 무조건 기능으로 바꾼 것은 아닙니다. 실제로 계속 쓰면서 불편이 반복되는지 보고, 필요한 만큼만 좁게 만들고, 확인 가능한 근거를 붙인 다음, 요구사항이 커질 때만 구조를 확장했습니다.

---

관련 글: A Prompt Library Is Not Enough · Preference memory without accounts · Evidence-first AI Workflow · Local MCP pilot · From personal prompts to team capability

概要

Prompt Hotbarは、繰り返し使うAIへの指示や運用リファレンスを、必要なときにすぐ取り出すためのキーボード中心のワークスペースです。

きっかけは単純でした。同じ短い指示を何度も打ち直していたからです。

“Looks good, proceed."
"Stay within scope."
"Verify the work when you’re done.”

長い指示は音声入力に任せることが増えましたが、承認、スコープの確認、検証、引き継ぎのような短い指示は、相変わらずキーボードで何度も入力していました。もう一つ文書を作って探し回るのではなく、よく使う指示を手元に置きたいと思ったのが始まりです。

そこでPrompt Hotbarを作りました。

使い続けるうちに、繰り返し探しているものはPromptだけではないと気づきました。Claude Code、Codex、Antigravity、Hermes Agentなどを使う中で、同じコマンド、ショートカット、permission mode、setup手順、診断用コマンドを何度も調べ直していました。そこで製品はHotbarとPrompt Libraryから、Library、Toolbox、LABの3つの領域へ広がりました。

何をするツールか

今も基本方針は変わっていません。探すことと実行することを分けています。

Libraryでは、次の流れで使います。

1. 必要なPromptを探すか、繰り返し使うSetを選びます。
2. 頻繁に使うものなら1〜9番のHotbarスロットに置きます。
3. スロットをクリックするか数字キーを押してコピーします。
4. すでに作業中のAI会話に貼り付けます。

Toolboxでは、同じ考え方を運用知識に使います。

1. AIツール、目的、リファレンス種別で絞り込みます。
2. レビュー済みのコマンド、ショートカット、Skill、configurationを確認します。
3. 必要なリファレンスをそのままコピーします。
4. 出典とリスクを確認したうえで、実際のツールや環境で自分で実行します。

Prompt Hotbar自身が作業を実行するわけではありません。PromptをAIへ自動送信せず、shell commandやinstallerを実行せず、外部ツールの設定も勝手に変更しません。実際の実行と判断は、作業中のAI会話や外部ツール側に残します。

ローンチデモで見せた流れ

公開したローンチデモでは、単にコピー機能が動く様子ではなく、実際の作業の流れを見せました。

• ChatGPTで機能を企画します。
• Prompt Hotbarで検証用Promptを探します。
• そのPromptを4番スロットに置き、数字キーでコピーします。
• 同じ会話に戻って貼り付けます。
• 既存の実装計画を具体的な検証チェックリストへ変えます。

この流れは今もPrompt Hotbarの役割をよく表しています。Prompt Hotbarは企画と実行の間で必要な指示を取り出し、実際の文脈と推論はAI会話側が持ち続けます。

このページにはLinkedInに公開した元のデモを埋め込んでいます。ブラウザの制約でプレイヤーが表示されない場合は、下の原文リンクから投稿とコメントを確認できます。

現在の製品構成

最初は9個のスロットだけでしたが、現在は3つの主要領域があります。

Library

• クリックと数字キーでコピーできる9個のHotbarスロット
• 承認、検証、スコープ管理、引き継ぎ、報告、安全確認、文章作成、リリース、デザインなどの繰り返し作業に使う公開-safe Prompt 72件
• よく使う作業モードをまとめて切り替えるPreset / Workflow Set 11件
• 個人Promptを追加、編集、削除し、Hotbarへ配置できるbrowser-local機能
• Board / List表示、検索、categoryとworkflow grouping、並び替え、表示設定
• アカウントなしでも有用だったPrompt、Toolbox、LAB、My Promptへ戻りやすくするbrowser-localのLike / Love this / My Picks
• すでにQuickslotへ配置済みの項目を見分けやすくする淡いaccent表示
• 韓国語と英語のUI、AIの回答言語は別に指定可能
• Prompt本文ではなく安定したpublic IDとslot番号を使う共有方式
• My PromptとLocal Set向けのversioned local JSON backup / restore

Toolbox

レビュー済みの現在のProductionでは、unique card 134件を扱っています。共通Skillや複数ツールにまたがるリファレンスもあるため、製品別の件数を合計してもunique card数とは一致しません。

• Claude Code: 46
• Codex: 41
• Antigravity: 26
• Hermes Agent: 54
• OpenCode: 1
• Slash Commands 49件
• Keyboard Shortcuts 20件
• Agent Skills 26件
• Configuration 3件
• CLI Commands 36件

Toolboxを公式ドキュメントへのリンク集にするつもりはありませんでした。実際に困るのは「ドキュメントはどこだったか」より、「あのコマンドは正確には何だったか」という場面が多かったからです。そこで現在は executable knowledge + provenance を基準にしています。コマンドやconfigurationはすぐコピーできる一方で、公式の出典、最終レビュー時点、リスクも確認できるようにします。

この考え方から、いくつかのルールが決まりました。

• Update、Doctor / Status / Help、permission/autonomyのように繰り返し使うものは、そのProviderが実際に対応している場合に通常のToolboxカードとして表示します。
• 一度導入すれば何度も見ることのないInstall / Setupは、通常のカード一覧を占有しません。Providerメニューと明示的なinstall/setup検索からアクセスします。
• Providerメニューから公式サイト、ドキュメント、Release Notes、Install / Setupへ移動できます。PCの右クリックとモバイルの長押しは、同じメニューを開く補助操作です。
• permission/autonomyを一括して「自動」と扱わず、scoped、auto-reviewed、auto-edit、full-bypassのように実際のリスクを分けます。
• OpenCode V2は、公式情報で確認できるpermission-rule configurationとして扱います。他のツールと見た目をそろえるためだけに、確認できないYOLOコマンドを作りません。
• Provider間で似たコマンドがありそうに見えても、公式な根拠を確認できなければ追加しません。
• Installerやpermission commandもあくまでリファレンスです。Prompt Hotbarが実行することはありません。

重要なのはCLI文字列だけではありません。実務で使ってよいか判断できるだけの出典とリスクの文脈が一緒にあることが大切だと考えています。

LABとDiscovery

LABには現在6件のcapability challengeがあります。実験用Promptをコピーできますが、Prompt Hotbar側でモデルを実行する仕組みはありません。

Discoveryでは、すべての内蔵assetを自動で公開せず、確認する価値のあるPrompt、Workflow、LABだけを選んで公開しています。個別assetのcanonical pageとcopy/open操作はPrompt Hotbarが持ち、PAOSにはプロジェクトの背景、方法論、proof-of-workを残します。

Preference memoryとMy Picks

使い続ける中で、別のretrieval上の問題も見えてきました。一度見つけた項目が役立っても、次回そこへ戻るのが速くなるわけではありませんでした。

v0.6.0では、この問題を小さなpositive preference modelで解きました。状態はneutral、Like、Love thisの3つです。LikeとLove thisは同時に選択されず、選択中の状態をもう一度押すとneutralへ戻ります。dislikeは入れていません。使わなかったことが、そのまま嫌いという意味にはならないからです。

好みの状態はversioned local abstractionの後ろでbrowser-localに保存します。My Picksはpositive stateをまとめ、実際に「また探す」ためのretrieval surfaceにしています。同じブラウザであれば、アカウント、Supabase、cloud profileなしで状態を覚えます。

この境界は意図的に置いています。PCとモバイルの同期、ローカルデータ削除後の復元、アカウント単位のpersonalizationなど、要件そのものがブラウザの外へ出た時点でbackendを検討すればよいと考えています。

製品の学習と個人状態も分けています。ProductionのPostHogへ送るのは、curated assetのpreference遷移やMy Picksの利用など、allowlistに入れた行動メタデータだけです。個人Promptの本文やlocal Prompt IDはanalytics dimensionにしません。persistent person identityも使っていないため、集計データを長期のユーザープロファイルとして解釈しない前提です。

この判断の背景は From Prompt Reuse to Personal Retrieval にまとめています。

Local MCPパイロット

ブラウザを開き直さず、AI coding clientの中で同じretrieval layerを使えるかも個人パイロットで試しました。

Claude Codeにlocal stdio MCP serverを接続し、Prompt検索、Prompt取得、文脈に応じた推薦、Workflow検索、Workflow取得のread-only toolを5個用意しました。runtimeにはレビュー済みの公開-safe snapshotだけを入れ、当時はPrompt 23件とWorkflow 3件を対象にしました。

実際に次のような依頼を処理できました。

• 中断した作業を再開するときに適したPromptを推薦する
• 検証フェーズに合うPromptと、その理由を返す
• 9ステップのcoding-agent Workflowを取得する
• 指定したPromptのcanonical bodyを返す

MCPはbrowser-localのMy Prompt、clipboard、Hotbarの配置、検索履歴、アカウント、cloud stateを読みません。write toolもなく、取得したPromptを代わりに実行することもありません。

現在の製品境界は次のように整理できます。

• Web product: 視覚的な探索、整理、browser-local personalization、Prompt shortcut、Toolbox reference、copy
• Local MCP pilot: 対応するAI client内でのread-only検索、推薦、取得
• AI client / external tool: 実際の作業文脈、推論、実行

packageはstandalone artifactとして準備していますが、個人利用で十分な価値を確認するまでは公開npm配布を保留しています。検証した範囲と制約は local MCP pilot proof note にまとめています。

レビュー済みDiscovery proof set

Discovery Foundationでは、内蔵assetをすべて自動公開せず、小さなレビュー済みセットだけを運用しています。

Prompts

• Inspect the current state before acting
• Keep the work within the minimum required scope
• Run a public/private safety check

Workflows

• Safe implementation workflow for a coding agent
• Business-model design and red-team workflow

Guide

• Before Asking AI to Change Anything: An Evidence-first Inspect, Verify, and Audit Workflow

LAB

• Pelican on a Bicycle: SVG capability check

Toolboxも同じ考え方です。個別のcommand、shortcut、Skill、configurationはPrompt Hotbarをcanonical ownerとし、PAOSへ重複してコピーしません。

Privacyと製品の境界

個人Prompt本文、clipboardの内容、検索語、Hotbarの配置、local setting、preference mapは端末に残します。

共有リンクにはPrompt本文や個人設定を含めません。Production analyticsは少数のnon-personal event allowlistに限定し、automatic pageview、session recording、autocapture、persistent person profileは無効にしています。curated assetのpreference analyticsもcanonical public IDと限定したtransition metadataだけを使い、local personal Prompt IDや本文は送信しません。公開詳細ページのview labelはraw countやunique-person claimではなく、キャッシュした非線形bucketを使います。

Toolboxを加えたことで、もう一つの境界も明確になりました。コピーできるcommand、installer、configuration recipe、permission flag、Agent Skillは情報として提供するものです。Prompt Hotbarが代わりに実行したり、credentialを集めたり、外部環境を黙って変更したりすることはありません。

現在の公開Web productには、次の機能を入れていません。

• Promptやcommandの自動実行
• アカウントやcloud synchronization
• server-sideのPrompt / preference database
• browser-wide global shortcut
• 公開reaction countやsocial ranking
• in-product payment、team機能、Prompt marketplace

Local MCPパイロットもこの境界を変えません。レビュー済み公開-safe snapshotだけを読み、browser-localの個人状態にはアクセスしません。

Prompt Hotbar内で決済も扱いません。将来Supportリンクを有効にする場合も、Core Utilityへのアクセス権とは切り離した外部Support Layerとして扱います。

実際に使って変わったこと

最初は問題をPromptの保存だと考えていました。自分で使い続けると、保存よりretrievalのほうが大きな問題だと分かりました。

似たPromptをまとめる必要があり、Libraryには検索が必要でした。Setは作業モードの切り替えに役立つ必要があり、初めて使う人にはplacementとcopyの仕組みを理解してもらう必要がありました。レビュー済みの一部Prompt、Workflow、LABには、製品を開く前に内容を確認できる公開ページも必要になりました。

Local MCPパイロットはretrievalを外側へ広げました。すでにAI clientで作業しているなら、ブラウザへ戻るより自然言語で検索や推薦を受けるほうが便利なことがあります。Preference Layerは逆に内側を広げました。ブラウザ内では、アカウントを作らなくても「また使う」と明示した項目を覚えられるようにしました。

Toolboxは同じ考え方を作業環境全体へ広げました。繰り返し探すものは、必ずしもAIへ送る文章だけではありません。command、permission mode、diagnostic action、Skillも、信頼できる根拠と一緒に再利用したい対象でした。

そのため、これまでの変化は機能数を増やした履歴というより、retrievalを実際の作業文脈へ近づけてきた過程だと考えています。

prompt storage
→ structured retrieval
→ in-client retrieval
→ preference-aware retrieval
→ cross-tool operational retrieval

小さな不便をすべて機能にしたわけではありません。実際に使いながら繰り返し起きるかを見て、必要な範囲だけを作り、確認できる根拠を付け、要件が大きくなったときだけ構造を広げてきました。

---

関連コンテンツ: A Prompt Library Is Not Enough · Preference memory without accounts · Evidence-first AI Workflow · Local MCP pilot · From personal prompts to team capability