one-code-extension 0.1.4 → 0.3.0

package/docs/guide/skills-plugins-and-mcp.md

@@ -0,0 +1,176 @@
+# Skills, plugins, and MCP
+
+One Code runs Agent Skills, Claude Code plugins, and MCP servers from your
+existing configuration. This page covers using each and the panels that
+manage them.
+
+## Skills
+
+An Agent Skill is a packaged set of instructions for a kind of task. One
+Code discovers skills from these places, in order of precedence:
+
+1. `.claude/skills/` in the project
+2. `~/.claude/skills/` and `~/.agents/skills/`
+3. Skills from installed plugins
+4. The bundled catalog
+
+A skill of the same name earlier in the list wins.
+
+The model calls a skill with the `skill` tool when a task matches its
+description. You can also run one yourself by typing its name as a slash
+command, as in Claude Code: `/simplify`, `/code-review`, or any skill from
+`.claude/skills/`. Anything after the name is passed to the skill as
+arguments. Plugin skills keep their plugin prefix and are run as
+`/skill:<plugin>:<name>`. pi's `/skill:<name>` form works for every skill.
+
+A skill's slash command is not created when the name is already taken by a
+built-in command, a `.claude/commands/` template, or another skill.
+
+### Manage skills
+
+`/skills` opens the skills panel. Each skill has one of four states, which
+control how the model sees it:
+
+| State | Effect |
+|---|---|
+| On | The model sees the full description and can call the skill. |
+| Name only | The model sees the name but not the description. |
+| User only | You can run it as a command; the model does not see it. |
+| Off | Not available to anyone. |
+
+**↑** and **↓** move, **Enter** or **Space** cycle the state, **/**
+searches, **t** sorts by name or state, **Esc** closes. Plugin skills are
+managed from `/plugins` instead. States are saved under One Code's plugin
+directory, never in the skill files.
+
+### Bundled skills
+
+Four of Claude Code's built-in skills ship with One Code:
+
+- `simplify`: clean up recently changed code for clarity.
+- `code-review`: review changes for correctness bugs.
+- `security-review`: review changes for security issues.
+- `fewer-permission-prompts`: scan your usage and propose an allowlist.
+
+A skill of the same name in your own `.claude/skills/` takes precedence.
+
+### Skills not bundled
+
+The bundle omits the Claude Code skills that depend on services One Code
+does not have:
+
+| Group | Skills omitted |
+|---|---|
+| Hosted artifacts and design | `design`, `design-sync`, `dataviz`, the `artifact-*` guides, and the dashboard, report, table, explainer, plan, and whiteboard publishers. |
+| Claude Code configuration, account, and desktop workflows | `update-config`, `keybindings-help`, `claude-in-chrome`, `debug`, `usage`, `explain-usage`, `setup-cowork`, `schedule` cloud routines, `batch`, and `claude-code-guide`. |
+| Run-skill generation | `run` and `run-skill-generator`. Use project-local run skills instead. |
+| API reference | `claude-api`. |
+
+One Code provides `/init` and `/loop` itself. Commit and pull-request
+workflows are available through the `commit-commands` plugin.
+
+You can add your own skills under `.claude/skills/`. A skill that requires a
+service or tool still needs that service or tool configured.
+
+## Custom commands
+
+Markdown files in `.claude/commands/` (project) and `~/.claude/commands/`
+(user) become slash commands with the file's name, as in Claude Code.
+`$ARGUMENTS` is replaced with what you type after the command. Plugin
+commands are namespaced as `/<plugin>:<command>`, and may run shell
+snippets from their body; oversized output is written to a file rather than
+truncated.
+
+## Plugins
+
+A plugin bundles agents, skills, commands, hooks, MCP servers, and
+language-server configuration. One Code picks up plugins installed under
+`~/.claude/plugins` and makes their contents available, each namespaced by
+plugin so names never collide with yours. The `enabledPlugins` key in your
+Claude Code settings is honored.
+
+Run `/plugins` to open the marketplace panel. Its four tabs are:
+
+- **Discover**: browse plugins from your marketplaces. Type to search,
+  **Space** to install, **Enter** for details.
+- **Installed**: see what is installed and turn plugins, or individual
+  skills within them, on or off. It works like `/skills`: **Enter** or
+  **Space** toggles the selected row, **v** opens its details, **e** and
+  **d** set it on or off, **u** uninstalls, **f** marks a favorite, and
+  **/** opens the search box (**Esc** leaves it). MCP servers have no
+  toggle, so **Enter** opens their details.
+- **Marketplaces**: the sources plugins come from. **a** adds one (a GitHub
+  `owner/repo`, a git URL, or a local path), **u** refreshes, **d** removes.
+- **Errors**: plugins that failed to load, and why.
+
+**←** and **→** switch tabs; **Esc** closes.
+
+Plugins you install through One Code go to One Code's own plugin directory
+under its agent directory. Plugins Claude Code installed stay read-only;
+turning one off writes to an overrides layer, never to `~/.claude`.
+Installing or toggling a plugin takes effect for commands at once; its MCP
+servers, agents, and hooks load on the next session, and the panel says so
+when you close it.
+
+Marketplace sources are git repositories and local paths. Version pinning,
+npm or pip sources, and dependency resolution are not implemented.
+
+## MCP servers
+
+The Model Context Protocol (MCP) lets external servers provide tools and
+resources to the model. One Code reads server definitions from:
+
+- `.mcp.json` in the project (the nearest one, walking up to the
+  repository root)
+- `~/.claude.json` (the `mcpServers` key)
+- `.claude/settings.local.json`
+- Installed plugins
+
+Definitions may reference environment variables as `$VAR` or `${VAR}` in
+the command, arguments, environment, URL, and headers; an unset variable
+produces a warning. Stdio servers (`command`) and HTTP servers (`url`) are
+verified; servers using server-sent events are untested.
+
+### Approve a project's servers
+
+Servers listed in a project's `.mcp.json` run only after you approve them.
+On the first start in a project, One Code shows the servers found, with the
+command each one runs, and offers to use this server, to use this and all
+future servers in the project, or to decline. Approvals are stored in
+`~/.onecode/mcp/project-approvals.json`, tied to the server's
+configuration, so a changed command asks again. If you decline, the server
+appears as disabled in `/mcp`; choosing Enable there approves it.
+
+Claude Code's `enabledMcpjsonServers`, `disabledMcpjsonServers`, and
+`enableAllProjectMcpServers` settings are honored from
+`~/.claude/settings.json`, and from `.claude/settings.local.json` when that
+file is not tracked by git. They are never honored from a checked-in
+`.claude/settings.json`, which would let a repository approve its own
+servers.
+
+In non-interactive runs, unapproved servers are skipped with a note on
+stderr.
+
+### Use MCP tools
+
+Each server's tools appear to the model as `mcp__<server>__<tool>` and load
+on demand, so a server with many tools does not bloat the prompt. Servers
+also expose resources, which the model can list and read.
+
+A permission rule naming `mcp__<server>` covers every tool of that server.
+
+### Manage servers
+
+`/mcp` opens the server manager: servers grouped by source (user, project,
+plugin), each with its status, tool and resource counts, and any warnings.
+**Enter** on a server shows its details and a numbered action list:
+
+- **Reconnect** restarts the connection.
+- **Disable** stops the server and remembers that in `~/.onecode` (user
+  scope or per repository), so it stays disabled across sessions.
+  **Enable** reverses it.
+- **Authenticate** appears for HTTP servers that need OAuth. It opens your
+  browser for sign-in; tokens are stored under `~/.onecode/mcp-auth/` with
+  owner-only permissions.
+
+Press the action's number to run it, or **Esc** to go back.

