Skip to content

docs: prompt-packs plan — declarative extensions and a self-extending Chat - #625

Open
kcarnold wants to merge 3 commits into
mainfrom
claude/thoughtful-extensibility-platform-6z0yku
Open

docs: prompt-packs plan — declarative extensions and a self-extending Chat#625
kcarnold wants to merge 3 commits into
mainfrom
claude/thoughtful-extensibility-platform-6z0yku

Conversation

@kcarnold

Copy link
Copy Markdown
Contributor

Adds docs/prompt-packs-plan.md, a design doc for the lowest tier of the extensibility ladder, grown out of a discussion of what it would take for Thoughtful to be extensible by people who aren't us — including domain experts who aren't software engineers.

What's in it

  • The extensibility ladder: prompt packs (inert data, no merge, no hosting) → hosted tools (tool-launcher-plan.md) → platform PRs (reserved for new primitives). Trust is carried by each tier's shape rather than by code review.
  • Pack format sketch: a prompt plus a declared subset of a generic runtime tool vocabulary, mounted on one of four surfaces (button, persona, lens, ritual), executed by the manual tool-loop pattern already proven in my-words/interaction/liveResponder.ts.
  • The runtime tool vocabulary tables (document / writer-interaction / memory-and-history / Chat-only authoring): for each tool, its essential schema, which concepts need it, its precedent in the repo, and consent/robustness notes. The design-doc verb list (ask, quote, notice, offer, resurface…) maps onto the tools; the covenant holds structurally because there is no silent-write tool to grant.
  • Coverage analysis: ~14 of 19 sketched concepts (interface-concepts.md + interaction-concepts.md + existing pages) reduce to packs given roughly ten tools — offer/ask_writer/highlight/annotate cover most, remember/recall add the stateful ones, read_history/get_revisions/search_corpus unlock the rest. The honest 20% (Loom, mindmap, voice, Skim View, Inkwell) needs its own rendering surface or transport and belongs in the hosted-tool tier.
  • Self-extension: Chat gets save_pack/test_pack/list_packs, so a writer can turn a conversational behavior into a persistent pack by asking ("make that a button"), with provenance and full-prompt legibility as the trust story.
  • Phasing, wired to existing issues: #597 (Revise grid as data), #583 (move view/highlight into Chat), Send hosts ranges, not needles: one text-matching implementation across editors #589/#591/#592`` (phrase matching that highlight/`propose_edit` lean on), #615 (consent gate that `read_history` depends on).

Also adds a short cross-reference at the top of tool-launcher-plan.md marking where the pack tier ends and the hosted-tool tier begins.

Docs only — no code changes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EUSXFcRA7ox4u9x1QENyHw


Generated by Claude Code

claude added 3 commits August 31, 2026 16:23
… Chat

Design doc for the lowest tier of the extensibility ladder: extensions as
prompt packs (prompt + tool grants, inert data) executed by the existing
UI, with Chat as the conversational authoring environment via save_pack /
test_pack tools. Includes the runtime tool vocabulary table and a coverage
analysis showing ~80% of the sketched concepts (interface-concepts.md,
interaction-concepts.md) reduce to packs given ~10 generic tools; the rest
need own rendering surfaces and stay in the hosted-tool tier
(tool-launcher-plan.md, now cross-referenced).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EUSXFcRA7ox4u9x1QENyHw
…pace; add MCP analysis

The memory/history tools (remember, recall, read_history, get_revisions,
search_corpus) were reinventing a filesystem and git. Replaced with a
per-(user, pack) virtual workspace: files, grep, and git history, whose
idiom the model already knows and whose contents the writer can read,
export and delete. Names just-bash / just-git as candidates, with the
undici network dependency flagged as due diligence rather than assumed
away, and states the covenant boundary explicitly: the document is not a
writable file in the workspace, and the workspace has no network.

Adds a build-vs-reuse section (W3C Web Annotation TextQuoteSelector for
the phrase-anchoring issues, OAuth device flow as precedent, XMPP's model
without its wire) and a section on the three roles MCP could play here:
outbound client to third-party servers as the cheap unlock, MCP-shaped
internal tool definitions, and an inbound server as the powerful but
values-fraught case that tests whether the covenant belongs to our UI or
to the platform.

Also sharpens the ask_writer rationale to floor control, non-chat
surfaces, and typed study data, rather than the ability to ask at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EUSXFcRA7ox4u9x1QENyHw
…ost, not servers they run

The doc's founding question is whether a domain expert who is not a
software engineer can extend Thoughtful, and its own distribution story
failed that test: 'a writing center publishes an MCP server' assumes a
public HTTPS endpoint, multi-tenant auth and someone on call — more
engineering than the monorepo PR the ladder exists to avoid.

Adds a 'Who can actually publish?' section with the principle that LLMs
made authoring cheap and operating no cheaper, a table of what skill each
distribution mechanism actually demands, and the rule that anything asked
of a domain expert must be something we host. Names collections (shared
sets of packs on our infrastructure, Google-Docs-shaped) as the real
distribution primitive, with author-hosted static URLs as an option
rather than a requirement, and states what hosting distribution obliges
us to take on — provenance, reporting, moderation — since that cost is
what made self-hosting tempting to write down.

Repositions MCP accordingly: the writing center is a consumer of servers
others already run, never an operator. Collections added to the phasing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EUSXFcRA7ox4u9x1QENyHw
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants