command-code 1.4.1 → 1.4.3

package/dist/bundled/command-code-knowledge/reference/hooks.md

@@ -146,8 +146,10 @@ Hooks are configured under the `hooks` key in `settings.json`. Each event array
 settings.json
 └── hooks
     └── <EventName>
-        └── [ HookDefinition ]       // matcher + list of handlers
-            └── hooks: [ HookEntry ] // type + command + timeout
+        └── [ HookDefinition ]
+            │   matcher: which tools
+            └── hooks: [ HookEntry ]
+                    type · command · timeout
 ```
 
 One `HookDefinition` can own multiple `HookEntry` handlers. They all run for the same matcher, in the order listed.

package/dist/bundled/command-code-knowledge/reference/mcp.md

@@ -158,7 +158,7 @@ To target one source, name it. Each argument maps to that agent only, so pick th
 /import gemini     # Gemini CLI
 ```
 
-It imports MCP servers alongside skills, agents, custom commands, and memory. See [Import](https://commandcode.ai/docs/core-concepts/import).
+It imports MCP servers alongside skills, agents, custom commands, and memory. See [Import](https://commandcode.ai/docs/import).
 
 ---
 
@@ -631,6 +631,6 @@ cmd mcp add-json <name> '{"type":"http","url":"https://..."}'
 ## Next steps
 
 - [CLI Reference](https://commandcode.ai/docs/reference/cli) for all Command Code commands
-- [Slash Commands](https://commandcode.ai/docs/reference/slash-commands) for custom prompts
+- [Slash Commands](./custom-slash-commands.md) for custom prompts
 - [MCP Protocol Specification](https://modelcontextprotocol.io/introduction) for building your own MCP server
 - Join our [Discord community](https://commandcode.ai/discord) for support

package/dist/bundled/command-code-knowledge/reference/memory.md

@@ -1,30 +1,21 @@
-<!-- GENERATED FILE — do not edit. Source: packages/docs/src/app/core-concepts/memory/page.mdx. Regenerate: pnpm generate:knowledge -->
+<!-- GENERATED FILE — do not edit. Source: packages/docs/src/app/memory/page.mdx. Regenerate: pnpm generate:knowledge -->
 
 # Memory
 
-Set custom instructions for Command Code by creating an `AGENTS.md` file. It contains instructions that customize Command Code's behavior for your project.
+Memory is the instructions Command Code carries into every turn without you repeating them — conventions, architecture notes, the commands your project actually uses. It lives in plain markdown files named `AGENTS.md`.
 
 ---
 
-## Initialize
+## Start here
 
-Create a new `AGENTS.md` in your project:
+Create one for your project:
 
 ```bash
 /init
 ```
 
-This creates an `AGENTS.md` file in your project root with a starter template.
+That writes `AGENTS.md` in your project root with a starter template. Edit it like any file, or run `/memory` to pick which memory file to open.
 
-Commit your project's `AGENTS.md` to git.
-
----
-
-## Example
-
-The `/init` command creates a template like this:
-
-**AGENTS.md template**
 ```markdown
 # Memory
 
@@ -45,54 +36,102 @@ Add important architectural decisions and patterns here.
 ## Common Workflows
 
 Document frequently used workflows and commands here.
-
 ```
 
-Customize it for your project.
+Commit your project's `AGENTS.md` to git. It's team-shared context, and changes
+to it deserve review like any other project convention.
 
 ---
 
-## File Locations
+## Where memory files live
 
-Command Code reads `AGENTS.md` from two locations:
+Command Code reads **three tiers**, and every one that exists is loaded — they add up, they don't replace each other.
 
-### Project-level
+| Tier | Location | Use it for |
+| ---- | -------- | ---------- |
+| **User** | `~/.commandcode/AGENTS.md` | Your personal preferences, across every project |
+| **Project** | `<project>/AGENTS.md` or `<project>/.commandcode/AGENTS.md` | Team-shared project instructions — commit this |
+| **Subdirectory** | `<subdir>/AGENTS.md` or `<subdir>/.commandcode/AGENTS.md` | Rules for one package or area of a monorepo |
 
-**Location:** `./AGENTS.md` or `./.commandcode/AGENTS.md`
+They're assembled in that order — user, project, then subdirectory — each block headed by its source path, so the model always knows which file a rule came from. Later blocks are more specific, so a package-level convention naturally reads as a refinement of the project-level one.
 
-Team-shared project instructions. Commit this to Git along with your code.
+Command Code reads `AGENTS.md`, not `CLAUDE.md`. If you're coming from another
+agent, [`/import`](https://commandcode.ai/docs/import) brings your memory files over and
+rewrites references to point at the right filename.
 
-### User-level
+### Project memory
 
-**Location:** `~/.commandcode/AGENTS.md`
+Both `<project>/AGENTS.md` and `<project>/.commandcode/AGENTS.md` are checked, in that order — the **first one that exists** is used, not both. Put it at the repo root if you want it visible; put it in `.commandcode/` if you'd rather keep the root clean.
+
+### Subdirectory memory
+
+Subdirectory memory loads on demand. When you `@`-mention a file (or the agent reads one you referenced), Command Code walks from that file's directory up to the project root and picks up any `AGENTS.md` it finds along the way, **outermost first**, so the nearest file has the last word.
+
+```
+repo/
+├── AGENTS.md          ← always loaded
+└── packages/
+    └── api/
+        ├── AGENTS.md  ← loaded when you mention
+        └── server.ts     a file in this directory
+```
 
-Personal preferences for all your projects.
+Only directories **inside** your project count — a sibling tree that happens to share a path prefix is never pulled in.
 
 ---
 
-## Edit Memory Files
+## Importing other files with `@path`
 
-Edit `AGENTS.md` files:
+Any `@path` reference inside a memory file is replaced with that file's contents, so a memory file can compose rather than duplicate:
 
-```bash
-/memory
+```markdown
+See @README.md for the project overview.
+Our review rules live in @./docs/review-checklist.md.
+Personal shell aliases: @~/.commandcode/shell-notes.md
 ```
 
-Opens a selector to choose which file to edit (project or user).
+- Paths are relative to the file doing the importing; `~/` expands to your home directory; absolute paths work.
+- Imports are **recursive**, up to **5 levels** deep.
+- Each expansion is wrapped with an `# Imported from <path>` header so the source stays visible.
+- References inside code fences or backticks are **left alone**, so documenting `@something` doesn't accidentally import it.
+- A path that doesn't resolve to a readable file is left as plain text rather than failing the turn.
+
+---
+
+## How memory reaches the model
+
+Memory is part of the **system prompt**, not the conversation. That has a few consequences worth knowing:
+
+- **It's re-read every request.** Edit `AGENTS.md` mid-session and the next turn picks it up — no restart needed. `/context` flags the row as *(modified, refreshes next request)* until then.
+- **It survives compaction.** Because it isn't conversation, it's never summarized away. See [Context & Compaction](https://commandcode.ai/docs/context).
+- **It costs tokens on every turn.** `/context` shows exactly how many under the **Memory** row. A memory file that has grown into a wiki is a real, recurring cost — keep it to standing rules, and use `@path` imports for the long-form material so it's only there when it's relevant.
 
 ---
 
-## Commands
+## Reference
+
+### Commands
+
+| Command | Description |
+| ------- | ----------- |
+| `/init` | Create `AGENTS.md` in the project root from a starter template |
+| `/memory` | Open a selector to edit your user or project memory file |
+| `/context` | See what memory is costing in the context window |
+| `/import` | Bring memory files over from another coding agent |
+
+### File paths
 
-| **Command** | **Description** |
-| ----------- | --------------- |
-| `/init`     | Create `AGENTS.md` in project root |
-| `/memory`   | Open file selector to edit `AGENTS.md` |
+| Tier | Path |
+| ---- | ---- |
+| User | `~/.commandcode/AGENTS.md` |
+| Project | `<project>/AGENTS.md`, else `<project>/.commandcode/AGENTS.md` |
+| Subdirectory | `<subdir>/AGENTS.md`, else `<subdir>/.commandcode/AGENTS.md` |
 
 ---
 
-## Next steps
+## See also
 
-* [Skills](./skills.md) for specialized agent capabilities
-* [Slash commands](https://commandcode.ai/docs/reference/slash-commands) for custom prompts
-* Join our [Discord community](https://commandcode.ai/discord) for support
+- [Taste](https://commandcode.ai/docs/taste) — learned style, as opposed to written rules.
+- [Skills](./skills.md) — instructions that load only when a task calls for them.
+- [Context & Compaction](https://commandcode.ai/docs/context) — what memory costs per request.
+- [Import](https://commandcode.ai/docs/import) — bring memory files from another agent.

package/dist/bundled/command-code-knowledge/reference/permissions.md

@@ -313,7 +313,43 @@ Set `permissions.disableBypass` to `"disable"` (or `true`) to make bypass unente
 
 ## How a decision is made
 
-The whole machine. Every tool call runs a fixed order - the order **is** the spec, and tests pin it:
+Every tool call falls through one fixed ladder. First rung that matches wins:
+
+```
+       tool call
+           │
+           ▼
+   1  deny rules ───────────► DENY
+           │                  (even bypass)
+   2  ask rules ────────────► ASK
+           │                  (even bypass)
+   3  outside workspace? ───► ASK to admit
+           │
+   4  plan mode + mutates? ─► DENY
+           │
+   5  taste-dir write ──────► redirect
+           │
+   6  malformed write ──────► DENY
+           │
+   7  read-only? ───────────► ALLOW
+           │                  (every mode)
+   8  rm -rf / ~ $HOME ─────► ASK
+           │                  (even bypass)
+   9  bypass mode? ─────────► ALLOW
+           │
+  10  sensitive write? ─────► ASK
+           │
+  11  allow rules ──────────► ALLOW
+           │
+  12  auto-accept + in ws? ─► ALLOW
+           │
+           ▼
+       ASK   (DENY in dont-ask)
+```
+
+Read that top to bottom and two things fall out. **Deny beats ask beats allow**, in every mode. And `bypass` sits at rung 9 — *after* your rules, the external-directory gate, and the circuit breaker — so `--yolo` skips ordinary prompts and the sensitive-write prompt, but never your explicit rules and never the root/home breaker.
+
+The long form of each rung:
 
 1. **Deny rules** - blocked in every mode, including bypass.
 2. **Ask rules** - always prompt, even under bypass. In `dont-ask` the would-be prompt becomes a deny.
@@ -329,8 +365,6 @@ The whole machine. Every tool call runs a fixed order - the order **is** the spe
 12. **Accept-edits fast path** - in `auto-accept`, file edits and safe filesystem commands inside the workspace run without a prompt. Recursive deletes excluded - they still prompt.
 13. Otherwise, **ask** - and in `dont-ask`, **deny**.
 
-Two consequences. First, **deny beats ask beats allow**, every mode. Second, `bypass` sits *after* the deny/ask rules, the external-dir gate, and the breaker - so `--yolo` skips ordinary prompts and the sensitive-write prompt, but not your explicit rules and not the root/home breaker.
-
   Every policy denial (deny rule, mode gate, malformed input) carries guidance the model can act on, and the turn continues. Only a **human** "no" ends the turn.
 
 ---

package/dist/bundled/command-code-knowledge/reference/plan-mode.md

@@ -1,105 +1,256 @@
-<!-- GENERATED FILE — do not edit. Source: packages/docs/src/app/core-concepts/plan-mode/page.mdx. Regenerate: pnpm generate:knowledge -->
+<!-- GENERATED FILE — do not edit. Source: packages/docs/src/app/plan-mode/page.mdx. Regenerate: pnpm generate:knowledge -->
 
-# Plan Mode and Auto-Accept Mode
+# Plan Mode
 
-Command Code separates reasoning from execution using permission modes:
+Plan mode is where the agent thinks before it touches anything. It explores read-only, writes a plan, and hands it to you in a review surface. You comment, it revises, you approve — then implementation starts.
 
-- **Plan Mode**: Explore and plan without executing file changes
-- **Auto-Accept Mode**: Implement changes without confirmation prompts
+---
+
+## Start here
 
-`Shift + Tab` cycles permission modes rather than toggling between two: `default` to `auto-accept` to `plan` and back to `default`. Launched with `--yolo`, `bypass` joins as a fourth rung (`plan` to `bypass` to `default`).
+```bash
+/plan                      # enter plan mode
+/plan add rate limiting    # enter plan mode and plan that task
+```
 
-Two modes sit off that cycle. `dont-ask` is selected from settings or `--permission-mode dont-ask`, and pressing `Shift + Tab` from it moves to `auto-accept` and rejoins the normal cycle. `bypass` is only reachable by launching with `--yolo`. To jump straight to a mode without cycling, use `/mode` or its shorthands (`/mode:default`, `/mode:auto-accept`, `/mode:plan`).
+Or press `shift+tab` until the banner reads **plan**, or launch with `cmd --plan`.
 
-Once a plan is written, [Plan Review](./plan-review.md) is where you read, comment on, revise, and approve it.
+In plan mode the agent can read files, search, and reason. It **cannot** edit files, run shell commands, or apply patches. When it's done it writes the plan to `~/.commandcode/plans/<name>.md` and opens **plan review** — a GitHub-style reader where one line is always selected, you leave inline comments, and you resolve with a verb:
+
+| Key | Verb |
+| --- | ---- |
+| `ctrl+r` | **Submit review** — send your comments back; the agent revises the plan |
+| `ctrl+a` | **Approve** — start implementing |
+| `esc` | **Cancel** — the plan stays saved; reopen it with `/plans` |
 
 ---
 
-## Plan Mode
+## The permission modes
+
+Plan mode is one rung on the permission-mode cycle. `shift+tab` moves between them: `default` → `auto-accept` → `plan` → back to `default`.
+
+| Mode | File edits | Shell commands | Use it when |
+| ---- | ---------- | -------------- | ----------- |
+| **plan** | Blocked | Blocked | Exploring, designing, reviewing sensitive flows |
+| **default** | Prompt for approval | Prompt for approval | Controlled iteration — the everyday mode |
+| **auto-accept** | Applied directly | Run directly | The approach is clear and you're iterating fast |
+
+Two modes sit off the cycle. `dont-ask` is selected from settings or `--permission-mode dont-ask`, and `shift+tab` from it moves to `auto-accept` and rejoins the normal cycle. `bypass` is only reachable by launching with `--yolo`, which also adds it to the cycle as a fourth rung (`plan` → `bypass` → `default`).
+
+To jump straight to a mode without cycling, use `/mode` or its shorthands: `/mode:default`, `/mode:auto-accept`, `/mode:plan`.
 
-Plan mode helps you with structured thinking. It can:
+**Permissions**
+	Modes are only the baseline. The complete guide covers allow/ask/deny rule
+	syntax, the decision ladder every tool call runs, safety behaviors, and the
+	full mode-by-operation decision table.
 
-- Read your codebase
-- Search files
-- Analyze architecture
-- Discuss tradeoffs
-- Propose implementation plans
+Bypass mode is deliberately **not** reachable through `/mode`. Slash commands
+are agent-invokable, so a mid-session route into bypass would let the model
+disable its own permission prompts.
 
-It **cannot**:
+Command Code creates a [checkpoint](./sessions.md) before modifying files in any mode, so an auto-accept run is always rewindable.
 
-- Modify files
-- Run shell commands
-- Apply patches
+### Picking a mode
 
-We recommend Plan mode to:
+| Situation | Mode |
+| --------- | ---- |
+| New feature with unclear scope | Plan |
+| Debugging a complex issue | Plan |
+| Multi-file refactor | Plan |
+| Security review | Plan |
+| Small bug fix | Auto-accept |
+| Routine refactor | Auto-accept |
+| Running tests and adjusting | Auto-accept |
+| Quick typo fix | Auto-accept |
 
-- Explore unfamiliar codebases
-- Debug complex issues
-- Design multi-file features
-- Evaluate architecture decisions
-- Identify edge cases early
-- Review sensitive or critical flows
+The usual loop: start in **plan**, explore and agree on the approach, approve the plan, let it run in **auto-accept**, rewind with checkpoints if something goes sideways.
 
 ---
 
-## Auto-Accept Mode
+## Plan review
+
+Plan review turns a plan into a first-class, persistent artifact you can read, comment on, revise, and approve — instead of a block of text that scrolls away.
+
+- **One mode: REVIEW.** Read line by line, comment on any line, resolve with a verb. There is no separate "edit mode" — plan edits go through your `$EDITOR`.
+- **Plans persist.** Every plan is saved to `~/.commandcode/plans/` as markdown and indexed, so canceling a review never throws the plan away.
+- **Comments are review artifacts, not plan text.** They live in a sidecar overlay and only reach the agent inside a prompt — they are never written into the plan document.
+- **Review rounds.** When the agent revises a plan, the next round diffs against the last one — changed lines render green so you re-review only what moved.
+- **Deterministic.** A harness backstop guarantees the review is offered even when a weaker model writes a plan and simply stops.
+
+### How it works
+
+```
+  you: "plan a rate limiter"
+             │
+             ▼
+  ┌─────────────────────┐
+  │  PLAN MODE          │  read-only
+  │  explore · design   │  writes <name>.md
+  └──────────┬──────────┘
+             │  exit_plan_mode
+             ▼
+  ┌─────────────────────┐
+  │  PLAN REVIEW        │ ◀───────┐
+  │  read · comment     │         │
+  └──┬───────────────┬──┘         │
+     │               │            │
+     │ ctrl+r        │ ctrl+a     │
+     │ submit        │ approve    │
+     ▼               ▼            │
+  ┌────────────┐  ┌───────────┐   │
+  │ agent      │  │ IMPLEMENT │   │
+  │ revises    │  └───────────┘   │
+  └──────┬─────┘                  │
+         └── another round ────────┘
 
-Auto-Accept mode is for fast implementation and execution.
+  esc  →  plan saved, not-implemented
+          reopen any time with /plans
+```
 
-- Modifies files directly
-- Applies patches without confirmation
-- Executes shell commands
-- Proceeds step-by-step automatically
+Inside the reader one line is always selected, comments pin inline under their line, and the bottom bar holds the review verbs:
 
-We recommend Auto-Accept mode when:
+```
+┌ Plan review · rate-limiter.md · v2 ─┐
+│                                     │
+│   5 ● 1. Add a token-bucket mw.     │
+│       ↳ why not a sliding window?   │
+│   6   2. Store buckets in Redis.    │
+│   7   3. Return 429 + Retry-After.  │
+│                                     │
+│ ─────────────────────────────────── │
+│ REVIEW    1 pending  ·  round 2     │
+│ Submit review (1)      ctrl+r       │
+│ Approve                ctrl+a       │
+│ Cancel                 esc          │
+└─────────────────────────────────────┘
+```
 
-- The approach is already clear
-- You are iterating quickly
-- You trust the implementation path
+`●` marks a commented line and `↳` is your comment pinned beneath it. In a revised round, changed lines render green. The hint row at the very bottom carries the rest: type + enter to comment, `ctrl+n`/`ctrl+p` to jump changes, `?` `x` `!` for quick comments, `ctrl+g` to edit.
 
-Command Code creates **Checkpoints** before modifying files, so you can rewind at any time.
+### Four ways in
 
-Learn how to use [checkpoints](./checkpoints.md) in Command Code.
+All of these open the same surface, scoped to a plan written during the **current session**.
 
----
+1. **Finishing plan mode.** The agent writes the plan and calls `exit_plan_mode`, which opens plan review as the approval surface — the plan *is* the approval prompt. Approving here can also switch you into auto-accept mode so implementation runs without further prompts.
+2. **Asking for it.** Outside plan mode, say *"review plan"* / *"open plan review"*. The agent calls the `plan_review` tool, which opens the panel for the most recent plan file, instead of pasting the plan back as a wall of text.
+3. **`/plan-review`.** Jumps straight into a review of this session's latest plan.
+4. **`/plans`.** Opens the full-screen plan browser — every plan from this session and past sessions, with status badges, comment counts, and search. `/plans <name>` jumps straight into a named plan.
+
+**The automatic backstop.** Some models write a plan file and stop without ever presenting it. When a run ends naturally with a plan that was written but never reviewed (in **default** or **plan** mode), the harness presents the review panel itself. Approving continues the run with an instruction to implement; declining lets the run end so you can steer. Modes that mean "don't interrupt me" — auto-accept, bypass, and dont-ask — skip the backstop.
+
+### Reading and commenting
+
+The reader renders the plan like a document — headings, code, quotes, and tables styled per line. Long lines **wrap** at a comfortable reading width (80 columns when there's room, otherwise 60) rather than truncating.
+
+**Navigating:**
+
+| Key | Action |
+|-----|--------|
+| `↑` / `↓` | Move one line; past the last line drops onto the review verbs |
+| `PgUp` / `PgDn` (`Fn+↑/↓` on Mac) | Page up/down one viewport, like `less` |
+| `Home` / `End` (`Fn+←/→` on Mac) | Jump to the first / last line |
+| `ctrl+n` / `ctrl+p` | Jump between marked lines — your comments, plus changed lines in a revised plan |
 
-## Default Mode
+**Commenting** is Figma-style — start typing on a line and a draft box opens inline, directly under that line, exactly where it will sit once pinned.
 
-Default mode sits between the Plan and Auto-Accept modes.
+| Key | Action |
+|-----|--------|
+| type + `Enter` | Open a draft on the selected line, then pin it |
+| `Enter` on a commented line | Reopen the comment to edit it |
+| empty + `Enter` | Remove the comment |
+| `?` | Quick comment: "Why? Explain the reasoning behind this." |
+| `x` | Quick comment: "Cut this — remove it from the plan." |
+| `!` | Quick comment: "Risky — double-check this before implementing." |
+| `esc` (while drafting) | Discard the draft |
 
-- File edits require confirmation
-- Commands require approval
+Pinned comments show a `●` gutter marker and a `↳ comment` row beneath the line. They're saved to disk with the plan, so they survive closing the reader and even ending the session.
 
-Use the Default mode when you want controlled iteration without fully separating planning and execution.
+**Editing the plan** happens in your editor: `ctrl+g` hands the plan file to `$EDITOR` (or `$VISUAL`) and the reader reloads when you close it.
+
+### Resolving a review
+
+Trigger a verb by chord from anywhere, or arrow onto it and press `Enter`.
+
+| Verb | Chord | What it does |
+|------|-------|--------------|
+| **Submit review** | `ctrl+r` | The agent takes your pending comments, revises the plan, and re-presents it for another round. Only shown when you have pending comments. |
+| **Approve** *(approval surface)* | `ctrl+a` | Executes the plan and begins implementation. |
+| **Execute plan** *(browser surface)* | `ctrl+e` | Executes the plan as written — from the `/plans` browser this is itself an approval. |
+| **Cancel** / **Back** | `esc` | Ends the review. In plan mode the plan stays saved and you keep refining; from the browser it returns to the list. |
+
+If you press Approve with comments still pending, Command Code asks rather than guessing:
+
+```
+Approve  (•) with N comments as notes    ( ) original plan · discard comments
+```
+
+**With comments as notes** sends them as a follow-up user turn — non-blocking notes the agent implements against. **Original plan** approves it clean and drops the comments. `←/→` switches, `Enter` confirms, `esc` backs out.
+
+### Review rounds and versioning
+
+Each time you **Submit review**, Command Code:
+
+1. Snapshots the current plan to `~/.commandcode/plans/versions/<name>-v<N>.md`.
+2. Bumps the plan's version and clears your pending comments (they were all handed to the agent in one prompt).
+3. Lets the agent revise the plan, overwriting the live file.
+
+When the revised plan comes back (version > 1), the reader **diffs it against the previous round's snapshot**. Changed lines render **green**, and the badge line reports `round N · M lines changed` — so a second review means re-reading only what actually moved. `ctrl+n`/`ctrl+p` jump between those changed lines.
 
 ---
 
-## Suggested workflow with modes
+## Where plans live
+
+```
+~/.commandcode/plans/<descriptive-name>.md      ← the plan markdown (written by the agent)
+~/.commandcode/plans/plans-index.json           ← titles, status, comments, versions
+~/.commandcode/plans/versions/<name>-v<N>.md    ← prior review-round snapshots
+```
+
+Every plan carries a status:
 
-1. Start in **Plan Mode**
-2. Explore relevant files
-3. Discuss approach and edge cases
-4. Switch to **Auto-Accept Mode** if you're ready to implement
-5. Rewind with Checkpoints if needed
+- **pending** — written but not yet taken through review.
+- **approved** — you approved it and moved to implementation.
+- **not-implemented** — you canceled the review; the plan is kept for later reading, commenting, and revision.
+
+Because a canceled plan is recorded rather than discarded, planning never feels throwaway — reopen it any time with `/plans`. Writes to `~/.commandcode/plans/*.md` never prompt for permission in any mode, and only `.md` files there get that exemption, so the plans directory can't double as a scratchpad.
 
 ---
 
-## Example use cases for choosing the right mode
+## Reference
+
+### Slash commands
+
+| Command | Description |
+|---------|-------------|
+| `/plan [task]` | Enter plan mode; `/plan <task>` plans that task |
+| `/plans [name]` | Browse, review, and annotate saved plans; bare `/plans` opens the browser |
+| `/plan-review` | Review this session's latest plan |
+| `/mode [default\|auto-accept\|plan]` | Show or switch the permission mode |
+| `/mode:plan` | Switch to plan mode (read-only, no side effects) |
+| `/mode:auto-accept` | Switch to auto-accept mode |
+| `/mode:default` | Switch to default mode |
+
+### CLI flags
+
+| Flag | Description |
+|------|-------------|
+| `--plan` | Start in plan mode |
+| `--auto-accept` | Start in auto-accept mode |
+| `--permission-mode <mode>` | `default`, `plan`, `auto-accept`, or `dont-ask` (legacy `standard` accepted) |
+| `--yolo` | Bypass all permission prompts, and add `bypass` to the `shift+tab` cycle |
+
+### Tools
 
-|            Use Case            | Recommended Mode |
-| ------------------------------ | ---------------- |
-| New feature with unclear scope | Plan             |
-| Debugging complex issue        | Plan             |
-| Multi-file refactor            | Plan             |
-| Security review                | Plan             |
-| Small bug fix                  | Auto-Accept      |
-| Routine refactor               | Auto-Accept      |
-| Running tests and adjusting    | Auto-Accept      |
-| Quick typo fix                 | Auto-Accept      |
+| Tool | Description |
+|------|-------------|
+| `enter_plan_mode` | Switches into plan mode (with your confirmation) for read-only exploration |
+| `exit_plan_mode` | Presents the plan for approval when leaving plan mode. Only valid *in* plan mode |
+| `plan_review` | Opens the review panel on demand *outside* plan mode. Renders as `PLAN(review)` in the feed |
 
 ---
 
-## Next Steps
+## See also
 
-- Use **Plan Mode** to outline a change, then switch to **Auto-Accept** to implement it
-- Join our [Discord community](https://commandcode.ai/discord) for support
+- [Permissions](./permissions.md) — the rule syntax and decision model behind every mode.
+- [Checkpoints](./sessions.md) — rewind after an approved plan is implemented.
+- [Tools](https://commandcode.ai/docs/reference/tools) and [Slash Commands](./custom-slash-commands.md) — the full references.

package/dist/bundled/command-code-knowledge/reference/{checkpoints.md → sessions.md}

@@ -1,4 +1,4 @@
-<!-- GENERATED FILE — do not edit. Source: packages/docs/src/app/core-concepts/checkpoints/page.mdx. Regenerate: pnpm generate:knowledge -->
+<!-- GENERATED FILE — do not edit. Source: packages/docs/src/app/sessions/page.mdx. Regenerate: pnpm generate:knowledge -->
 
 # Sessions & Checkpoints
 
@@ -127,7 +127,27 @@ The model a session was using is stored in its meta and **adopted when you resum
 
 ## Branching
 
-Three commands let one conversation become many.
+Three commands let one conversation become many. They differ in **what comes with you**:
+
+```
+  original session
+    A ── B ── C ── D   ← you are here
+         └─ B' ── C'   ← an older branch
+
+  /fork      whole tree + checkpoints
+             ┌─────────────────────┐
+             │ A ─ B ─ C ─ D       │
+             │     └ B' ─ C'       │  /rewind works
+             └─────────────────────┘
+
+  /clone     active branch only
+             ┌─────────────────────┐
+             │ A ─ B ─ C ─ D       │  /rewind empty
+             └─────────────────────┘
+
+  /tree      no copy — jump anywhere
+             in the tree you already have
+```
 
 ### `/fork [name]` — copy everything
 
@@ -316,6 +336,10 @@ When the conversation approaches the context limit, Command Code compacts histor
 
 ---
 
+**Context & Compaction**
+	What compaction does to the transcript, the tiers and their thresholds,
+	`/compact` and `/compact-mode`, and how to keep context lean.
+
 ## Design decisions
 
 - **One picker, not two.** `/resume` and `/sessions` open the same unified picker rather than separate interactive/print views, so there's one mental model for "where are my sessions."
@@ -361,6 +385,6 @@ When the conversation approaches the context limit, Command Code compacts histor
 ## See also
 
 - [Headless Mode](./headless.md) — resuming and naming sessions from scripts and CI.
-- [Interactive Mode](https://commandcode.ai/docs/core-concepts/interactive-mode) — the full session experience.
-- [Context & Compaction](https://commandcode.ai/docs/core-concepts/context) — how history is summarized as it grows.
+- [Interactive Mode](https://commandcode.ai/docs/interactive-mode) — the full session experience.
+- [Context & Compaction](https://commandcode.ai/docs/context) — how history is summarized as it grows.
 - [Permissions](./permissions.md) — how permission decisions apply as you resume or fork a session.

package/dist/bundled/command-code-knowledge/reference/skills.md

@@ -451,7 +451,7 @@ After editing, the changes are immediately applied and ready to use. No restart
 
 ### Setting up your editor
 
-The `/skills` command uses your `$EDITOR` environment variable to open files. See [setting up your editor](https://commandcode.ai/docs/core-concepts/interactive-mode#setting-up-your-editor) for setup instructions.
+The `/skills` command uses your `$EDITOR` environment variable to open files. See [setting up your editor](https://commandcode.ai/docs/interactive-mode#setting-up-your-editor) for setup instructions.
 
 ---