kash-shell 0.3.17__tar.gz → 0.3.18__tar.gz

{kash_shell-0.3.17 → kash_shell-0.3.18}/.copier-answers.yml

@@ -1,5 +1,5 @@
 # Changes here will be overwritten by Copier. Do not edit manually.
-_commit: v0.2.8
+_commit: v0.2.10
 _src_path: gh:jlevy/simple-modern-uv
 package_author_email: joshua@cal.berkeley.edu
 package_author_name: Joshua Levy

kash_shell-0.3.18/.cursor/rules/general.mdc

@@ -0,0 +1,67 @@
+---
+description: General Guidelines
+globs: 
+alwaysApply: true
+---
+# General Responses
+
+Remember you are a senior engineer and have a serious responsibility to be clear,
+factual, think step by step and be systematic, express expert opinion, and make use of
+the user's attention wisely.
+
+Therefore:
+
+- Be concise. State answers or responses directly, without extra commentary.
+  Or (if it is clear) directly do what is asked.
+
+- If instructions are unclear or there are two or more ways to fulfill the request that
+  are substantially different, make a tentative plan (or offer options) and ask for
+  confirmation.
+
+- If you can think of a much better approach that the user requests, be sure to mention
+  it. It's your responsibility to suggest approaches that lead to better, simpler
+  solutions.
+
+- Give thoughtful opinions on better/worse approaches, but never say "great idea!"
+  or "good job" or other non-essential banter or encouragement.
+  Your job is to give expert opinions and to solve problems, not to motivate the user.
+
+- Avoid gratuitous enthusiasm or generalizations.
+  Use thoughtful comparisons like saying which code is "cleaner" but don't congratulate
+  yourself. Avoid subjective descriptions.
+  For example, don't say "I've meticulously improved the code and it is in great shape!"
+  That is useless generalization.
+  Instead, specifically say what you've done, e.g., "I've added types, including
+  generics, to all the methods in `Foo` and fixed all linter errors."
+
+# General Coding Guidelines
+
+## Using Comments
+
+- Keep all comments concise and clear and suitable for inclusion in final production.
+
+- DO use comments whenever the intent of a given piece of code is subtle or confusing or
+  avoids a bug or is not obvious from the code itself.
+
+- DO NOT repeat in comments what is obvious from the names of functions or variables or
+  types.
+
+- DO NOT include comments that reflect what you did, such as "Added this function" as
+  this is meaningless to anyone reading the code later.
+  (Instead, describe in your message to the user any other contextual information.)
+
+- DO NOT use fancy headings like "===== STEP 1: ... =====" in comments
+
+- DO NOT scatter numbered steps in comments.
+  These are hard to maintain if the code changes.
+  Wrong: "// Step 3: Fetch the data from the cache" Correct: "// Now fetch the data from
+  the cache"
+
+## Using Emojis
+
+- DO NOT use emojis or special unicode characters like ① or • or – or — in comments.
+
+- Use emojis in output if it enhances the clarity and can be done consistently.
+  You may use ✔︎ and ✘ to indicate success and failure, and ∆ and ‼︎ for user-facing
+  warnings and errors, for example, but be sure to do it consistently.
+  But but do not use emojis gratuitously as it clutters the output.

kash_shell-0.3.18/.cursor/rules/python.mdc

