Learn Github, Gulp and Rust

GitHub fosters a fast, flexible, and collaborative development process that lets you work on your own or with others.

github

Now that we are on Fly.io we'll want to replicate the functionality that Vercel was automatically doing for us by creating and configuring a GitHub Action to deploy our site whenever new commits hit the main branch.

Luckily for us there are a number of pre-defined GitHub actions that we can utilize like `actions/checkout@v3`, `actions/setup-node@v3`, and `superfly/flyctl-actions/setup-flyctl@master`. You'll notice that the first two actions are maintained by GitHub where the last is maintained by Fly.io. 

During this process you will also need to generate a token to verify your deployment to Fly.io and store that in the repository Action secrets.

Create a GitHub Action Configuration to Automatic Deploy an Astro Blog

Next.js is a minimalistic framework for server-rendered React applications.

First thing we'll do is navigate to [Github's Developer Settings](https://github.com/settings/applications/new) to register a new OAuth application.

Here we will set the app name, url, and callback url both for the development environment.

We will copy the Client ID and generate secrets and set them in our `.env`.

Finally we'll generate a `NEXTAUTH_SECRET` with the `openssl` cli tool to generate a random, secure string.

Set up GitHub OAuth for a Next.js 13 Application

Supabase is an open source Firebase alternative. A service to:

- Listen to database changes.
- Query your tables, including filtering, pagination, and deeply nested relationships (like GraphQL).
- Create, update, and delete rows.
- Manage your users and their permissions.
- Interact with your database using a simple UI.

Supabase is not a 1-to-1 mapping of Firebase. Most notably, Supabase uses Postgres rather than a NoSQL store. 

supabase

[Supabase](https://supabase.com) includes multiple authentication strategies. In this lesson, we create a Supabase client to trigger the OAuth authentication flow with GitHub.

Additionally, we discuss the differences between Client and Server Components in the [Next.js App Router](https://nextjs.org/docs/app):

- Client Components: user interactivity
- Server Components: data fetching

Lastly, we create a Route Handler to exchange an authentication code from GitHub for their Supabase session.

## Code Snippets

**Authenticate with GitHub OAuth**

```tsx
await supabase.auth.signInWithOAuth({
  provider: "github",
  options: {
    redirectTo: "http://localhost:3000/auth/callback",
  },
});
```

**Exchange code for Supabase session**

```tsx
await supabase.auth.exchangeCodeForSession(code);
```

## Resources

- [Supabase Auth Helper docs](https://supabase.com/docs/guides/auth/auth-helpers/nextjs)
- [Next.js App Router docs](https://nextjs.org/docs/app)

Authenticate Users with GitHub OAuth using Supabase and Next.js Client Components

[Supabase](https://supabase.com/) includes many ways to authenticate users - Email and password, magic link, mobile OTP etc. In this lesson we implement social login with GitHub by registering a new OAuth Application and providing Supabase with the Client ID and Secret.

## Resources

- [Supabase guide to Login with GitHub](https://supabase.com/docs/guides/auth/social-login/auth-github)

Create an OAuth App with GitHub

Remix is a full stack web framework that focuses on web standards and the server/client model so that you can develop the features your users want and need without being bogged down in over-abstractions. When you get good with Remix, you actually get good at the foundations of web development.

remix

Using a GitHub repo to deploy our application to Vercel, keeps our code and live production site in sync. In this lesson we look at using the [GitHub CLI](https://cli.github.com/) tool to create a public repo, and adding it as a remote origin for our project.

Additionally, we create a new Vercel project from this GitHub repo, add our Supabase environment variables, and deploy. Lastly, we update the Homepage URL in our GitHub OAuth app to be our new Vercel URL, and set our Supabase project's [Authentication Site URL](https://app.supabase.com/project/_/auth/url-configuration) to our new live application URL.

## Extension ideas

- Style the app using Tailwind CSS (or another method of choice)
- Implement the ability for a user to `update` and `delete` their own messages
- Add the option to set a username and display this alongside messages
- Add separate message threads/chat rooms
- Implement private messages/chat rooms

## Resources

- [GitHub CLI](https://cli.github.com/)
- [Vercel docs](https://vercel.com/docs)
- [Deploying Remix app to Vercel](https://vercel.com/guides/deploying-remix-with-vercel)

Deploy a Remix Application to Vercel from a GitHub Repository

Supabase supports [a collection of auth strategies](https://supabase.com/docs/guides/auth) - Email and password, passwordless and OAuth. In this lesson, we look at implementing OAuth with GitHub.

In order to do this, we [create a new GitHub OAuth app](https://github.com/settings/applications/new), and configure Supabase to use its Client ID and Secret. Additionally, we create a `<Login />` component that uses the Supabase client to sign users in and out.

This identifies a problem that we don't have access to the environment variables required to create a Supabase client outside of loaders or actions. Therefore, we pipe through our `SUPABASE_URL` and `SUPABASE_ANON_KEY` from the Loader function, and create a singleton Supabase client, to use across our components.

Lastly, we look at sharing this single instance of Supabase through the Outlet Context and declare types to ensure we have TypeScript helping us out throughout the application.

## Code Snippets

**Expose environment variables from the server**

```tsx
export const loader = async ({}: LoaderArgs) => {
  const env = {
    SUPABASE_URL: process.env.SUPABASE_URL!,
    SUPABASE_ANON_KEY: process.env.SUPABASE_ANON_KEY!,
  };

  return json({ env });
};
```

**Access `env` in component**

```tsx
const { env } = useLoaderData<typeof loader>();
```

**Create a singleton Supabase client**

```tsx
const [supabase] = useState(() =>
  createClient<Database>(env.SUPABASE_URL, env.SUPABASE_ANON_KEY)
);
```

**Share global variables with Outlet Context**

```tsx
<Outlet context={{ supabase }} />
```

**Consuming Outlet Context**

```tsx
const { supabase } = useOutletContext<SupabaseOutletContext>();
```

**Logging in with GitHub**

```tsx
await supabase.auth.signInWithOAuth({
  provider: "github",
});
```

**Logging out**

```tsx
await supabase.auth.signOut();
```

**Entire root component**

```tsx
import { json, LoaderArgs, MetaFunction } from "@remix-run/node";
import {
  Links,
  LiveReload,
  Meta,
  Outlet,
  Scripts,
  ScrollRestoration,
  useLoaderData,
} from "@remix-run/react";
import { createClient, SupabaseClient } from "@supabase/supabase-js";
import { useState } from "react";

import type { Database } from "db_types";

type TypedSupabaseClient = SupabaseClient<Database>;

export type SupabaseOutletContext = {
  supabase: TypedSupabaseClient;
};

export const meta: MetaFunction = () => ({
  charset: "utf-8",
  title: "New Remix App",
  viewport: "width=device-width,initial-scale=1",
});

export const loader = async ({}: LoaderArgs) => {
  const env = {
    SUPABASE_URL: process.env.SUPABASE_URL!,
    SUPABASE_ANON_KEY: process.env.SUPABASE_ANON_KEY!,
  };

  return json({ env });
};

export default function App() {
  const { env } = useLoaderData<typeof loader>();

  const [supabase] = useState(() =>
    createClient<Database>(env.SUPABASE_URL, env.SUPABASE_ANON_KEY)
  );
  return (
    <html lang="en">
      <head>
        <Meta />
        <Links />
      </head>
      <body>
        <Outlet context={{ supabase }} />
        <ScrollRestoration />
        <Scripts />
        <LiveReload />
      </body>
    </html>
  );
}
```

## Resources

- [Supabase docs - login with GitHub](https://supabase.com/docs/guides/auth/auth-github)
- [Remix docs - Outlet Context](https://remix.run/docs/en/v1/api/remix#useoutletcontext)

Implement Authentication for Supabase with OAuth and Github

In this lesson we look at why you would need to generate snapshots on your CI server. We follow this up by creating a simple Github Action that will generate new snapshots against a pull request once you leave a specially formatted "slash command" style comment.

Generate Playwright Snapshots on your CI Server

“a11y” stands for “accessibility.” It is a numeronym, with 11 representing the count of letters between the letter a and the letter y.

Accessibility is broken down into 4 categories of disability: visual, cognitive, auditory, motor. 

Regardless of the category of disability, accessibilities aim in web development is to make applications and websites usable for everyone.

a11y

To automate running Lighthouse audits on our application we can add the use of the Lighthouse CI tool to our Continuous Integration suite using GitHub Actions.  By making use of the Lighthouse CI GitHub App we can add to the checks in every Pull Request a report with the score from the audit run on each URL we configure for Lighthouse to audit.

## Resources
* https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md
* https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md
* https://github.com/apps/lighthouse-ci

Automate Lighthouse Audits with GitHub Actions

The pluggable linting utility for JavaScript and JSX.

eslint

We can leverage GitHub Actions to automate the running of all of our accessibility auditing tools as part of a Continuous Integration (CI) workflow. 

Auditing tools will only catch a percentage of potential accessibility issues, it is no replacement for manual testing.  But being able to automate the auditing will add efficiencies to our testing and provide an early warning system that can be run much more frequently than it’s practical to perform manual testing.  Additionally, we can use our CI suite as a safety net to prevent code changes that break accessibility from being able to be merged.

## Resources
* https://app.egghead.io/lessons/react-set-up-eslint-to-audit-accessibility-issues-in-react
* https://docs.cypress.io/guides/continuous-integration/github-actions#Basic-Setup
* https://github.com/cypress-io/github-action

Automate Accessibility Audits with GitHub Actions

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

This course builds off a react-based shopping cart application containing a list of products (loaded dynamically from a JSON file). It is fully self-sustaining and does not rely on any third party APIs. It uses [vite](https://vitejs.dev/) as the underlying bundler and development tool with [react-ts](https://vitejs.dev/guide/#scaffolding-your-first-vite-project) preset.

To get started simply follow the these instructions:

```
git clone git@github.com:xjamundx/redux-shopping-cart.git
cd redux-shopping-cart
git checkout egghead
npm install
npm run dev
open http://localhost:3000
```

**Note** This course uses a shopping cart application to demonstrate redux principles. It is not meant to demonstrate anything about making actual financial transactions over the web.

Setup and Explore our Shopping Cart Application to Learn Redux with TypeScript

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Getting started with contributing to open source projects can be very confusing and stressful. This talk will help clear away the confusion and pinpoint why and how you can make your first open source contribution. 



How to Make Your First Open Source Contribution

Get a client ID and Secret from GitHub by registering a new OAuth Application. You can register a new OAuth Application on Github [here](https://github.com/settings/applications/new)

Make sure to keep the secret you generated safe. It's the key to your data.

Get a GitHub client ID and Secret for an OAuth Application

 Every developer who has attempted to demystify OAuth 2.0 must be presented with mind-bugging complicated flow diagrams. It becomes worse when you try to understand all the terminologies of OAuth 2.0 and Open ID protocols.

There is no getting around the OAuth 2.0 flow being complicated with back and forth between your browser, the service you are authenticating with, and the application you want to access. 

This course gets straight to the point without any application code distracting you from the core takeaway -- You will learn how to authenticate and authorize yourself using GitHub as your Auth Server.

We'll first cover the OAuth 2.0 flow for authentication and then integrate the Open ID protocol for authorization.

[**LIVE EVENT**: Register here for a live webinar with Christian on OAuth.](https://egghead.zoom.us/webinar/register/WN_Sxy1FEcoTea8UA6F7EDzLw) Bring any questions you have from taking this course!

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

Add Github Login to Your Web App with OAuth 2.0

DevOps goals have stayed the same over the year, but our tools, infrastructure, and operating models have changed. To support modern software delivery, organizations must establish and share proven developer workflows.

This talk will cover how existing projects are using GitHub Action to hope that all projects, despite their size, can benefit collectively from knowledge sharing. The benefit of Actions is that the majority are shareable and open source. Plan to leave this talk with ideas on how you can automate new portions of your software development pipeline for production.

GitHub Action Traction

In this course, Chris takes a README-driven approach to build out a Rust CLI that supports content authoring for a digital garden.

Specifically, you'll work through the first command for the CLI, writing files. You start by initializing a new Cargo binary crate through creating the `write` command that allows you to create files (and their contents) to the folder that you set. 

Step by step you'll learn about:
- Handling user input
- Error handling
- Rust Move semantics
- Rust Copy semantics
- Integration testing

...and more!

Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

rust

Creating a Digital Garden CLI with Rust

While we have `test_write_with_title`
which tests the garden CLI with a given
title flag, we can also set up additional
tests, such as for using a written title
in the document for the filename.

Copy/pasting the code from test one into
test two is a lot of duplication, and
setting up the fake editor isn't going
to change across tests, so let's abstract
the creation of the temporary directory,
the fake editor script path, and the
`Command` itself into a utility function.

The port is relatively straightforward,
with the only changes being that we cut
off the `cmd` modifications before the
`.arg` calls, and now have to return
the `cmd` and the `temp_dir` in a tuple.

We return the actual `Command` and `TempDir`,
yielding ownership to the calling function
because we have no further use for them here,
but the calling function will need to mutate
the `Command` more, and use `TempDir` to test.

```rust
fn setup_command() -> (Command, assert_fs::TempDir) {
    let temp_dir = assert_fs::TempDir::new().unwrap();

    let mut cmd = Command::cargo_bin("garden").unwrap();
    let fake_editor_path = std::env::current_dir()
        .expect("expect to be in a dir")
        .join("tests")
        .join("fake-editor.sh");
    if !fake_editor_path.exists() {
        panic!(
            "fake editor shell script could not be found"
        )
    }

    cmd.env("EDITOR", fake_editor_path.into_os_string())
        .env("GARDEN_PATH", temp_dir.path());
    (cmd, temp_dir)
}
```

The new write tests are considerably shorter
now and focus mostly on which subcommand to
call, and what the user interaction with that
subcommand is.

```rust

fn test_write_with_title() {
    let (mut cmd, temp_dir) = setup_command();
    let assert = cmd
        .arg("write")
        .arg("-t")
        .arg("atitle")
        .write_stdin("N\n".as_bytes())
        .assert();

    assert.success();

    temp_dir
        .child("atitle.md")
        .assert(predicate::path::exists());
}

fn test_write_with_written_title() {
    let (mut cmd, temp_dir) = setup_command();
    let assert = cmd
        .arg("write")
        .write_stdin("N\n".as_bytes())
        .assert();

    assert.success();

    temp_dir
        .child("testing.md")
        .assert(predicate::path::exists());
}
```

Abstracting test utilities inside integration test files

We can print lines to the terminal and
ask the user for various input. So let's
make the interface a bit more usable by
using colored output.

We can do this by bringing an extension
trait for formatting into scope:
`OwoColorize`.

Extension traits are one-off traits that
are used to add functions to a type that
our crate doesn't own. A crate can create
the new trait, then implement the
functions defined by that trait on a type
the crate doesn't own and if we bring that
trait into scope, the type will get the
extra functions. In this case, `OwoColorize`
is used for adding color functions to
formatters like Display and Debug.

We'll start with `ask_for_filename`

```rust
use color_eyre::owo_colors::OwoColorize;

fn ask_for_filename() -> Result<String> {
    rprompt::prompt_reply_stderr(&format!(
        "{}",
        "\
Enter filename
> "
        .blue()
        .bold(),
    ))
    .wrap_err("Failed to get filename")
    .map(|title| slug::slugify(title))
}
```

In `confirm_filename` we can use multiple
formatters to get different colors:

```rust
let result = rprompt::prompt_reply_stderr(&format!(
    "\
{} {}
Do you want a different title? (y/N): ",
    "current title:".green().bold(),
    raw_title,
))
.wrap_err("Failed to get input for y/n question")?;
```

Using owo_colors Extension Traits to colorize terminal output

`PathBuf` lets us check to see if a file
exists before writing to it, so we can
take advantage of that to make sure that
we don't overwrite a file that already
exists, even if the user has indicated
a title that would overwrite another file.

```
let mut i: usize = 0;
loop {
    let dest_filename = format!(
        "{}{}",
        filename,
        if i == 0 {
            "".to_string()
        } else {
            i.to_string()
        }
    );
    let mut dest = garden_path.join(dest_filename);
    dest.set_extension("md");
    if dest.exists() {
        i = i + 1;
    } else {
        fs::rename(garden_tmpfile, &dest)?;
        break;
    }
}
```

Checking for file existence with PathBuf to ensure unique filenames

We have been ignoring implementing tests for the write subcommand. Now is the time that we'll test the command we have been building.

We'll build out a fake editor script that our test will use to check if the command is functioning properly. We will then use `arg` to build the command as we would normally use it ourselves.

After writing the test, we'll see how to clean up after ourselves so that we aren't leaving testing artifacts leftover just from running a test.

---

How to integration test a cargo binary that calls
out to `EDITOR` for modifications and asks the
user for input.

First we'll create a fake editor script to use
instead of vim, etc.

`tests/fake_editor.sh` is a one-liner.

```shell
echo "testing" >> $1;
```

Then we'll write our test using `assert_cmd` to
build up a `Command` that points to the `garden`
binary in out `Cargo.toml`.

We grab the fake editor path script using
`std::env::current_dir()`, make sure the file
exists (which means we've grabbed the right
path), and spawn a new `Command` with the
`EDITOR` variable set to the fake editor
script. The equivalent call to our bin is

```shell
EDITOR=path/to/fake-editor.sh garden write -t atitle
```

And the rust code to execute.

```rust
fn test_write_with_title() {
    let mut cmd = Command::cargo_bin("garden").unwrap();
    let fake_editor_path = std::env::current_dir()
        .expect("expect to be in a dir")
        .join("tests")
        .join("fake-editor.sh");
    if !fake_editor_path.exists() {
        panic!(
            "fake editor shell script could not be found"
        )
    }

    let assert = cmd
        .env("EDITOR", fake_editor_path.into_os_string())
        .arg("write")
        .arg("-t")
        .arg("atitle")
        .write_stdin("N\n".as_bytes())
        .assert();

    assert.success();
}
```

Note that we're asserting that the command
exited sucessfully, and that we're inputing
`N\n` to the bin's stdin, which responds to
a request for user input after the editor
closes.

Note that this doesn't actually test for
the resulting file existence, and also that
we're writing our files out directly into
our default digital garden! We can solve
this with `assert_fs` and `predicates`.

We'll bring in both preludes (a prelude is
a bunch of stuff the library author thinks
will be useful to have around all the time)
and create a new temporary directory.

We'll use the `GARDEN_PATH` environment
variable to pass the temporary directory in
to the `garden` bin and that's it, we've
added a temporary directory to our test.
No more polluting the default garden!

```rust
use assert_fs::prelude::*;
use predicates::prelude::*;

fn test_write_with_title() {
    let temp_dir = assert_fs::TempDir::new().unwrap();

    let mut cmd = Command::cargo_bin("garden").unwrap();
    let fake_editor_path = std::env::current_dir()
        .expect("expect to be in a dir")
        .join("tests")
        .join("fake-editor.sh");
    if !fake_editor_path.exists() {
        panic!(
            "fake editor shell script could not be found"
        )
    }

    let assert = cmd
        .env("EDITOR", fake_editor_path.into_os_string())
        .env("GARDEN_PATH", temp_dir.path())
        .arg("write")
        .arg("-t")
        .arg("atitle")
        .write_stdin("N\n".as_bytes())
        .assert();

    assert.success();

    temp_dir
        .child("atitle.md")
        .assert(predicate::path::exists());
}
```

Now that's enough, but we can also check
to make sure the file we expect to exist
actually exists. `temp_dir.child` gives
us the possible file, and we can assert
on that file with a test from `predicates`
that tests to make sure the file exists.

```rust
temp_dir
    .child("atitle.md")
    .assert(predicate::path::exists());
```

Using assert_fs and predicates to integration test with a real temporary file system

What user experience do we want for the
act of writing?

We have a few options, including letting
users write directly in the console or giving
them a prepared file that they can then open
and write in.

Writing directly in the console doesn't give
a user access to their text editor of choice.
Which means lacking autocomplete, syntax
highlighting, snippets, and other functionality.

Creating a file and handling the path back to
the user doesn't quite work for us either, as
that reduces the utility of the garden write
command to the equivalent of running `touch
filename.md`.

So for our use case, we'd ideally like to open
the user's preferred editing environment,
whatever that happens to be, then wait for them
to be done with the file before continuing.

Since we're working with a CLI tool, we
can safely assume that our users either
know how to, or are willingly to learn how
to, set environment variables. This means we
can use the `EDITOR` variable to select an
editor to use. This is the same way `git commit`
works.

---

In Rust, there is a crate that handles not only
`EDITOR`, but also various fallbacks per-platform.
We'll take advantage of [edit](https://crates.io/crates/edit)
to call out to the user's choice of editor.

The quick usage of edit allows us to call the
`edit::edit` function, and get the user's data.

```rust
pub fn write(garden_path: PathBuf, title: Option<String>) -> Result<()> {
    dbg!(garden_path, title);
    let template = "# ";
    let content_from_user = edit::edit(template).wrap_err("unable to read writing")?;
    dbg!(content_from_user);
    todo!()
}
```

This results in a filename that looks like:
`.tmpBy0Yun` "somewhere else" on the filesystem,
in a location the user would never reasonably
find it. Ideally, if anything went wrong, the
user would be able to take a look at the
in-progress tempfile they were just working on,
which should be in an easily discoverable place
like the garden path.

*We don't want to lose a user's work.*

Additionally, the tempfile doesn't have a file
extension, which means that the user's editor
will be less likely to recognize it as a
markdown file, so we want to add `.md` to the
filepath.

```rust
use color_eyre::{eyre::WrapErr, Result};
use edit::{edit_file, Builder};
use std::io::{Read, Write};
use std::path::PathBuf;

const TEMPLATE: &[u8; 2] = b"# ";

pub fn write(garden_path: PathBuf, title: Option<String>) -> Result<()> {
    let (mut file, filepath) = Builder::new()
        .suffix(".md")
        .rand_bytes(5)
        .tempfile_in(&garden_path)
        .wrap_err("Failed to create wip file")?
        .keep()
        .wrap_err("Failed to keep tempfile")?;
    file.write_all(TEMPLATE)?;
    // let the user write whatever they want in their favorite editor
    // before returning to the cli and finishing up
    edit_file(filepath)?;
    // Read the user's changes back from the file into a string
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;

    dbg!(contents);
    todo!()
}
```

We will use the `edit::Builder` API to generate
a random tempfile to let the user write content
into. The suffix is going to be `.md` and the
filename will be 5 random bytes. We also put
the tempfile in the garden path, which ensures
a user will be able to find it if necessary.

`wrap_err` (which requires the `eyre::WrapErr`
trait in scope) wraps the potential error
resulting from these calls with additional context,
making the original error the source, and we can
keep chaining after that. We `keep` the tempfile,
which would otherwise be deleted when all handles
closed, because if anything goes wrong after the
user inputs data, we want to make sure we don't
lose that data.

After the file is created, we write our template
out to the file before passing control to the
user. This requires the `std::io::Write` trait
in scope. We use a const for the file template
because it won't change. To make the `TEMPLATE`
a const, we also need to give it a type, which
is a two element byte array. Change the string
to see how the byte array length is checked at
compile time.

Since we have access to the `file` already, we
can read the contents back into a string after
the user is done editing. This requires having
the `std::io::Read` trait in scope.

And now we've let the user write into a file
which will stick around as long as we need it
to, and importantly will stick around if any
errors happen in the execution of the program,
so we lose no user data and can remove the
temporary file at the end of the program
ourselves if all goes well.

Passing control to the user's favorite editor (such as VSCode) from the CLI

Given the potential `document_title` we now
want to ask the user if the title is still
what they want to use so that we can write
the file to disk. This will involve two
paths depending on if we have an existing
potential option or not.

We will need to use `ask_for_filename` in
`confirm_filename`, so we'll write that branch
first.

```rust
let filename = match document_title {
    Some(raw_title) => {
        // confirm_filename()?
        todo!()
    }
    None => ask_for_filename(),
};
```

`rprompt` allows us to ask for a small amount
of input from the user (compared to the  much
larger input possible by passing control to
the user's editor).

We'll use `rprompt::prompt_reply_stderr` to
get a response from the user, and `.wrap_err`
to add context to the error if anything goes
wrong.

```rust
fn ask_for_filename() -> Result<String> {
    rprompt::prompt_reply_stderr(
        "\
Enter filename
> ",
    )
    .wrap_err("Failed to get filename")
}
```

We'll use the same behavior for the first
part of `confirm_filename`. We'll also
need to use our first lifetime to account
for the shared reference argument.

`match` can match against multiple values
for the same branch, so we'll take advantage
of that to handle branches for Ns and Ys, as
well as the default case. If anything goes
wrong, such as someone inputting an "a",
we'll fall through using `loop` and ask again
until we get a usable answer

```rust
fn confirm_filename(raw_title: &str) -> Result<String> {
    loop {
        // prompt defaults to uppercase character in question
        // this is a convention, not a requirement enforced by
        // the code
        let result = rprompt::prompt_reply_stderr(&format!(
            "\
current title: `{}`
Do you want a different title? (y/N): ",
            raw_title,
        ))
        .wrap_err("Failed to get input for y/n question")?;

        match result.as_str() {
            "y" | "Y" => break ask_for_filename(),
            "n" | "N" | "" => {
                // the capital N in the prompt means "default",
                // so we handle "" as input here
                break Ok(slug::slugify(raw_title));
            }
            _ => {
                // ask again because something went wrong
            }
        };
    }
}
```

While filenames can technically have spaces
in them, we're going to slugify our filenames
like urls for a few reasons. One is that
when starting out, many programmers fail to
quote filename arguments in their bash scripts,
which results in filenames with spaces being
treated as separate arguments. Another is
that this is a digital garden CLI, and
digital gardens are often stored in git,
accessed from multiple file systems, as well
as from URLs. While strictly speaking we don't
need to slugify our filenames, we will here
so as to adhere to a safer set of characters.

```
cargo add slug
```

We'll map over the `Result` from `rprompt`
which allows us to operate on the internal
value if it's `Ok`.

```rust
fn ask_for_filename() -> Result<String> {
    rprompt::prompt_reply_stderr(
        "\
Enter filename
> ",
    )
    .wrap_err("Failed to get filename")
    .map(|title| slug::slugify(title))
}
```

We'll also use slugify in `confirm_filename`

```rust
match result.as_str() {
    "y" | "Y" => break ask_for_filename(),
    "n" | "N" | "" => {
        // the capital N in the prompt means "default",
        // so we handle "" as input here
        break Ok(slug::slugify(raw_title));
    }
    _ => {
        // ask again because something went wrong
    }
};
```

The fact that `confirm_filename` and
`ask_for_filename` have the same return type
is important because the branches of a `match`
need to return the same type.

Prompting the user for input with rprompt and loop

Establish an automated, AI-driven workflow for implementing UI designs by comparing live development versions against target screenshots. This lesson integrates the Playwright MCP server for browser automation, a custom script using Pixelmatch for visual diffing, and Cursor Rules for persistent context. See how to instruct the Cursor Agent to iteratively implement design changes based on visual diff feedback, creating a robust loop where the AI refines the UI towards the target design.

**Workflow demonstrated in this lesson:**

*   Configure the Playwright MCP server within Cursor for browser control.
*   Use the Agent and Playwright MCP tools (`browser_navigate`, `browser_resize`, `browser_take_screenshot`) to capture baseline and current state PNG screenshots.
*   Install `pixelmatch` and `pngjs` dependencies.
*   Guide the Agent to create and run a TypeScript script (`compare-images.ts`) to generate visual diff images between screenshots.
*   Establish Cursor Rules (`visual-testing.mdc`, `project-setup.mdc`, etc.) to provide the Agent with necessary context about directories, scripts, dependencies, and the overall workflow.
*   Initiate an AI-driven design implementation loop:
    *   Agent captures the current state via Playwright.
    *   Agent runs the comparison script to get a visual diff.
    *   Agent analyzes the diff and implements code changes in the project (e.g., `app/page.tsx`, components, `globals.css`).
    *   Repeat the capture-compare-implement cycle, using the latest diff as feedback.
*   Use context files and prompts like "Please continue" to manage the multi-step process and guide the AI through potential interruptions.

**Key benefits:**

*   Creates an iterative, AI-driven workflow for implementing designs based on visual comparisons.
*   Combines browser automation (Playwright) and pixel-level diffing (Pixelmatch) within the Cursor environment.
*   Utilizes Cursor Rules to effectively manage context and guide the AI through complex, multi-step tasks.
*   Demonstrates how visual diffs can serve as direct feedback for AI-driven UI code generation and refinement.

John Lindquist

AI-Driven Design Workflow: Playwright MCP Screenshots, Visual Diffs, and Cursor Rules

[Scraped MCP Examples](https://gist.github.com/johnlindquist/b19673bbf6a396406dff869beecace1d)
[ghx tool](https://www.npmjs.com/package/@johnlindquist/ghx)

Building complex components like Model Context Protocol (MCP) servers from scratch can be challenging, especially without good reference implementations. This lesson demonstrates a powerful workflow combining the `ghx` CLI tool with AI assistants (like Google's AI Studio and Cursor's agent) to overcome this hurdle.

You'll learn how to:

1.  **Use `ghx`:** Leverage the `ghx` command-line tool (which wraps the GitHub CLI) to search GitHub for real-world code examples based on specific import paths (e.g., `modelcontextprotocol/sdk/server/mcp.js`).
2.  **Refine Search Results:** Use `ghx` options (`--help`, `--limit`, `--max-filename`, `NOT demo`) within Cursor's chat to filter results, exclude simple demos, and gather a rich set of relevant MCP server implementations.
3.  **Provide AI Context:** Copy the aggregated code examples found by `ghx` into an AI environment like Google AI Studio (or ChatGPT).
4.  **Handle Context Limits:** See techniques for trimming large context files (like using Cursor's `Cmd+K` inline edit with `head -n` commands) to fit within model limits while retaining valuable examples.
5.  **Generate Code:** Prompt the AI (Gemini 2.5 Pro in AI Studio or ChatGPT O3) to generate a *new* MCP server (e.g., with five distinct tools) based *solely* on the provided real-world examples.
6.  **Integrate and Debug:** Set up the generated TypeScript code (`mcp_server.ts`) locally in Cursor, install dependencies (`pnpm install`), and use Cursor's agent (`Cmd+I`) or inline fixes (`Cmd+K`) to resolve TypeScript errors and path issues.
7.  **Configure in Cursor:** Add the newly created MCP server (running via `bun mcp_server.ts`) to Cursor's MCP settings, using the absolute path and the `bun` command.
8.  **Test the MCP Server:** Interact with Cursor's chat agent to call the custom tools (e.g., `add_note`, `list_notes`, `write_managed_file`) defined in the AI-generated MCP server, verifying its functionality.

This lesson showcases how combining targeted code searching (`ghx`) with the generative power of AI, fueled by relevant examples, can dramatically accelerate the process of building and bootstrapping complex tools and applications.

Generate and Debug MCP Servers from Scratch

Hey Everyone 👋,

John Lindquist here with the second issue of AI Dev Essentials! It's been another busy week in the AI tooling world. The biggest splash was probably GPT-4.1 hitting the streets, but there's plenty more action around MCP, Vercel's v0, Google's developer tools, and interesting community discussions. I've spent some time with GPT-4.1 already (specifically in Cursor), and while it shows promise, it didn't quite convince me to switch from Gemini 2.5 Pro yet. It stumbled on a few basic requests where Gemini usually shines on the first attempt.

---

### New egghead.io Lesson This Week:

* **[Create a Custom MCP that Calls Cursor Tools](https://egghead.io/create-a-custom-mcp-that-calls-cursor-tools~r77sw):** Learn how to build custom MCP server tools that allow Cursor's AI Agent to access your local project context. This lesson shows how to use Zod schemas and the crucial `.describe()` method to explicitly request information (like Git status or version) from the Cursor environment *before* your tool runs, enabling powerful, context-aware automation.

---

Here are the highlights that caught my eye this past week.

## Model Mania: GPT-4.1 Arrives, Plus Grok & Llama Updates

* **GPT-4.1 Lands:** OpenAI announced GPT-4.1, and it quickly became available via the [API](https://openai.com/live/) and showed up in [Cursor](https://x.com/cursor_ai/status/1911835651810738406). Cursor is offering it free for now to let users get a feel for it, though they don't recommend it as a default just yet. Curious to hear initial impressions from folks testing it out for coding tasks.

* **Grok 3 in Cursor:** Following other model additions, [Cursor also enabled Grok 3 models](https://x.com/amanrsanger/status/1910434915419906141), with the mini version available for free users. Aman Sanger noted it seems to "think upfront more than other models."

* **Community Hack: Llama 4.0 via Groq in Cursor:** Levi Dan shared a [detailed (and slightly hacky) guide](https://x.com/lxvi_brg/status/1908865544721154455) on how to wire up Groq's fast Llama 4.0 API into Cursor by using the OpenAI API key slot and intercepting requests. A clever workaround for the adventurous!

## Tooling & Platform Pulse

Lots of movement across different platforms and tools this week:

* **Vercel Ecosystem:**

  * Guillermo Rauch teased [v0 coming to VS Code](https://x.com/rauchg/status/1911524154458984515), hinting at tighter integration for the UI generation tool.

  * v0 also [added AI integrations](https://x.com/v0/status/1911912183149256943) with models from xai (Grok), FAL, Groq, and DeepInfra, including automatic API key setup and pay-as-you-go billing via Vercel Marketplace. They're offering a $10 credit for the Grok free tier.

  * Vercel shared insights on the [grep.app migration from CRA to Next.js](http://grep.app/), showcasing performance improvements. ([Source](https://x.com/rauchg/status/1911920410020757881)) I'm personally excited about this one – I rely heavily on examples when working with AI, and for me, a good example is often worth ten prompts. Tools like `grep.app` that make code discovery easier are invaluable.

* **Google's Growing Stack:**

  * Project IDX has officially become [Firebase Studio](https://x.com/_davideast/status/1909990728593453455), positioning itself as a cloud-based, agentic dev environment for full-stack AI apps, deeply integrated with Firebase. I've tried spinning up a few sites with it, and the speed is impressive. However, for more complex tasks like designing from images or intricate interactions, I still find myself leaning towards v0 for now.

  * Google quietly released the [Agent Development Kit (ADK)](https://x.com/omarsar0/status/1910004370864742757), a Python library (`pip install google-adk`) for building multi-agent systems with features like state management, tool usage, and orchestration. I haven't had a chance to dive into this yet, but it's right at the top of my list. Building robust agent systems is a huge area of interest, so this is probably the announcement I'm most excited about exploring this week.

  * Ramón Medrano Llamas shared his experience [moving back to VS Code from Cursor](https://x.com/rmedranollamas/status/1909516749612999149), highlighting the effectiveness of GitHub Copilot combined with the Gemini Code Assist extension (using Gemini 2.5 Pro in Agent Mode). I gave the Gemini Code Assist extension a try myself, but as someone deeply embedded in the Cursor workflow with established keyboard shortcuts and patterns, I struggled to find a flow I liked and didn't stick with it for long. It's interesting to see different perspectives, though!

  * AI features are rolling out more broadly in [Chrome](https://x.com/iam_chonchol/status/1909942954686636224), including text grabbing from YouTube videos and Google Lens integration.

* **Cloudflare Corner:**

  * Big news for edge compute: [Cloudflare Containers are coming to Open Beta in June](https://x.com/CherryJimbo/status/1910682562499850405), enabling running containerized apps (Next.js, Go, PHP confirmed) directly on the edge. This is huge news, in my opinion. Think about all the WordPress sites and other applications that rely on containerization. Opening this up on the edge unlocks incredible possibilities, including for AI applications. I'm super hyped to see what people build with this come June.

  * A new tool, [MCPify.ai](http://mcpify.ai/), launched for building MCP servers conversationally, built entirely on Cloudflare Workers and Durable Objects. ([Source](https://x.com/pbteja1998/status/1911723180445610149))

  * Securing MCP servers is getting easier, with examples shared using [WorkOS AuthKit](https://x.com/WorkOS/status/1910722639036874943) and [Auth0](https://x.com/dschenkelman/status/1910693265566728319).

* **IDE Updates:**

  * JetBrains shared the public [WebStorm roadmap for March-April](https://youtrack.jetbrains.com/issue/WEB-72310). ([Source](https://x.com/WebStormIDE/status/1909291367504748937))

> **✨ Workshop Spotlight: Conquer the Complexity of Cursor (Europe Friendly Time!) ✨**
>
> Missed the last workshop or found the timing tricky? This one's for you! Master practical AI development workflows in Cursor in a session scheduled for **12:00 PM UTC** to better accommodate European attendees.
>
> This hands-on workshop covers Agents, Ask, Custom Modes, multi-file analysis, effective prompting, Cursor rules, and strategies for handling AI failures. Unlock Cursor's potential and streamline your development process.
>
> * **When:** \[Check website for upcoming dates - This session is Europe-friendly at 12:00 PM UTC\]
>
> * **Where:** Zoom (Live Q&A included)
>
> * **Investment:** $149
>
> ➡️ [**Read More about the Workshop**](https://egghead.io/workshop/cursor)
> ➡️ [**Register Now ($149)**](https://buy.stripe.com/7sI7tT81dfpC06s28c)
>
> *(Team training also available)*

## Community Buzz & Resources

* **MCP Explained:** Kent C. Dodds wrote a piece explaining [why he's excited about Model Context Protocol (MCP)](https://www.epicai.pro/the-game-changing-potential-of-model-context-protocol) and its potential. ([Source](https://x.com/kentcdodds/status/1911840456432034112))

* **Prompting Guide:** Ian Nuttall surfaced [v7 of Google's Prompt Engineering Guide](https://x.com/iannuttall/status/1911086164196606314), a deep dive into techniques and best practices. Definitely worth a look.

* **Discussion Starter:** Eric Zakariasson asked the community about their [favorite CLIs and MCP servers to use with the Cursor agent](https://x.com/ericzakariasson/status/1910808935961088346). What are you all using?

* **Gemini 2.5 Pro Praise:** The positive buzz around Gemini 2.5 Pro continues to grow in the community. It's getting rave reviews and even achieving 'S-tier' status on social platforms like Reddit for its coding capabilities. ([Source](https://x.com/suchenzang/status/1911251230317490416))

That’s a wrap for this week! There's always so much happening, it's hard to keep up, but hopefully, this helps surface some of the more interesting bits for developers working with AI.

If you have any feedback or questions, feel free to respond to this email. Always happy to talk shop about the latest AI tools.

John Lindquist

[egghead.io](https://egghead.io)

AI Dev Essentials #2: GPT-4.1 Arrives, MCP Deep Dive & Google's Agent Dev Kit

AI Dev Essentials #2: GPT-4.1 & Gemini updates, MCP tools, Vercel v0, Google ADK, Cloudflare Containers news. Latest AI dev tooling highlights.

In this quick walkthrough, you’ll learn how to drop Nx into an existing npm or pnpm workspace and immediately benefit from project graph visualization, caching, and smart task orchestration, all without rewriting your setup.

You’ll start with a standard React monorepo containing a Vite app, a UI package, and utility functions. Then, using a single command (`nx init`), you’ll initialize Nx and see how it auto-detects your existing scripts, builds a dependency graph, and enables advanced features like affected commands and local caching.

We're also going to explore optional enhancements using Nx plugins for Vite and React. You’ll see how they help Nx infer tasks directly from your Vite config files, improve DX with the Nx Console VS Code extension, and leverage Nx plugin generators to scaffold code with a consistent structure.

What you’ll learn
- How to initialize Nx in an existing npm or pnpm monorepo
- How Nx understands your workspace structure and scripts
- How local caching and affected builds speed up development
- How optional Nx plugins improve DX without adding bloat
- How to scaffold new packages

Using Nx on an existing React and NPM workspace based monorepo

Applying Nx to an existing React monorepo to enable caching, task orchestration, and project graph analysis without changing your current setup.

Typing repetitive or complex instructions for Cursor's AI agent can slow down your workflow. This lesson teaches you how to create custom slash commands (e.g., `/s term`, `/l`, `/c`) using Cursor's "Rules" feature. Learn how to map these simple shortcuts to specific AI actions, instructing the agent to use precise tools like `codebase_search`, `edit_file`, or `run_terminal_cmd` based on your command and the current conversation context.

**Workflow demonstrated in this lesson:**

*   List available AI tools (built-in and MCP) to get their exact names.
*   Navigate to Cursor Settings -> Rules.
*   Define custom rules under a heading (e.g., `## Slash Commands`).
*   Create rules mapping a slash command pattern (like `/s <term>`) to a detailed instruction specifying which tool to use and how (e.g., "Use the codebase_search tool to search for <term/>").
*   Define rules that leverage conversation context (e.g., for summarizing notes or creating commit messages).
*   Save the rules (potentially in `.cursor/rules/project.mdc` for team sharing).
*   Invoke the custom slash commands (e.g., `/s handle`, `/l`, `/c`) in the chat/agent window.
*   Observe the AI understanding the shortcut and executing the intended tool call.

**Key benefits:**

*   Creates efficient, reusable shortcuts for common AI interactions.
*   Reduces the need for typing lengthy, detailed prompts repeatedly.
*   Allows mapping simple commands to specific Cursor tool invocations.
*   Enables commands that leverage the ongoing conversation context.
*   Improves workflow speed and consistency when working with the AI agent.

Speed Up Your Agents with Cursor Slash Commands

Hey Everyone 👋,

John Lindquist here. Since I've been diving deep into AI tooling and workflows over the past year, I'm starting this weekly newsletter to share updates on what interests me and could be helpful to the community. The goal is to help everyone stay up-to-date with the latest in essentials tools for AI devs.

I'll focus on relevant community news, model evaluations for coding, notable tools like Cursor and Windsurf, and practical workflows (including tools I build myself 😇). This week kicks off Cloudflare Developer Week with major announcements around agent/MCP services that many of us will likely use soon (I'll dig in and share my thoughts next issue). There are also lots of hints about new coding models possibly coming to Cursor (though my preference remains Gemini 2.5). Personally, I'm hoping for a Gemini Flash 2.5 variant. So let's hop into the latest! For my detailed, up-to-date workflows, check out the workshop info below.

Recent egghead.io lessons about AI tooling:

* **[Swarm Intelligence: Massively Parallelize Your AI Agents in Cursor](https://egghead.io/swarm-intelligence-massively-parallelize-your-ai-agents-in-cursor~g7u2g):** A workflow using `file-forge`, AI scripting, and a custom `git worktree` tool (`wt`) to launch parallel Cursor agents on different branches.
* **[Build a Better Edit Tool in Cursor with Custom Agent Modes](https://egghead.io/build-a-better-edit-tool-in-cursor-with-custom-agent-modes~21rr0):** Create a focused 'edit mode' in Cursor for precise AI refactors without conversational overhead, overcoming Command-K limitations.
* **[Visually Clone Websites with Gemini 2.5 Canvas for Cursor](https://egghead.io/visually-clone-websites-with-gemini-2-5-canvas-for-cursor~s5ugk):** Use Gemini 2.5 Pro's Canvas feature within Cursor to analyze and replicate website structures.

---

## Cloudflare Developer Week: Agent & Platform Updates

Cloudflare announced several updates relevant to AI application development:

* **Durable Objects Free Tier:** Lowers the barrier for experimenting with stateful serverless and the Agents SDK. ([Rita Kozlov](https://x.com/ritakozlov_/status/1909231625855983939))
* **MCP Enhancements:** BYO Auth (incl. [Auth0](https://x.com/auth0/status/1909307220816228354)) and Hibernation for MCP servers aim to improve agent security and efficiency. Exercise caution with MCP, but these are steps toward production viability.
* **Workflows GA & autoRAG:** Orchestration tool is now GA; a new autoRAG product indicates more integrated AI solutions.
* **Outerbase Acquisition:** Expect Durable Objects usability improvements following this acquisition. ([Rita Kozlov](https://x.com/ritakozlov_/status/1909232149246492887))
* **OpenNext Adapter Beta:** v1.0-beta for deploying Next.js apps on Cloudflare Pages adds caching, PPR, middleware support. ([CloudflareDev](https://x.com/CloudflareDev/status/1909598450871652398))

**Summary:** Cloudflare is actively enhancing its platform for AI/agent development, particularly reducing friction with Durable Objects and MCP.

## Llama 4 & Nemotron-Ultra Released

Meta's Llama 4 models began rolling out, with initial reports of variable quality across implementations. Meta attributes this to implementation stabilization, denying training on test sets ([Ahmad Al-Dahle](https://x.com/Ahmad_Al_Dahle/status/1909302532306092107)). Nvidia subsequently released **Llama-Nemotron-Ultra** (253B parameters), derived from Llama-405B via pruning and reasoning-focused post-training. Open weights and data are available ([Oleksii Kuchaiev](https://x.com/kuchaev/status/1909444566379573646)).

**Summary:** More powerful open models are available. Llama 4's initial rollout highlights the importance of stable implementations. Nemotron-Ultra adds a high-end specialized option.

---

## Quasar Alpha: Stealth Model on OpenRouter

OpenRouter provides early access to "Quasar Alpha," a model with limited public details but notable claims: 1M token context, benchmarks reportedly surpassing Claude 3.7 Sonnet, and >4x faster speeds. Reports suggest strong coding performance comparable to O3 Mini/DeepSeek R1 but significantly faster ([Matthew Berman's Thread](https://x.com/TheMattBerman/status/1908286423976886371)). The originating lab remains anonymous; speculation includes GPT-5, Claude 4, or Gemini 3.

**Summary:** The combination of large context, speed, and reported coding strength warrants attention for agentic workflows and large codebase analysis, despite benchmark caveats. Worth testing via OpenRouter if accessible.

---

**✨ Workshop Spotlight: Conquer the Complexity of Cursor ✨**

Master practical AI development workflows in Cursor. This hands-on workshop covers Agents, Ask, Custom Modes, multi-file analysis, effective prompting, Cursor rules, and strategies for handling AI failures.

* **When:** **This Thursday!** April 10, 2025, 9:00 AM - 2:00 PM (PDT)
* **Where:** Zoom (Live Q&A included)
* **Investment:** $149

Unlock Cursor's potential and streamline your development process.

➡️ [**Read More about the Workshop**](https://egghead.io/workshop/cursor)
➡️ [**Register Now ($149)**](https://buy.stripe.com/dR67tT4P17Xa8CYfZ1)

*(Team training also available)*

---

## Quick Links

* **Nightwhisper Buzz:** Highly-rated coding model "Nightwhisper" (rumored Gemini 2.5 variant?) left LMSys Arena; release may be imminent. ([ʟᴇɢɪᴛ Tweet](https://x.com/legit_api/status/1908264443827351913), [AiBattle Tweet](https://x.com/AiBattle_/status/1907519430961025476))
* **AI SDK Speech-to-Text:** Vercel AI SDK added a `transcribe` function. ([AI SDK Tweet](https://x.com/aisdk/status/1909603418639155460))
* **Gemini 2.5 Pro Updates:** Supports YouTube URLs as input in AI Studio (transcribe, summarize, analyze); reported improvements reducing stop issues/displaying thinking tokens. ([Jean Gatt Tweet](https://x.com/jean__gatt/status/1909256747518226829), [Eric Zakariasson Tweet](https://x.com/ericzakariasson/status/1908619515023548880))
* **Baby Cursor Project:** Cursor's Ryo Lu is building a rapid prototyping environment for IDE ideas. ([Ryo Lu Tweet](https://x.com/ryolu_/status/1908328050154233863))
* **(Rumor) Qwen3 Soon?:** Hints suggest Alibaba's Qwen3 model release is near. ([Elaina Tweet](https://x.com/Elaina43114880/status/1909572798944841859))

---

If you have any feedback or any questions, feel free to respond to this email. Always happy to talk shop about the latest AI tools.

John Lindquist

[egghead.io](https://egghead.io)

AI Dev Essentials #1: Cloudflare agent updates, Llama 4/Nemotron/Quasar models, Cursor workshop

Cursor's AI Agent has the abilitly to invoke MCP tools, but they lack direct access to your project. This lesson shows how to build custom MCP (Model Context Protocol) server tools that bridge this gap. Learn to define tool parameters using Zod schemas and the crucial `.describe()` method to explicitly request necessary context from the Cursor environment *before* your tool runs. See how the AI gathers this information (like Git status or version via terminal commands, or web search results) and passes it to your tool, enabling powerful, context-aware automation.

**Workflow demonstrated in this lesson:**

*   Scaffold a basic MCP server using a Cloudflare template (`pnpm create cloudflare`).
*   Run the MCP server locally and configure it in Cursor settings.
*   Define MCP tools (e.g., `status`) within the server code (`index.ts`).
*   Specify required context for tools using Zod schema parameters and `.describe()` (e.g., requesting "The status of the git repository").
*   Interact with the Cursor Agent using natural language (e.g., "Please check the status").
*   Observe the Agent's thought process: identifying the need for specific context based on the `.describe()` text.
*   See the Agent automatically using its *own* tools (like `run_terminal_cmd` or `web_search`) to gather the requested context *before* calling your MCP tool.
*   Watch the Agent call your MCP tool, passing the gathered local context (Git status, version, etc.) as arguments.
*   Receive the final response from the Agent, incorporating the information provided by your local MCP tool.

**Key benefits:**

*   Allows Cursor's AI to access and reason about information from your local machine (Git status, versions, file contents, etc.).
*   Enables the creation of AI tools that directly interact with or report on your local development environment.
*   Demonstrates the power of using `.describe()` in Zod schemas to guide the AI in gathering necessary context automatically.
*   Unlocks advanced automation possibilities by combining AI reasoning with local machine access.

Create a Custom MCP that Calls Cursor Tools

Vimium's Vomnibar is a "command palette"-like search tool for your open tabs, browser history, and bookmarks. We can search through and jump to any tab open across browser windows. We can also do a generalized search with results that also include browser history and bookmarks which can either be opened in the current tab or a new tab. If you're anything like me, you open tons of tabs and visit hundreds of webpages over the course of a week. The vomnibar puts all of that at your fingertips.

Josh Branchaud

Open Tabs, Browser History, and Bookmarks with the Vomnibar

Vimium's Vomnibar is a "command palette"-like search tool for your open tabs, browser history, and bookmarks.

Another aspect of Vimium's configurability is customizable key mappings. We can add new mappings and override existing ones. If there is a certain Vimium feature you want to make easier to trigger, adjust the key mapping to suit your needs.

Configure Custom Vimium Key Mappings

Another aspect of Vimium's configurability is customizable key mappings. We can add new mappings and override existing ones.

Many aspects of Vimium can be configured in order to bend the tool to your specific needs and use cases. We look at how to configure what sites turn off Vimium, the default search engine, link hint characters, and other basic settings. We also see how both insert mode and searching a visual selection work. Custom keymappings and custom search engines are covered in subsequent lessons.

Configure Basic Aspects of Vimium

Many aspects of Vimium can be configured in order to bend the tool to your specific needs and use cases.