[Feature]: Project script type that sends a prompt to the composer

[SayarB]

Before submitting

• I searched existing issues and Ideas discussions and did not find this exact shape.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web (Project settings → Actions / Scripts), apps/server (project scripts / t3.json)

Problem or use case

Project actions today are terminal commands: add one in project settings (or t3.json), optionally bind script.{id}.run, and triggering it starts a shell command in the integrated terminal.

I also have a small set of prompts I reuse constantly in a project — for example “review the open PR comments and implement the valid ones”, “update the PR summary from the current diff”, or a short $skill line. Those are not shell commands; they belong in the composer. Today I retype them, paste from notes, or dig through history.

Add Action / Add Script is already where I manage project-scoped reusable actions. It just cannot represent a prompt that should go to the agent the same way a script goes to the terminal.

Docs and the t3.json schema match that limit: each script is a name + shell command. There is no prompt field or type.

Proposed solution

Extend project actions so an entry can be either:

1. Command (existing) — runs in the terminal when triggered.
2. Prompt (new) — puts the stored text into the active thread’s composer and sends it on the same path as a manually typed message.

Concretely:

• In Add / Edit action, choose Prompt vs Command.
• A Prompt entry stores a label and the prompt text (plain text and/or a skill mention, same as something you’d type).
• Triggering it (actions list, toolbar, or keybinding) fills the composer and sends immediately — the way running a Command starts the terminal immediately.
• Prompt entries use the same project surfaces Commands already use (list, shortcuts, t3.json / project settings) so they stay project-scoped and shareable.
• Optional: “insert only, don’t send” for prompts you want to edit before submitting.

Why this is not a skill

Skills ($…) are reusable capabilities for the agent (instructions, workflows, sometimes model-invokable). They live in the provider/project skill system and are picked from the composer.

A prompt action is a reusable user message: one click or shortcut fires a canned turn. Skills can cover some of the same ground if you $skill and hit send yourself; they do not sit next to npm test in Add Action with an icon and script.{id}.run-style binding.

Why this matters

Actions already solve “one click / one shortcut → do the project thing” for the terminal. The same affordance for composer prompts removes repetitive paste/retype for project-specific agent workflows, without inventing a second quick-actions system beside scripts.

Smallest useful scope

• Add a Prompt type next to Command in Add Action.
• Persist label + prompt text on the project (and in t3.json if actions already live there).
• Running the action sends the prompt on the active thread.
• Existing Command actions keep working unchanged.

Related discussions / issues

Closest neighbors, different shape:

• #6996 / #6612 — composer quick-slot buttons that immediately send skills/prompts (separate UI above the composer, not extending project actions).
• #6712 / #1547 — searchable saved snippets that insert into the draft without sending.

Neither is “Prompt type alongside Command in project actions.”

Risks or tradeoffs

• Immediate send can fire accidentally; Prompt actions should be visually distinct from Command actions and easy to edit/remove.
• Sending while a turn is already running should follow the same queue / reject rules as a normal composer send.
• Schema needs a clear distinction so old clients and t3.json imports never treat prompt text as a shell command.

Contribution

• I would be open to helping implement this.

[JamesOBrien2]

Note

🤖 gpt-6.1-terra responding on behalf of James

I'd like to help move this idea forward, starting with a small project-scoped action containing a label and prompt for the current thread, using its current provider and model. Would maintainers be interested in that direction and scope?

Before implementation, should triggering insert into the composer for review or send immediately? How should an existing draft and a running turn be handled, and should the action follow the ordinary send permissions and queue behavior? Which existing action entry points and clients must the first version support? If shared through t3.json, how should imports and older clients distinguish prompt text from shell commands safely? I'd leave model overrides and new-thread targets for later unless maintainers want them in scope.

Existing discussion: #15153. Related broader idea: #19524. Closed implementation: #24144. Its closure requests a link to explicit prior approval or approval in an Ideas discussion; no such public approval has been identified here.