package/docs/guide/subagents-and-workflows.md

@@ -0,0 +1,193 @@
+# Subagents and workflows
+
+One Code delegates work in two ways: subagents for tasks that deserve their
+own context window, and `ultracode` workflows for fanning a large job out
+across many agents at once.
+
+## Subagents
+
+A subagent is a child agent with its own context window. It does its work
+and returns a report, so the noise of an investigation stays out of your
+main conversation.
+
+### Where subagents come from
+
+- Three ship with One Code: `general-purpose` (any task), `explore`
+  (read-only search), and `plan` (design an implementation plan).
+- Markdown definitions in `.claude/agents/` (project) and
+  `~/.claude/agents/` (user), each setting an agent's model, tools, and
+  system prompt. A project definition wins over a user definition of the
+  same name.
+- Plugins can add agents, namespaced by plugin.
+- `fork`, a synthetic type that copies the current conversation.
+
+Run `/agents` with no agents running to list the catalog with each agent's
+tools.
+
+### Run a subagent
+
+The model delegates through the `Agent` tool. You steer it in plain
+language: "use a subagent to find every call site", or "explore this with
+the `explore` agent". What happens next:
+
+- **The run starts in the background.** The model receives a task id at
+  once and keeps working. The subagent's report arrives as a notification
+  when it finishes, mid-turn if the model is still busy, or as a new turn
+  if it is idle. In a `-p` or `--mode json` run, the subagent runs to
+  completion instead and the report is returned inline.
+- **You can keep talking to the model** while agents run.
+- **Subagents go through your permission gate.** A subagent's tool calls
+  are decided by the same mode, rules, and classifier as the main session,
+  and a prompt it triggers is shown to you. Your hooks run inside subagents
+  too.
+- **A finished agent can be messaged later.** The `SendMessage` tool
+  reaches a running agent live, or resumes a finished one from its saved
+  session. `list_agents` lists the session's agents and their status.
+
+Two options change how a subagent runs:
+
+- **Fork.** A forked subagent inherits the whole conversation so far, for a
+  task that needs everything you have built up. Forks run on the main
+  model and can only be started from the main conversation. Depth is
+  limited: the main conversation can start a subagent, and that subagent
+  one more, but no further.
+- **Worktree isolation.** The subagent gets its own git worktree, branched
+  from `HEAD`, so it can edit files without colliding with your working
+  tree or other agents. A worktree the agent left unchanged is removed;
+  otherwise it is kept and its path reported.
+
+### Choose the subagent model
+
+Subagents and workflow agents can run on a different model or provider
+from the main session. The default is chosen for you: the cheapest model on
+your provider that meets the same capability floor auto mode's classifier
+uses (a Sonnet-class model for a Sonnet-class or stronger session), never a
+dearer one than your main model. When an Artificial Analysis key is
+configured, measured coding ability is used for that floor; see
+[Automatic model selection](providers-and-models.md#automatic-model-selection).
+
+To set the default yourself:
+
+| Command | Effect |
+|---|---|
+| `/subagent <provider/model-id>` | Save a default for subagents and workflow agents. Short aliases such as `sonnet` or `haiku` work too: by name when your provider has that model, otherwise as that class within your provider. |
+| `/subagent inherit` | Use the main session's model. |
+| `/subagent status` | Show the configured default, the model it resolves to, and where the setting came from. |
+| `/subagent clear` | Remove the saved default and return to automatic selection. |
+| `/subagent` | Open a model picker. |
+
+The choice is saved to `~/.onecode/settings.json`. A saved choice is tied
+to the provider it was made on; after switching providers, run
+`/subagent status` and pick again if it no longer applies.
+
+On a Claude session, Claude Code's `CLAUDE_CODE_SUBAGENT_MODEL` variable is
+honored, from the environment or from the `env` block of your user or
+managed settings. One Code's own setting wins when both are set.
+
+An agent definition's own `model` field overrides the default for that
+agent.
+
+### Follow agents live
+
+While agents run, the panel below the editor shows a tree: `main` first,
+then each agent with its type, what it is doing right now ("Reading
+src/index.ts", "Running a command"), its elapsed time, and its token count.
+Nested agents appear under their parent. A finished agent stays for a few
+seconds.
+
+- Press **↓** from an empty editor to focus the rows (after the shells
+  chip, if background shells exist).
+- **↑** and **↓** select an agent. **Enter** opens its live transcript.
+- **x** stops the selected agent. **ctrl+x** then **ctrl+k** stops all of
+  them.
+- In the transcript: **↑** and **↓** scroll, **PgUp** and **PgDn** page,
+  **Tab** moves to the next agent, **←** returns to the rows, **Enter**
+  closes the view.
+
+`/agents` opens the panel on the newest agent.
+
+## Git worktrees for the whole session
+
+Separately from subagents, the model can move your whole session into an
+isolated worktree with `enter_worktree`. It creates a worktree under
+`.claude/worktrees/`, branched from your current `HEAD`. Every shell command
+and relative path then resolves there, and your main working tree stays
+untouched until `exit_worktree` leaves the worktree, keeping or removing
+it. Removal is refused while there is uncommitted or unmerged work. Ask for
+this when a task will make sweeping changes you want to review before
+merging.
+
+## Ultracode workflows
+
+For a big job (a broad audit, a migration, a review worth double-checking),
+include the word **`ultracode`** in your message. The model writes a short
+JavaScript script that fans the work out across many agents in parallel,
+then runs it with the `workflow` tool.
+
+The keyword arms the turn it appears in. A message you queue while the
+model is still working does not arm the next turn. For a longer stretch of
+this kind of work, turn the mode on with `/effort ultracode`: it sets the
+reasoning effort to `xhigh` and keeps workflow orchestration armed until
+you change the effort again. The footer shows `✦ ultracode` while it is
+armed.
+
+### How a workflow runs
+
+- The script runs in a separate thread, so a runaway script cannot freeze
+  the interface. A script that stops making progress is stopped after a
+  few seconds; a run is capped at 30 minutes.
+- The run goes to the background and the model gets a run id. Progress
+  shows in a strip below the editor (**↓** to focus it, **Enter** to open,
+  **x** to stop) and in `/workflows`.
+- Every completed agent call is journaled. Re-running a workflow with
+  `resumeFromRunId` replays the calls whose inputs did not change at no
+  cost and runs only what differs. A background run does not survive the
+  end of a session, but its journal does.
+- A script can carry an output-token target. Once the target is reached,
+  new and queued agent calls stop; agents already running finish and can
+  land above it.
+- Fan-out agents use the subagent default model, so a cheap subagent tier
+  keeps a large run affordable while the main conversation stays on a
+  frontier model.
+- In a `-p` or `--mode json` run, the workflow runs to completion and
+  returns its result inline.
+
+### The run viewer
+
+`/workflows` opens the viewer: a list of phases, the agents in each phase,
+and a detail pane with each agent's prompt and output, with a live ticker.
+
+| Key | Action |
+|---|---|
+| **↑**, **↓** | Move. |
+| **Enter** | Open a phase or agent; expand a truncated prompt. |
+| **Tab** | Switch to another running workflow. |
+| **PgUp**, **PgDn** | Scroll the detail pane. |
+| **x** | Stop the running workflow. |
+| **s** | Save the script to `.claude/workflows/<name>.js`. A second **s** confirms an overwrite. |
+| **Esc** | Go up a level, then close. **q** closes at once. |
+
+From the prompt, `/workflows stop <runId>` stops a run, `/workflows log
+<runId>` prints its recent events, and `/workflows list` prints this
+session's runs and the saved workflows.
+
+### Save a workflow to reuse
+
+Scripts in `.claude/workflows/` (project) or `~/.claude/workflows/` (user)
+can be invoked by name instead of describing the job again. A project
+script shadows a user script of the same name. The viewer's **s** key saves
+the current run's script there.
+
+## Reasoning effort
+
+`/effort` sets how much reasoning the model spends: `off`, `minimal`,
+`low`, `medium`, `high`, `xhigh`, `max`, or `ultracode`. A bare `/effort`
+opens a slider (**←** and **→** or **h** and **l** move, **Enter** confirms).
+Levels the current model does not support are skipped. **shift+tab** cycles
+the plain levels; cycling away from `xhigh` while ultracode is armed turns
+ultracode off.
+
+Changing the effort re-caches the conversation, so the next request costs
+more than usual. `/effort` does not save the level across restarts; to
+save one, open pi's `/thinking` picker and press **ctrl+s**, or pass
+`--thinking <level>` at launch.

package/docs/guide/tasks-and-background-work.md

@@ -0,0 +1,111 @@
+# Tasks and background work
+
+One Code keeps long-running work out of the model's way. This page covers
+the structured task list, background shells, monitors, scheduled
+wake-ups, and how the results of background work reach the model.
+
+## The task list
+
+For multi-step work the model keeps a structured task list, using the
+`task_create`, `task_get`, `task_list`, and `task_update` tools. Each task
+has a subject, a description, a status (pending, in progress, or
+completed), an optional owner, and dependencies on other tasks.
+
+While the list has entries, a pinned widget below the transcript shows a
+summary line and up to 12 tasks: `✔` for completed, `◼` for in progress,
+`◻` for pending.
+
+| Command | What it does |
+|---|---|
+| `/tasks` | Prints the full list. |
+| `/tasks hide` | Hides the widget. |
+| `/tasks show` | Shows it again. |
+
+The list is stored inside the session, so it survives a resume and follows
+the branch you are on in `/tree`. If the model has not touched the list for
+a while during a long task, it is reminded that the list exists.
+
+## Background shells
+
+When the model runs a command with `run_in_background`, the command starts
+detached and the model gets a task id at once. Output spools to a log file
+under the session directory. When the command finishes, the model is
+notified with the result, and it can read the output at any time with
+`task_output` or stop the command with `task_stop`.
+
+Running and recently finished shells appear in the panel below the editor:
+
+1. Press **↓** from an empty editor to focus the shells chip.
+2. Press **Enter** to open the Background list, which shows each shell's
+   status and command. **↑** and **↓** select, **x** stops the selected
+   shell, **Esc** goes back.
+3. Press **Enter** on a shell to see its status, runtime, command, and a
+   live box with the last lines of output. **←** returns to the list;
+   **Esc**, **Enter**, or **Space** closes the section; **x** stops it.
+
+A finished shell stays in the list for a minute. From the chip, a second
+**↓** moves on to the subagent rows in the same panel.
+
+The turn-duration line reports how many shells are still running when a
+turn ends. When a session ends, running shells are stopped and the next
+session is told which ones.
+
+## Monitors
+
+The `monitor` tool watches a long-running command, or a WebSocket URL, and
+turns each line of output (or each message) into an event. Events are
+batched and delivered to the model as notifications: at most once a second
+while the model is idle, once every ten seconds while it is working, so a
+noisy process does not flood the conversation.
+
+A monitor runs until its command exits or its timeout passes (five minutes
+by default, one hour at most), or for the whole session when started as
+persistent. The model can stop it with `task_stop`.
+
+A monitor is not auto-approved, because it runs a shell command; the
+permission gate treats it like `bash`.
+
+## Scheduled wake-ups and loops
+
+`/loop` runs a task repeatedly. Two forms exist:
+
+- **Fixed interval.** `/loop 5m check whether the deploy finished` runs the
+  task every five minutes. Intervals accept `s`, `m`, and `h`, and are
+  clamped between one minute and one hour. The first run happens
+  immediately. A tick that arrives while the model is still busy is
+  skipped, not queued.
+- **Self-paced.** `/loop watch the CI run` with no interval lets the model
+  choose when to check next. It uses the `schedule_wakeup` tool, which
+  schedules one wake-up at a time between one minute and one hour ahead.
+  The model is told to pick a delay that matches what it is waiting for,
+  and to stop the loop when the task is done.
+
+`/loop status` (or a bare `/loop`) reports the current loop. `/loop stop`
+ends it. Only one loop runs at a time, and loops end with the session.
+
+## The background list
+
+`/background` lists every background task in the session: monitors,
+background shells, and background subagents, with their id, kind, status,
+and start time. A small widget shows the count of running tasks that have
+no panel of their own.
+
+## How results reach the model
+
+Background work reports back through notifications:
+
+- A notification is delivered as soon as the model finishes its current
+  batch of tool calls, or starts a new turn if the model is idle.
+- Notifications that arrive within a quarter of a second of each other are
+  merged into one message.
+- After you interrupt a turn, notifications are held and attached to your
+  next prompt instead of starting a turn on their own.
+- Each notification is framed as an automated event, so the model does not
+  mistake it for something you said or approved.
+
+## Non-interactive runs
+
+In `-p` and `--mode json` runs nothing can run in the background, because
+the process exits when the turn settles. Background shells, monitors,
+subagents, and workflows run to completion and return their output
+directly. `/loop` and `schedule_wakeup` do not fire.

package/docs/guide/terminal-interface.md

@@ -0,0 +1,155 @@
+# The terminal interface
+
+This page describes what you see on screen and how to move around it: the
+banner, the status line, the working indicator, the panels below the
+editor, the dialogs, and the themes.
+
+## The banner
+
+The session opens with a One Code wordmark, the version, and a live line
+showing the model, the permission mode, and the subagent model. Below it, a
+hint line lists the keys worth knowing:
+
+| Hint | Meaning |
+|---|---|
+| `/hotkeys` | pi's full key list. |
+| `shift+tab` | Cycle reasoning effort. |
+| `ctrl+q` | Cycle the permission mode. |
+| `ctrl+t` | Show or hide thinking blocks. |
+| `ctrl+o` | Expand a collapsed tool output. |
+| `/` | List commands. |
+| `!` | Run a shell command yourself. |
+| `ultracode` | The keyword that turns on workflow orchestration for a turn. |
+
+On a machine with no provider yet, the banner reads `model none` and a
+notice points you at `/login`.
+
+When pi's `quietStartup` setting is on (the bundled app turns it on), the
+startup listing is compact: one line each for the instruction files in
+context, the skills found, the saved workflows, and the themes.
+
+Set `CC_NO_BANNER=1` to keep pi's own header.
+
+## Prompt and transcript markers
+
+Your input line starts with a `❯` marker and the model's replies with a `●`
+bullet, as in Claude Code. Tool calls render as `● Tool(arguments)` with
+the result on an indented `⎿` line. Thinking is collapsed behind
+`✻ Thinking… (ctrl+t to expand)`.
+
+Set `CC_NO_INPUT_MARKER=1` or `CC_NO_ASSISTANT_MARKER=1` to remove either
+marker.
+
+## The working indicator
+
+While the model works, a spinner shows a random verb, the elapsed time, and
+the tokens streamed so far, for example `✳ Cogitating… (12s · ↓ 843 tokens)`.
+The clock runs from the start of the turn until it settles, through retries.
+
+After the turn, a dim `✻ Cooked for 5m 12s` line reports the total time.
+Set `CC_TURN_DURATION=0` to turn it off.
+
+## The status line
+
+The footer replaces pi's status line with One Code's own:
+
+- **Left:** the working directory, the git branch, and the open pull
+  request number for that branch when the GitHub CLI is installed.
+- **Right:** context usage as `used/window (percent)`, the session cost,
+  the cache-hit rate of the latest turn, the model, and the reasoning
+  effort. When ultracode is armed, the effort reads `✦ ultracode`.
+
+The cost is all-in: it includes the main conversation plus every model call
+One Code makes on the side, such as subagents, the auto-mode classifier,
+web-fetch reader calls, and recaps. pi's own footer counts only the main
+conversation. When the line is too narrow, the cache-hit rate goes first,
+then the pull request, then the branch.
+
+Set `CC_FOOTER=0` to keep pi's footer.
+
+## The panel below the editor
+
+One panel below the editor holds the background-shell manager and the
+live subagent tree. It appears when there is something to show and hides
+when there is not.
+
+- Press **↓** from an empty editor to focus it. If background shells exist,
+  the first **↓** lands on the shells chip; a second **↓** moves to the
+  subagent rows. Otherwise the first **↓** lands on the first subagent.
+- In the subagent rows, **↑** and **↓** select, **Enter** opens the
+  selected agent's live transcript, **x** stops it, **ctrl+x** then
+  **ctrl+k** stops every agent, and **Esc** leaves the panel. Typing any
+  other key returns to the editor.
+- Inside a transcript, **↑** and **↓** scroll, **PgUp** and **PgDn** page,
+  **Tab** switches to the next agent, **←** returns to the row list, and
+  **Enter** closes the view.
+
+The panel's own footer names the keys that apply at each stage. Mouse-wheel
+scrolling is deliberately not enabled in the transcript view, because
+turning on mouse reporting would take over the terminal's native scrolling
+and text selection for the whole session.
+
+Details of the shells section are in
+[Background shells](tasks-and-background-work.md#background-shells); the
+subagent view is in [Follow agents live](subagents-and-workflows.md#follow-agents-live).
+
+## The question dialog
+
+When the model asks structured questions with `ask_user_question`, a dialog
+opens with one tab per question and a final Submit tab.
+
+- **←**, **→**, **Tab**, and **shift+Tab** switch questions.
+- **↑** and **↓** move between options. **Enter** selects one; a
+  single-choice question then advances to the next tab.
+- A number key selects that option directly.
+- Multiple-choice questions show checkboxes and a **Next** row to move on.
+- Questions without option previews have an **Other** row for a typed
+  answer. Questions with previews show the preview beside the options and
+  take free text through a notes field, opened with **n**.
+- **Chat about this**, the last row of every question, closes the dialog
+  and tells the model you want to discuss before answering.
+- On the Submit tab, **Enter** submits, or jumps to the first unanswered
+  question. **Esc** cancels; nothing is submitted.
+
+## Approval dialogs
+
+The permission prompt and the plan-approval dialog are described in
+[The approval prompt](permissions-modes-and-auto-mode.md#the-approval-prompt)
+and [Plan mode](permissions-modes-and-auto-mode.md#plan-mode).
+
+## Panels opened by commands
+
+| Command | Panel | Keys |
+|---|---|---|
+| `/agents` | The live subagent panel, focused on the newest agent. | See the preceding section. |
+| `/workflows` | The workflow run viewer. | **↑↓** select, **Enter** open, **Tab** next run, **x** stop, **s** save the script, **Esc** back or close. |
+| `/skills` | The skills panel. | **↑↓** move, **Enter** or **Space** cycle a skill's state, **/** search, **t** sort, **Esc** close. |
+| `/plugins` | The plugin marketplace, with Discover, Installed, Marketplaces, and Errors tabs. | **←→** or **Tab** switch tabs, **Esc** close. Discover: type to search, **Space** install, **Enter** view. Installed (like `/skills`): **Enter**/**Space** toggle, **v** view, **e**/**d** set, **u** uninstall, **f** favorite, **/** search. In a detail view: **Enter**/**Space**/**e**/**d** toggle, **u** uninstall, **i** install, **f** favorite. On Marketplaces: **a** add, **u** update, **d** remove. |
+| `/mcp` | The MCP server manager. | **↑↓** navigate, **Enter** open a server or run an action, a digit picks a numbered action, **Esc** back or close. |
+| `/doctor report` | The setup report. | **↑↓** or **j**/**k** scroll, **Space**/**b** page, **g**/**G** top and end, **f** run the checkup, **Esc** or **q** close. |
+| `/memory` | The instruction and memory file picker. | **↑↓** move, **Enter** open, **Esc** close. |
+| `/effort` | The reasoning-effort slider. | **←→** or **h**/**l** adjust, **Enter** confirm, **Esc** cancel. |
+
+**ctrl+c** closes any panel.
+
+PgUp and PgDn do not reach these panels in full-screen mode, because pi uses
+them for its own scrollback; use the keys the panel's footer names.
+
+## Full-screen mode
+
+The bundled app runs in pi's full-screen mode, on the terminal's alternate
+screen, and restores your terminal when you exit. On a plain pi
+installation full-screen mode is opt-in; see
+[Full-screen mode and themes](configuration.md#full-screen-mode-and-themes).
+
+## Themes
+
+Two themes ship: `onecode` (dark, the bundled app's default) and
+`onecode-light`. Any other pi theme also works. See
+[Full-screen mode and themes](configuration.md#full-screen-mode-and-themes)
+for how to select one.
+
+## Keyboard shortcuts
+
+The full list of One Code and pi shortcuts is in the
+[command and keyboard reference](reference.md#keyboard-shortcuts).