fix(tui): insert skill name without wiping existing prompt text

[HaleTom]

Issue for this PR

Closes #27578
Closes #27160
Closes #18756
Closes #18755

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

When selecting a skill from the TUI skill picker, the skill name is now inserted at the current cursor position using input.insertText() instead of replacing the entire prompt with input.setText(). This preserves any text the user has already typed in the prompt box.

Previously, typing a question then selecting a skill would destructively wipe the entire prompt — a frustrating UX reported multiple times.

Whitespace note (re: review on #27160)

insertText does not trim surrounding whitespace. This is consistent with every other insertText call in the same file — file attachments, paste, and history restore all append " " unconditionally. It's a pre-existing cosmetic pattern, not specific to this fix.

Replaces #27584

The previous PR (#27584) was closed because a close/reopen trick used to force a diff refresh after a rebase left the PR permanently locked — GitHub refused to reopen it ("no new commits on the branch"). This replacement PR has the same change on the same branch.

Credits

This fix borrows from and improves upon two prior community PRs:

• @eyenalxai (#27160) — first attempted fix with insertText + syncExtmarksWithPromptParts pattern
• @paoloricciuti (#18756) — original report and append-based approach

How did you verify your code works?

Manually verified the logic by inspecting the existing patterns in the codebase:

• input.insertText() is already used extensively throughout this file (history restore, paste, file attachments, PromptAppend event handler)
• syncExtmarksWithPromptParts() is already called in onContentChange and during IME submission sync — consistent usage
• setStore("prompt", "input", rawText) matches how onContentChange syncs state

Screenshots / recordings

N/A — 3-line change affecting only the skill picker onSelect handler.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one related PR:

PR #27160: fix(tui): insert selected skill into prompt
#27160

This PR is directly related to the current PR (#27632). According to the description in the current PR, #27160 was a prior community PR attempting the same fix using insertText. The current PR (#27632) builds upon and improves this approach while also addressing issues that caused the previous attempt (#27584) to be locked.

Note: PR #27160 is already mentioned and credited in the current PR's description, indicating the maintainers are aware of this relationship.

[Copilot]

Pull request overview

Updates the TUI prompt skill picker so selecting a skill inserts the skill slash text at the current cursor position instead of replacing the entire prompt, preventing accidental loss of already-typed input.

Changes:

• Replace input.setText() prompt replacement with input.insertText() insertion for skill selection.
• Sync prompt store input and extmark-backed prompt parts after insertion.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[HaleTom]

Production-readiness review — PR #27632

Diff: 1 file, +3/-6 lines

---

Production-ready bar for this PR

1. The onSelect handler must insert the skill prefix without destroying existing prompt text, parts, or extmarks.
2. The new setStore("prompt", "input", ...) call must match the established pattern used by onContentChange and submitInner — not a full store replacement that resets parts: [].
3. syncExtmarksWithPromptParts() must be called after text mutation to keep extmark→part mappings consistent (same as onContentChange).
4. The change must not introduce any new dependencies, imports, or side effects beyond the handler body.
5. The regression test must assert that existing text is preserved (not just that the skill name appears).
6. The change must be consistent with other insertText call sites in the same file (history restore, paste, file attachments, PromptAppend).
7. No typecheck errors, no test regressions in the TUI test suite.

---

Findings

1. Correctness & functional completeness

No issues found in this area based on the diff and reviewed context.

The handler body (prompt/index.tsx:589-593) does exactly three things:

• input.insertText(/${skill} ) — inserts at cursor, preserving surrounding text
• setStore("prompt", "input", input.plainText) — syncs store input field only (not full replacement)
• syncExtmarksWithPromptParts() — rebuilds parts array from extmarks with updated positions

This matches the established pattern in onContentChange (prompt/index.tsx:1498-1503) and submitInner (prompt/index.tsx:1013-1015).

2. Architecture & boundary integrity

No issues found in this area based on the diff and reviewed context.

The change is scoped to a single event handler within the Prompt component. It does not cross package boundaries, introduce new abstractions, or alter any shared contracts.

3. Code clarity, clean code & maintainability

No issues found in this area based on the diff and reviewed context.

The 3-line handler body is straightforward. Each line has a clear purpose: mutate textarea, sync store, sync extmarks. No indirection, no speculative generalization.

4. Comments & code documentation

No issues found in this area based on the diff and reviewed context.

No comments were added or removed. The code is self-explanatory.

5. Tests & validation

[NIT] Regression test mirrors handler logic rather than exercising the real component

• Type: Plausible risk
• Evidence: packages/opencode/test/cli/tui/prompt-skill-select.test.ts:25-29, packages/opencode/test/cli/tui/prompt-skill-select.test.ts:38-39
• Why it matters: The test defines its own handleSkillSelect function that mirrors the production handler shape. It proves the intended behavior is correct but does not exercise the actual DialogSkill → onSelect → input.insertText path through the real Prompt component. If someone later changed the production handler to call setText again, this test would not catch it — the test's own handleSkillSelect would still pass.
• Recommendation: This is acceptable as a first-pass regression test following the same pattern as prompt-submit-race.test.ts. A follow-up integration test using testRender from @opentui/solid that pre-populates the prompt, triggers skill selection, and asserts the textarea content would provide stronger coverage. Not blocking — the test documents the expected behavior and would fail if the mirrored function were changed to the old setText pattern.
• Confidence: Medium

The test does correctly assert:

• Existing text is preserved ("some existing text/test-skill ")
• Store input is updated to the combined text
• syncExtmarks is called
• Empty prompt case works

6. Performance

No issues found in this area based on the diff and reviewed context.

syncExtmarksWithPromptParts() iterates extmarks for the prompt part type — O(n) in the number of parts. This is the same cost as onContentChange, which calls it on every keystroke. No material overhead.

7. Operational risk

No issues found in this area based on the diff and reviewed context.

The change is purely local to the TUI prompt component. No cross-platform concerns, no storage invariants, no migration implications. Revert is a straightforward 3-line diff reversal.

8. Adversarial review

Actively attempting to falsify readiness:

• What assumption is most likely to be wrong? That insertText always appends at the end. In reality, it inserts at the cursor position. If the user has their cursor mid-text, the skill prefix goes there. This is standard editor behavior and consistent with every other insertText call site in this file. Not a bug, but worth noting for future contributors who might expect end-of-buffer insertion.

• What would break first in production? If syncExtmarksWithPromptParts() had a bug that corrupted extmark positions on text insertion, file attachments or agent mentions could display incorrectly after skill selection. However, this function is already called on every onContentChange (every keystroke), so any such bug would be caught immediately in normal use.

• What test gives false confidence? The regression test's handleSkillSelect is a copy of the production logic, not an import of it. It proves the algorithm is correct but doesn't verify the wiring. This is the same pattern as prompt-submit-race.test.ts and is acceptable for this scope.

• What contract appears preserved but is actually drifting? The old code explicitly set parts: [], destroying all non-text parts. The new code calls syncExtmarksWithPromptParts() which rebuilds parts from extmarks. This is actually an improvement — file attachments and agent mentions are now preserved after skill selection. The contract is better, not drifted.

---

What I could not fully verify

1. DialogSkill dismissal behavior: Whether DialogSkill automatically closes the dialog after onSelect fires. This is handled by the DialogSkill component itself and was not reviewed in this diff, but is a prerequisite for the UX to feel correct. Based on the existing dialog patterns in this file, this is expected behavior.

2. Real TextareaRenderable insertText behavior: The test uses a mock insertText that appends. The real @opentui/core TextareaRenderable inserts at the cursor position. This difference is not tested but is consistent with the production code's intent.

3. Typecheck and full TUI test suite: Not run in this review session. The change is small enough that type errors would be caught by CI.

---

Final verdict

✅ Ready to merge — no blocking issues.

Full review file: REVIEW-2026-05-17T16:30:02+07:00.md

[HaleTom]

Committed and pushed as 7028ee41e.

Both tests pass:

• inserts skill name without wiping existing prompt text — verifies existing text is preserved
• inserts skill name into empty prompt — verifies empty prompt case

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[yassine-safraoui]

guys please merge this, I just lost a prompt after 15 minutes of typing...

[HaleTom]

@yassine-safraoui Please thumbs up the description -- this registers as a "vote" for the PR. Cheers!