An open-source React textarea component with @mentions, /commands, #tags, inline markdown, undo/redo, file attachments, and dark mode. Install via npm or shadcn registry: npx shadcn@latest add.
No reviews yetBe the first to leave a review for Prompt Area
Maker
📌
Hey Product Hunt 👋
I'm part of the team at Juma (formerly Team-GPT). While building AI chat interfaces, we kept hitting the same wall: every prompt box needs @mentions, /commands, #tags, inline markdown and file attachments, but the only way to get them was to bolt together a mention library + a command palette + a tag input + a markdown editor + an upload widget. Five dependencies and five APIs for one input box.
Most "rich text editors" are document editors (ProseMirror, Lexical, Slate) crammed into a chat box.
We wanted the opposite: something purpose-built for prompt-style inputs.
So we built Prompt Area and open-sourced it:
• One contentEditable component: @mentions, /commands, #tags, inline markdown, files & images, undo/redo, IME (CJK), copy/paste chip preservation, dark mode, and ARIA accessibility.
• Two ways to install, same source, no lock-in either way. npm: "npm install prompt-area" (ships its own CSS, no Tailwind needed). shadcn: "npx shadcn@latest add https://prompt-area.com/r/prompt-area.json" (copies the source into your repo so you own every line).
• Dependency-light: no ProseMirror / Slate / Lexical, zero bundled runtime deps, ~37 kB packed.
• Companion components included: Action Bar, Status Bar, Compact, and Chat Layout. Enough to recreate the inputs in Claude Code, Codex, ChatGPT or Slack.
You don't have to take my word for it: there's a full Vite + React app running live in your browser (no setup) at https://prompt-area.com/docs/try-it-live where you can edit the code and watch the chips and markdown resolve.
It's MIT licensed and free.
We'd genuinely love your feedback: what's missing, what would make it a drop-in for your stack, and which trigger behaviors you'd want next. I'll be here all day answering everything 🙏
contentEditable + custom chip rendering for mentions/tags is usually where things fall apart with IME composition (CJK input especially) since the browser's own cursor/selection handling gets confused by non-text inline nodes mid-composition. you list IME support as a feature explicitly so I'm guessing you hit this - was that the hardest bug to get right, and does it still break on any edge case, like composing a mention right at a chip boundary?
Report
Maker
@galdayan Yes, IME composition was the tricky part. The approach is to not modify the DOM while composition is active.
On `compositionstart` we set a flag. While it is set, the input handler still syncs our internal model but skips all trigger detection and re-rendering, so no chip resolution and no caret changes happen during composition. The native composition runs in a plain text node and we reconcile once, on compositionend. The keydown handlers also check the same flag, so Enter, Shift+Enter, Backspace/Delete, and launch characters do not act while a candidate is being composed. That is the case where confirming a candidate with Enter would otherwise submit the form.
On the chip boundary: composing a mention with a space after a chip works. The case that does not work is typing a trigger directly against a chip with no space between them. That is not a composition or selection problem. Trigger detection runs on a flattened plain-text version of the content where a chip is represented by its literal text, so an @ placed right after a "#readme" chip looks like it is in the middle of a word and gets ignored. The same thing happens with plain ASCII typing, with no IME involved. In practice it is usually hidden because we insert a trailing space after each chip. The fix is to make detection treat a chip boundary as a valid trigger position.
Report
The inline markdown parsing feels really polished, especially how it plays nicely with @mentions and /commands without getting in each other's way. Solid execution for a drop-in component.
Report
Maker
@mentions@hakk231638 Yeah! I love great app UX and this was an imortant bit. Thanks for noticing!
Report
Drop-in textarea with all the niceties I usually end up hand-rolling - mentions, slash commands, markdown - actually feels solid. Skimmed the source and the keyboard handling looks thoughtful, not hacky.
Report
Maker
@kymetigeg Thanks for noticing! We've polished the UX to the extent it's really usable!
Report
We've just swapped our chat input with prompt area and it has been a major gamechanger!
Super excited to be serving 100K+ users through it, thanks for building it!
Hey Product Hunt 👋
I'm part of the team at Juma (formerly Team-GPT). While building AI chat interfaces, we kept hitting the same wall: every prompt box needs @mentions, /commands, #tags, inline markdown and file attachments, but the only way to get them was to bolt together a mention library + a command palette + a tag input + a markdown editor + an upload widget. Five dependencies and five APIs for one input box.
Most "rich text editors" are document editors (ProseMirror, Lexical, Slate) crammed into a chat box.
We wanted the opposite: something purpose-built for prompt-style inputs.
So we built Prompt Area and open-sourced it:
• One contentEditable component: @mentions, /commands, #tags, inline markdown, files & images, undo/redo, IME (CJK), copy/paste chip preservation, dark mode, and ARIA accessibility.
• Two ways to install, same source, no lock-in either way. npm: "npm install prompt-area" (ships its own CSS, no Tailwind needed). shadcn: "npx shadcn@latest add https://prompt-area.com/r/prompt-area.json" (copies the source into your repo so you own every line).
• Dependency-light: no ProseMirror / Slate / Lexical, zero bundled runtime deps, ~37 kB packed.
• Companion components included: Action Bar, Status Bar, Compact, and Chat Layout. Enough to recreate the inputs in Claude Code, Codex, ChatGPT or Slack.
You don't have to take my word for it: there's a full Vite + React app running live in your browser (no setup) at https://prompt-area.com/docs/try-it-live where you can edit the code and watch the chips and markdown resolve.
It's MIT licensed and free.
We'd genuinely love your feedback: what's missing, what would make it a drop-in for your stack, and which trigger behaviors you'd want next. I'll be here all day answering everything 🙏
Repo: https://github.com/just-marketing/prompt-area
Docs & live demo: https://prompt-area.com
contentEditable + custom chip rendering for mentions/tags is usually where things fall apart with IME composition (CJK input especially) since the browser's own cursor/selection handling gets confused by non-text inline nodes mid-composition. you list IME support as a feature explicitly so I'm guessing you hit this - was that the hardest bug to get right, and does it still break on any edge case, like composing a mention right at a chip boundary?
@galdayan Yes, IME composition was the tricky part. The approach is to not modify the DOM while composition is active.
On `compositionstart` we set a flag. While it is set, the input handler still syncs our internal model but skips all trigger detection and re-rendering, so no chip resolution and no caret changes happen during composition. The native composition runs in a plain text node and we reconcile once, on compositionend. The keydown handlers also check the same flag, so Enter, Shift+Enter, Backspace/Delete, and launch characters do not act while a candidate is being composed. That is the case where confirming a candidate with Enter would otherwise submit the form.
On the chip boundary: composing a mention with a space after a chip works. The case that does not work is typing a trigger directly against a chip with no space between them. That is not a composition or selection problem. Trigger detection runs on a flattened plain-text version of the content where a chip is represented by its literal text, so an @ placed right after a "#readme" chip looks like it is in the middle of a word and gets ignored. The same thing happens with plain ASCII typing, with no IME involved. In practice it is usually hidden because we insert a trailing space after each chip. The fix is to make detection treat a chip boundary as a valid trigger position.
The inline markdown parsing feels really polished, especially how it plays nicely with @mentions and /commands without getting in each other's way. Solid execution for a drop-in component.
@mentions @hakk231638 Yeah! I love great app UX and this was an imortant bit. Thanks for noticing!
Drop-in textarea with all the niceties I usually end up hand-rolling - mentions, slash commands, markdown - actually feels solid. Skimmed the source and the keyboard handling looks thoughtful, not hacky.
@kymetigeg Thanks for noticing! We've polished the UX to the extent it's really usable!
We've just swapped our chat input with prompt area and it has been a major gamechanger!
Super excited to be serving 100K+ users through it, thanks for building it!
@iliya_valchanov That's awesome! Thanks for the feedback!