Actions

Last updated: November 2026

An Action is a named prompt you fire at a task, issue, or pull request to start agent work.

You can change every Action’s wording and agent, and choose which Action each kind of work suggests as its one-click default. An automation can also run an Action for you, on a schedule or when new GitHub or Jira activity matches its query.

---

The four built-in Actions

Kepler comes with 4 Actions, and you can edit each of them.

Action	What it asks the agent to do	Available on
Plan	Research the code first, write out the proposed approach, change nothing, and wait for your confirmation	Tasks, Issues, Pull requests
Implement	Read enough surrounding code to be confident, then make the changes directly rather than describing them	Tasks, Issues, Pull requests
Review	Review the pull request if one is attached, otherwise the uncommitted work in the worktree	Tasks, Pull requests
Address Feedback	Triage the review comments, apply what’s worth applying, and push back on the rest instead of applying every suggestion blindly	Pull requests

Address Feedback never appears on a task with no pull request.

You can edit and reset built-in Actions, but you cannot delete them.

---

Where the Action button appears

You fire Actions from a split button. The left half runs the Action suggested for that surface; the chevron opens the full list.

Firing an Action from a Todo row is also how an issue or pull request that is not tracked yet becomes a task in Kepler.

On a narrow card, the button shrinks to a play icon. On a phone, a row has a single ⋮ menu instead that lists every Action.

In the list of Actions, hover a row, or move focus to it, to read that Action’s prompt.

Inside a task, Actions are under the chevron on the composer’s send button: type a refinement, then pick the Action to fire it with. In a composer that starts something new, such as the New task composer or a panel’s draft, picking an Action does not fire it. It sets the main button to that Action, and the agent pill shows the Action’s own agent, if it names one. See Create a task.

Task rows do not carry an Action button. A task’s own operations are in the ⋮ menu on its row.

---

Firing an Action

An Action runs at once, unless Kepler needs you to choose where it runs.

The left half: one click

The left half of the button runs the suggested Action straight away, in the current session if one exists. It stops to ask only when the task has 2 or more worktrees.

The number of issues or pull requests attached to the task does not change what the Action does. Kepler sends the Action’s prompt word for word, and every attached item reaches the agent as shared context. To have the agent look at one item first, say so in the prompt box or in the chat.

The chevron: the deliberate path

An Action you pick from the chevron list asks where to run it whenever there is a choice, even between a new session and the current one.

At the bottom of the list, Manage Actions… opens Settings → Actions.

From the keyboard, the two halves are separate Tab stops, the Action first. Down Arrow or Alt+Down on the Action opens the list too, and closing the list puts focus back on the Action. Every split button in Kepler (Send, Open in, Run) works the same way.

Choosing where it runs

The Run in view asks 2 separate questions.

New session, or a current one? A two-way toggle between New session and Current session. Current session lists every reusable session with its worktree, so clicking a row queues the Action into that exact session.

Which worktree? In New session, the rows are All N worktrees, A new worktree, and then one row per branch. In Current session, individual sessions replace branches that already have sessions.

Clicking any row runs the Action immediately, with no separate confirm step.

When an Action runs on several worktrees, Kepler takes you to the first one you picked. Under Current session, a worktree with no open session gets a new one, so All N worktrees always means all of them.

A task with no worktree runs the Action in a folder attached to it, or else in the task’s own folder. With neither, Kepler tells you it has nowhere to start a session.

Firing into a running session

Firing into a live session queues the prompt behind whatever the agent is currently doing. Nothing is dropped and nothing is canceled, and Kepler takes you to the session the prompt went into.

---

Set your suggested Actions

To choose the Action each kind of item suggests, open Settings → Actions → Suggested Actions.

Each row sets the Action that the left half of the button runs for that kind of item.

Pull requests split by who wrote them, not by what you want to do with them. When you want the other Action, it is one click away in the chevron.

To show only the chevron on the button for a kind of item, set its slot to None.

Suggest automatically, below the pickers, is on by default. When you link an issue or pull request to a new task, the composer’s button switches to that item’s suggested Action, and anything you type is added to the Action’s prompt. Turn it off to keep Start.

---

Edit an Action

To edit an Action, go to Settings → Actions and click the Action’s row under All Actions. The editor opens as its own page.

Each row shows what the Action does and where it is available. Once you have a custom Action, the list splits into Built in and Custom.

The editor has these fields:

Field	What it does
Title	Required. The name shown on the button and in the chevron list
Prompt	Required. Sent to the agent word for word, and can be or start with one of your skills: type / (or $ for Codex) to pick one
Available on	Where the Action is offered: Tasks, Issues, Pull requests, or several. Pick at least one
Agent	Which agent runs it. See below

Create your own

To create an Action, click New Action in Settings → Actions.

Custom Actions work exactly like the built-in ones. Make one for any prompt you would otherwise retype, such as backporting a fix, writing a migration, or auditing a dependency bump.

Example: Prepare for review

This Action asks the agent to gather the evidence a reviewer needs before you read the diff, so you start from what the agent did and what it did not check. To create it, click New Action in Settings → Actions and fill in the following fields:

Field	Value
Title	Prepare for review
Available on	Tasks
Agent	Use default agent, or a preset for a different agent from the one that wrote the code

Use the following text for Prompt:

Before I review this work, write a review summary in this session. Include:
- What the change is supposed to do, in one or two sentences
- Each file you changed, and why
- The commands you ran to test the change, and their results
- What you didn't test, and anything you're unsure about
Don't change any files.

The summary is the agent’s own account. Check it against the diff in Review Changes before you commit.

Example: Open a pull request

Kepler has no “create pull request” button, so the agent or you open one. This Action has the agent open it, with a note in the description that an agent helped write the change. Fire it after you’ve reviewed and committed the work. To create it, click New Action in Settings → Actions and fill in the following fields:

Field	Value
Title	Open a pull request
Available on	Tasks
Agent	Use default agent

Use the following text for Prompt:

Push this worktree's branch and open a pull request against its base branch.
Write a title and a description that say what changed and why.
End the description with this line:
"An AI coding agent helped write this change, and a person reviewed it."
If the worktree has uncommitted changes, stop and tell me.

The agent opens the pull request with the tools it has, such as your Git host’s command-line tool. When it publishes the pull request, Kepler attaches it to the task. See Review Changes.

Restore defaults

To undo your edits to one Action, click Restore default on its row. The row shows Restore default only after you edit the Action. To undo your edits to every Action at once, click Restore all defaults in the All Actions section header.

An Action you have never edited picks up new default wording when Kepler updates. Restore default discards your edit.

Deleting a custom Action that a suggested-Action slot points to sets that slot to None, so its rows show only the chevron. To pick a new suggested Action, go back to Settings → Actions → Suggested Actions.

You cannot delete an Action that an automation runs. Delete the automation first; see Automations.

---

Setting an Action’s agent

By default an Action runs on your default agent, configured in Settings → Tasks → New tasks → Default agent. To change it, open the Preset list in the editor’s Agent field and pick one of the following:

Choice	What the Action runs on
Use default agent	Your default agent configuration
A preset, shown as {preset} · {agent}	That preset’s agent, with its model, mode, and options. If that agent has more than 1 account, pick the account below the list
Custom agent settings	The agent, model, and mode you set for this Action alone

You save agent presets in Settings → Agents → Agent presets; see Settings. For example, pick a cheap, fast preset for triage and review, and a heavier one for implementation. If an Action’s preset no longer exists, the Action shows Preset unavailable for this agent.

An automation runs its Action unattended, on issue and pull request text that other people write. If an automation uses the Action, choose a mode that acts without asking only if you trust everyone who can open or comment on those items.

Custom agent settings is an all-or-nothing override: it pins the provider, account, model, mode, and options together, rather than changing one of them and inheriting the rest.

Three rules govern which agent actually runs:

• A model belongs to its provider, so a pinned model never runs on a different agent.
• If an Action names an agent you do not have installed, the override falls back whole to your default agent.
• An agent you pick explicitly at the point of firing beats an Action’s override.

Review with a different agent

You can have one agent write the code and a different agent review it. A reviewer that did not write the code is less likely to repeat the author’s mistakes.

To give Review its own agent, take the following steps:

1. Go to Settings → Actions, and click Review under All Actions.
2. In the Agent field, pick a preset for a different agent from the one that writes your code, or choose Custom agent settings and pick that agent. Implement uses your default agent unless you’ve changed it.
3. Click Save.

Review now runs on that agent, whether you fire it at a task’s uncommitted work or at an attached pull request, with the model and mode you chose for it.

To use a different reviewer just once, pick the agent when you fire Review. An agent you pick at that point beats the Action’s override.

The review is a report, not an approval. You read it in the session and decide what to change before you commit.

---