@@ -0,0 +1,230 @@
+---
+description: Python Coding Guidelines
+globs: *.py,pyproject.toml
+alwaysApply: false
+---
+# Python Coding Guidelines
+
+These are rules for a modern Python project using uv.
+
+## Python Version
+
+Write for Python 3.11-3.13. Do NOT write code to support earlier versions of Python.
+Always use modern Python practices appropriate for Python 3.11-3.13.
+
+Always use full type annotations, generics, and other modern practices.
+
+## Project Setup and Developer Workflows
+
+- This project has a modern pyproject.toml file and a Makefile.
+  Be sure you read and understand both.
+
+- Use uv for running all code and managing dependencies.
+  Never use direct `pip` or `python` commands.
+
+- Use modern uv commands: `uv sync`, `uv run ...`, etc.
+  Prefer `uv add` over `uv pip install`.
+
+- You may use the following shortcuts
+  ```shell
+  
+  # Install all dependencies:
+  make install
+  
+  # Run linting (with ruff) and type checking (with basedpyright).
+  # Note when you run this, ruff will auto-format and sort imports, resolving any
+  # linter warnings about import ordering:
+  make lint
+  
+  # Run tests:
+  make test
+  
+  # Run uv sync, lint, and test in one command:
+  make
+  ```
+
+- The usual `make test` like standard pytest does not show test output.
+  Run individual tests and see output with `uv run pytest -s some/file.py`.
+
+- Always run `make lint` and `make test` to check your code after changes.
+
+- You must verify there are zero linter warnings/errors or test failures before
+  considering any task complete.
+
+## General Development Practices
+
+- Be sure to resolve the pyright (basedpyright) linter errors as you develop and make
+  changes.
+
+- If type checker errors are hard to resolve, check pyproject.toml to see if they are an
+  excessively pedantic error.
+  In special cases you may consider disabling it globally it in pyproject.toml but you
+  *must ask for confirmation* from the user before doing this.
+
+- Never change an existing comment, pydoc, or a log statement, unless it is directly
+  fixing the issue you are changing, or the user has asked you to clean up the code.
+  Do not drop existing comments when editing code!
+  And do not delete or change logging statements.
+
+## Coding Conventions and Imports
+
+- Always use full, absolute imports for paths.
+  do NOT use `from .module1.module2 import ...`. Such relative paths make it hard to
+  refactor. Use `from toplevel_pkg.module1.modlule2 import ...` instead.
+
+- Be sure to import things like `Callable` and other types from the right modules,
+  remembering that many are now in `collections.abc` or `typing_extensions`. For
+  example: `from collections.abc import Callable, Coroutine`
+
+- Use `typing_extensions` for things like `@override` (you need to use this, and not
+  `typing` since we want to support Python 3.11).
+
+- Add `from __future__ import annotations` on files with types whenever applicable.
+
+- Use pathlib `Path` instead of strings.
+  Use `Path(filename).read_text()` instead of two-line `with open(...)` blocks.
+
+- Use strif's `atomic_output_file` context manager when writing files to ensure output
+  files are written atomically.
+
+- Use `uv add` and `uv sync` as needed to add dependencies.
+
+## Testing
+
+- Don't write one-off test code in extra files or within `if __name__ == "__main__":`
+  blocks. Instead, for simple tests, create simple test functions in the original file
+  below a `## Tests` comment.
+  This keeps the tests clear and close to the code.
+
+- For longer tests `test_somename.py` in the `tests/` directory.
+
+- Then you can run such tests with `uv run python -s src/.../path/to/test`
+
+- Don't add docs to assertions unless it's not obvious what they're checking - the
+  assertion appears in the stack trace.
+  Do NOT write `assert x == 5, "x should be 5"`. Do NOT write `assert x == 5 # Check if
+  x is 5`. That is redundant.
+  Just write `assert x == 5`.
+
+- NEVER write `assert False`. If a test reaches an unexpected branch and must fail
+  explicitly, `raise AssertionError("Explanation")` instead.
+  This is best typical best practice in Python since assertions can be removed with
+  optimization.
+
+- Don't use pytest fixtures like parameterized tests or expected exception decorators
+  unless absolutely necessary in more complex tests.
+  It is often far simpler to use simple assertions and put the checks inside the test.
+  This is preferable because then we want simple tests in original source files but
+  don't want pytest dependencies at runtime.
+
+## Types and Type Annotations
+
+- Use modern union syntax: `str | None` instead of `Optional[str]`, `dict[str]` instead
+  of `Dict[str]`, `list[str]` instead of `List[str]`, etc.
+
+- Never use/import `Optional` for new code.
+
+- Use modern enums like `StrEnum` if appropriate.
+
+- One exception to common practice on enums: If an enum has many values that are
+  strings, and they have a literal value as a string (like in a JSON protocol), it's
+  fine to use lower_snake_case for enum values to match the actual value.
+  This is more readable than LONG_ALL_CAPS_VALUES, and you can simply set the value to
+  be the same as the name for each.
+  For example:
+  ```python
+  class MediaType(Enum):
+    """
+    Media types. For broad categories only, to determine what processing
+    is possible.
+    """
+  
+    text = "text"
+    image = "image"
+    audio = "audio"
+    video = "video"
+    webpage = "webpage"
+    binary = "binary"
+  ```
+
+## Guidelines for Formatting Literal strings
+
+- For multi-line strings NEVER put multi-line strings flush against the left margin.
+  ALWAYS use a `dedent()` function to make it more readable.
+  You may wish to add a `strip()` as well.
+  Example:
+  ```python
+  from textwrap import dedent
+  markdown_content = dedent("""
+      # Title 1
+      Some text.
+      ## Subtitle 1.1
+      More text.
+      """).strip()
+  ```
+
+## Guidelines for Docstrings
+
+- Here is an example of the correct style for docstrings:
+  ```python
+  def check_if_url(
+      text: UnresolvedLocator, only_schemes: list[str] | None = None
+  ) -> ParseResult | None:
+      """
+      Convenience function to check if a string or Path is a URL and if so return
+      the `urlparse.ParseResult`.
+  
+      Also returns false for Paths, so that it's easy to use local paths and URLs
+      (`Locator`s) interchangeably. Can provide `HTTP_ONLY` or `HTTP_OR_FILE` to
+      restrict to only certain schemes.
+      """
+      # Function body
+  
+  def is_url(text: UnresolvedLocator, only_schemes: list[str] | None = None) -> bool:
+      """
+      Check if a string is a URL. For convenience, also returns false for
+      Paths, so that it's easy to use local paths and URLs interchangeably.
+      """
+      return check_if_url(text, only_schemes) is not None
+  ```
+
+- Use concise pydoc strings with triple quotes on their own lines.
+
+- Use `backticks` around variable names and inline code excerpts.
+
+- Use plain fences (```) around code blocks inside of pydocs.
+
+- For classes with many methods, use a concise docstring on the class that explains all
+  the common information, and avoid repeating the same information on every method.
+
+- Docstrings should provide context or as concisely as possible explain "why", not
+  obvious details evident from the class names, function names, parameter names, and
+  type annotations.
+
+- Docstrings *should* mention any key rationale or pitfalls when using the class or
+  function.
+
+- Don't add pydocs that just repeat information obvious from the function, variable
+  names, or concise description.
+  That is silly and obvious and makes the code longer for no reason.
+
+- Do NOT list args and return values if they're obvious.
+  In the above examples, you do not need and `Arguments:` or `Returns:` section, since
+  their meaning as obvious from context.
+  do list these if there are many arguments and their meaning isn't clear.
+  If it returns a less obvious type like a tuple, do explain in the pydoc.
+
+- Exported/public variables, functions, or methods SHOULD have concise docstrings.
+  Internal/local variables, functions, and methods DO NOT need docstrings unless their
+  purpose is not obvious.
+
+## General Clean Coding Practices
+
+- When writing a class DO NOT blindly make delegation methods for consistency.
+  For exmaple DO NOT write methods like this:
+  ```python
+      def reassemble(self) -> str:
+        """Call the original reassemble method."""
+        return self.paragraph.reassemble()
+  ```
+  In general, the user can just call the enclosed objects methods, reducing code bloat.

{kash_shell-0.3.17 → kash_shell-0.3.18}/.github/workflows/ci.yml

@@ -42,7 +42,7 @@ jobs:
         uses: astral-sh/setup-uv@v5
         with:
           # Update this as needed:
-          version: "0.7.3"
+          version: "0.7.11"
           enable-cache: true
           python-version: ${{ matrix.python-version }}
 

{kash_shell-0.3.17 → kash_shell-0.3.18}/.github/workflows/publish.yml

@@ -25,7 +25,7 @@ jobs:
       - name: Install uv (official Astral action)
         uses: astral-sh/setup-uv@v5
         with:
-          version: "0.7.3"
+          version: "0.7.11"
           enable-cache: true
           python-version: "3.12"
 

{kash_shell-0.3.17 → kash_shell-0.3.18}/.gitignore

@@ -1,3 +1,7 @@
+# Generated by Makefile
+CLAUDE.md
+AGENTS.md
+
 # Additions to standard GitHub .gitignore:
 *.bak
 *.orig

kash_shell-0.3.18/Makefile

@@ -0,0 +1,46 @@
+# Makefile for easy development workflows.
+# See development.md for docs.
+# Note GitHub Actions call uv directly, not this Makefile.
+
+.DEFAULT_GOAL := default
+
+.PHONY: default install lint test test-full upgrade build clean agent-rules
+
+default: agent-rules install lint test 
+
+install:
+	uv sync --all-extras --dev
+
+lint:
+	uv run python devtools/lint.py
+
+test:
+	uv run pytest
+
+test-full:
+	ENABLE_TESTS_LLM=1 ENABLE_TESTS_INTEGRATION=1 uv run pytest
+
+upgrade:
+	uv sync --upgrade --all-extras --dev
+
+build:
+	uv build
+
+agent-rules: CLAUDE.md AGENTS.md
+
+# Use .cursor/rules for sources of rules.
+# Create Claude and Codex rules from these.
+CLAUDE.md: .cursor/rules/general.mdc .cursor/rules/python.mdc
+	cat .cursor/rules/general.mdc .cursor/rules/python.mdc > CLAUDE.md
+
+AGENTS.md: .cursor/rules/general.mdc .cursor/rules/python.mdc
+	cat .cursor/rules/general.mdc .cursor/rules/python.mdc > AGENTS.md
+
+clean:
+	-rm -rf dist/
+	-rm -rf *.egg-info/
+	-rm -rf .pytest_cache/
+	-rm -rf .mypy_cache/
+	-rm -rf .venv/
+	-rm -rf CLAUDE.md AGENTS.md
+	-find . -type d -name "__pycache__" -exec rm -rf {} +

{kash_shell-0.3.17 → kash_shell-0.3.18}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: kash-shell
-Version: 0.3.17
+Version: 0.3.18
 Summary: The knowledge agent shell (core)
 Project-URL: Repository, https://github.com/jlevy/kash-shell
 Author-email: Joshua Levy <joshua@cal.berkeley.edu>
@@ -19,7 +19,7 @@ Requires-Python: <4.0,>=3.11
 Requires-Dist: anyio>=4.8.0
 Requires-Dist: audioop-lts>=0.2.1; python_version >= '3.13'
 Requires-Dist: cachetools>=5.5.2
-Requires-Dist: chopdiff>=0.2.1
+Requires-Dist: chopdiff>=0.2.3
 Requires-Dist: clideps>=0.1.4
 Requires-Dist: colour>=0.1.5
 Requires-Dist: cssselect>=1.2.0
@@ -38,6 +38,7 @@ Requires-Dist: litellm>=1.63.11
 Requires-Dist: markdownify>=0.13.1
 Requires-Dist: mcp-proxy>=0.5.0
 Requires-Dist: mcp>=1.6.0
+Requires-Dist: minify-tw-html>=0.1.3
 Requires-Dist: openai>=1.66.3
 Requires-Dist: pandas>=2.2.3
 Requires-Dist: patch-ng>=1.18.1
@@ -83,35 +84,64 @@ src="https://github.com/user-attachments/assets/a5d62ae4-17e6-46bb-a9cb-3b6ec8d8
 > “*Simple should be simple.
 > Complex should be possible.*” —Alan Kay
 
-Kash (“Knowledge Agent SHell”) is an **interactive, AI-native command-line** shell for
-practical knowledge tasks.
+Kash (“Knowledge Agent SHell”) is an experiment in making software tasks more modular,
+exploratory, and flexible using Python and current AI tools.
 
-It's also **a Python library** that lets you convert a simple Python function into a
-command and an MCP tool, so it integrates with other tools like Anthropic Desktop or
-Cursor.
+The philosophy behind kash is similar to Unix shell tools: simple commands that can be
+combined in flexible and powerful ways.
+It operates on "items" such as URLs, files, or Markdown notes within a workspace
+directory.
 
-You can think of it a kind of power-tool for technical users who want to use Python and
-APIs, a kind of hybrid between an AI assistant, a shell, and a developer tool like
-Cursor or Claude Code.
+You can use Kash as an **interactive, AI-native command-line** shell for practical
+knowledge tasks. It's also **a Python library** that lets you convert a simple Python
+function into a command and an MCP tool, so it integrates with other tools like
+Anthropic Desktop or Cursor.
 
-It's my attempt at finding a way to remix, combine, and interactively explore and then
-gradually automate complex tasks by composing AI tools, APIs, and libraries.
+It's new and still has some rough edges, but it's now working well enough it is feeling
+quite powerful. It now serves as a replacement for my usual shell (previously bash or
+zsh). I use it routinely to remix, combine, and interactively explore and then gradually
+automate complex tasks by composing AI tools, APIs, and libraries.
+And last but not least, the same framework lets me build other tools (like
+[textpress](https://github.com/jlevy/textpress)).
 
 And of course, kash can read its own functionality and enhance itself by writing new
 actions.
 
+### Kash Packages
+
+The [kash-shell](https://github.com/jlevy/kash) package is the base package and includes
+the Python framework, a few core utilities, and the Kash command-line shell.
+
+Additional actions for handling more complex tasks like converting documents and
+transcribing, researching, or annotating videos, are in the
+[kash-docs](https://github.com/jlevy/kash-docs) and
+[kash-media](https://github.com/jlevy/kash-docs) packages, all available on PyPI and
+quick to install via uv.
+
 ### Key Concepts
 
-- **Actions:** The core of Kash are **Kash actions**. By decorating a Python function,
-  you can turn it into an action, which makes it more flexible and powerful, able to
-  work with file inputs stored and outputs in a given directory, also called a
-  **workspace**.
+- **Actions:** The core of Kash are **actions**. By decorating a Python function with
+  `@kash_action`, you can turn it into an action, which makes it more flexible and
+  powerful. It can then be used like a command line command as well as a Python function
+  or an MCP tool.
+
+- **Workspaces:** A key element of Kash is that it does most nontrivial work in the
+  context of a **workspace**. A workspace is just a directory of files that have a few
+  conventions to make it easier to maintain context and perform actions.
+  A bit like how Git repos work, it has a `.kash/` directory that holds metadata and
+  cached content. The rest can be anything, but is typically directories of resources
+  (like .docx or .pdf or links to web pages) or content, typically Markdown files with
+  YAML frontmatter. All text files use
+  [frontmatter-format](https://github.com/jlevy/frontmatter-format) so have easy-to-read
+  YAML metadata that includes not just title or description, but also the names of the
+  actions that created it.
 
 - **Compositionality:** An action is composable with other actions simply as a Python
-  function, so complex (like transcribing and annotating a video) actions can be built
-  from simpler actions (like downloading and caching a YouTube video, identifying the
-  speakers in a transcript, etc.). The goal is to reduce the "interstitial complexity"
-  of combining tools, so it's easy for you (or an LLM!) to combine tools in flexible and
+  function, so complex operations (for example, transcribing and annotating a video and
+  publishing it on a website) actions can be built from simpler actions (say downloading
+  and caching a YouTube video, identifying the speakers in a transcript, formatting it
+  as pretty HTML, etc.). The goal is to reduce the "interstitial complexity" of
+  combining tools, so it's easy for you (or an LLM!) to combine tools in flexible and
   powerful ways.
 
 - **Command-line usage:** In addition to using the function in other libraries and
@@ -120,9 +150,6 @@ actions.
   video. In kash you have **smart tab completions**, **Python expressions**, and an **LLM
   assistant** built into the shell.
 
-- **MCP support:** Finally, an action is also an **MCP tool server** so you can use it
-  in any MCP client, like Anthropic Desktop or Cursor.
-
 - **Support for any API:** Kash is tool agnostic and runs locally, on file inputs in
   simple formats, so you own and manage your data and workspaces however you like.
   You can use it with any models or APIs you like, and is already set up to use the APIs
@@ -131,6 +158,9 @@ actions.
   **Perplexity**, **Firecrawl**, **Exa**, and any Python libraries.
   There is also some experimental support for **LlamaIndex** and **ChromaDB**.
 
+- **MCP support:** Finally, an action is also an **MCP tool server** so you can use it
+  in any MCP client, like Anthropic Desktop or Cursor.
+
 ### What Can Kash Do?
 
 You can use kash actions to do deep research, transcribe videos, summarize and organize
@@ -175,9 +205,9 @@ ideas, feedback, or use cases for Kash!
 
 ### Running the Kash Shell
 
-Kash offers a shell environment based on [xonsh](https://xon.sh/) augmented with an LLM
-assistant and a variety of other enhanced commands and customizations.
-If you've used a bash or Python shell before, xonsh is very intuitive.
+Kash offers a shell environment based on [xonsh](https://xon.sh/) augmented with a bunch
+of enhanced commands and customizations.
+If you've used a bash or Python shell before, it should be very intuitive.
 
 Within the kash shell, you get a full environment with all actions and commands.
 You also get intelligent auto-complete, a built-in assistant to help you perform tasks,
@@ -211,30 +241,17 @@ These are for `kash-media` but you can use a `kash-shell` for a more basic setup
    Kash is easiest to use via [**uv**](https://docs.astral.sh/uv/), the new package
    manager for Python. `uv` replaces traditional use of `pyenv`, `pipx`, `poetry`, `pip`,
    etc. Installing `uv` also ensures you get a compatible version of Python.
-
-   If you don't have `uv` installed, a quick way to install it is:
-
+   See [uv's docs](https://docs.astral.sh/uv/getting-started/installation/) for other
+   installation methods and platforms.
+   Usually you just want to run:
    ```shell
    curl -LsSf https://astral.sh/uv/install.sh | sh
    ```
 
-   For macOS, you prefer [brew](https://brew.sh/) you can install or upgrade uv with:
-
-   ```shell
-   brew update
-   brew install uv
-   ```
-   See [uv's docs](https://docs.astral.sh/uv/getting-started/installation/) for other
-   installation methods and platforms.
-
 2. **Install additional command-line tools:**
 
    In addition to Python, it's highly recommended to install a few other dependencies to
-   make more tools and commands work: `ripgrep` (for search), `bat` (for prettier file
-   display), `eza` (a much improved version of `ls`), `hexyl` (a much improved hex
-   viewer), `imagemagick` (for image display in modern terminals), `libmagic` (for file
-   type detection), `ffmpeg` (for audio and video conversions)
-
+   make more tools and commands work.
    For macOS, you can again use brew:
 
    ```shell
@@ -255,22 +272,22 @@ These are for `kash-media` but you can use a `kash-shell` for a more basic setup
 
    For Windows or other platforms, see the uv instructions.
 
+   Kash auto-detects and uses `ripgrep` (for search), `bat` (for prettier file display),
+   `eza` (a much improved version of `ls`), `hexyl` (a much improved hex viewer),
+   `imagemagick` (for image display in modern terminals), `libmagic` (for file type
+   detection), `ffmpeg` (for audio and video conversions)
+
 3. **Install kash or a kash kit:**
 
+   For a more meaningful demo, use an enhanced version of kash that also has various
+   media tools (like yt-dlp and Deepgram support):
+
    ```shell
-   uv tool install kash-media --python=3.13
+   uv tool install kash-media --upgrade --python=3.13
    ```
 
    Other versions of Python should work but 3.13 is recommended.
-   For a setup without the media tools, use `kash-shell` instead.
-
-   If you've installed an older version and want to be sure you have the latest shell,
-   you may want to add `--upgrade --force` to be sure you get the latest version of the
-   kit.
-
-   ```shell
-   uv tool install kash-media --python=3.13 --upgrade --force 
-   ```
+   For a setup without the media tools, just install `kash-shell` instead.
 
 4. **Set up API keys:**
 
@@ -362,25 +379,11 @@ Type `help` for the full documentation.
 The simplest way to illustrate how to use kash is by example.
 You can go through the commands below a few at a time, trying each one.
 
-This is a "real" example that uses a bunch of libraries.
+This is a "real" example that uses ffmpeg and a few other libraries.
 So to get it to work you must install not just the main shell but the kash "media kit"
 with extra dependencies.
-
-You need the following tools:
-
-```shell
-# On MacOS:
-brew install ripgrep bat eza hexyl imagemagick libmagic ffmpeg 
-# On Linux:
-apt install ripgrep bat eza hexyl imagemagick libmagic ffmpeg
-```
-
-Then install the `kash-media`, which includes kash-shell and many other libs like yt-dlp
-for YouTube handling:
-
-```shell
-uv tool install kash-media
-```
+This is discussed in [the installation instructions](#installation-steps).
+If you don't have these already installed, you can add these tools:
 
 Then run `kash` to start.
 
@@ -499,7 +502,7 @@ show_webpage
 show_webpage --help
 
 # And you can actually how this works by looking at its source:
-source_code show_webpage
+show_webpage --show_source
 
 # What if something isn't working right?
 # Sometimes we may want to browse more detailed system logs:
@@ -518,7 +521,7 @@ transcribe_format https://www.youtube.com/watch?v=_8djNYprRDI
 
 # Getting a little fancier, this one adds little paragraph annotations and
 # a nicer summary at the top:
-transcribe_annotate_summarize https://www.youtube.com/watch?v=_8djNYprRDI
+transcribe_annotate https://www.youtube.com/watch?v=_8djNYprRDI
 
 show_webpage
 ```