why i tried advent of ai

A few weeks ago, Goose announced that they were hosting daily AI dev challenges. At first, many would think that "challenges" is a bit of a push if it's only prompting an LLM. But, I have actually learnt multiple interesting things about AI Engineering (a newcoming term which I've heard before, and sounds less cringe than "vibe coding" to me) — from subagents, more advanced tooling with recipes, and how easy they provide MCP tools to average users.

I wanted to collect all the features that Goose offers that I either wasn't aware of, or didn't fully understand before these challenges. I also wanted to share what worked for me, prompting styles, and when it felt better to use the GUI vs CLI.

what is goose?

Their website currently advertises it as:

your local AI agent, automating engineering tasks seamlessly

Honestly, it summarises it very well. goose in itself is both a GUI application (available on all platforms, macOS, Linux, and Windows), and a CLI on the same platforms.

The tool recently joined the Linux Foundation among other common AI tools/standards, such as MCP (Model Context Protocol, donated by Anthropic), AGENTS.md (from OpenAI). From what has been publicly said, goose is expected to be used as a reference implementation for parts of MCP, giving confidence that it will stay aligned with future versions of the protocol.

But in short, goose is similar to Claude Code, OpenCode, Codex, Gemini CLI, and all other similar apps. I'd argue it's more extensible with what exactly you can do with it, but there are some drawbacks too.

what are these drawbacks?

Before I get into what I've learnt about it, I just want to mention some of the weird quirks or annoyances I have with it! (Not to get too negative 😅).

Firstly, it feels VERY token heavy. I've tried looking around online to find out if others have had this, but I just don't think goose is as well known as other CLI tools in the space. I'm unsure what causes this, but if I were to put the same prompt into goose and OpenCode - both using OpenRouter - I could guarantee you that a similar result from OpenCode would come out significantly cheaper. I'm hoping this gets "fixed" in future. I can only think that it's either a large system prompt, the extensions always being reinput to the message each time you send something, or that it maybe gets the LLM to read every file each new message? (I doubt it's that last point, but I'm unsure what else..)

Next is the GUI app. The CLI form of goose is very good. But when it comes to the GUI client of goose, it just feels a little behind. As far as I can tell it's some sort of webview running locally? It's the same build across platforms, but bugs out frequently.

Here are some of my main annoyances with it:

  • Opening goose in a new directory opens a new window, rather than just refreshing the current session to reflect this change.

  • Updating goose (GUI!) on macOS instead just downloads the latest .dmg file, and gets you to reinstall this in the Applications folder - this is super unintuitive!

  • On Windows, you can't even install it as a proper application as far as I can tell (in the sense that you can open it from the start menu) - you have to launch it from the folder you extract when you run it each time.

And just weird UI bugs, such as this prompt I had on macOS the other day when I kept having to re-enter my keychain password, even after clicking Allow Always. I guess that's what happens when you don't build it natively and instead go for Electron.

so why is it so good!?

1 - Extensions

Bar the issues above, it's actually super powerful when you provide it with the extensions - and the goose team have made it SUPER simple to be able to install these extensions and get them running in no time. They provide a page on their site where they frequently add new extensions which you can add with a single click to open the desktop app, or you can copy their commands into your terminal to install them on goose CLI.

Here are the extensions I currently have enabled on my goose Mac app:

goose GUI Extensions settings panel showing 10 enabled extensions: Auto Visualiser, Chatrecall, Computer Controller, Council of Mine, Developer Tools, Extension Manager, Fetch, Memory, PDF Reader, Todo, and Vercel.

These particularly came in handy for the advent of AI challenges:

  • Auto visualiser → used to view any data with the LLM directly in the chat UI with simple queries

  • Council of mine → I posted about this in this GitHub comment. It's a really cool way to get goose to have 9 different "voices" (councils) which try to reason their way to a result, then it lets each council vote for another to get a final result. They all see each other's ideas to let each come with a fair vote. This was handy in day 12, where we had to find a mascot for the winter festival.

  • Todo → tool similar to what you see in Cursor, Antigravity, VSCode, OpenCode, etc.. where the agent will create a list of tasks it will have to do. Enabling this improves the quality of the result quite a lot as it has a plan it has to follow as it goes through, and it will periodically check on this, update it, remove/edit tasks as it sees fit, and the user can view it the whole time.

  • Vercel → an extension that lets the LLMs interact with your Vercel account. This was useful early on when we had to deploy a website publicly. This could obviously be done other ways, such as using GitHub pages, Cloudflare Pages, or similar, but the Vercel MCP server made this incredibly easy. You just had to ask the agent to make a new Vercel deployment and it just did it (after signing in, of course)

2 - Recipes

I've explored Recipes in the app before, but I underestimated how powerful they are! I just assumed they were presets for system prompts, but they are much more!

One of the tasks was to automate a Christmas tag writer recipe which would help speed up the process (in this fake scenario, of course!). This is where we used the parameters to be able to customise this, meaning that you can use a simple prompt, but the prompt is filled with data you provide on the first chat.

Here's a snippet of the instructions that my Recipe had:

You will receive these further parameters:
{{recipient_name}} → name of the person that the gift is for.
{{gift_description}} → a description of the gift.
{{sender_name}} → name of the sender of this gift.

recipient:
{{favourite_colour}} → person the gift's going to's favourite colour
{{lang}} → person it's going to's language (as mentioned above.)
{{tone}} → how it should be worded! (e.g., heartfelt.)

The values in {} curly brackets were provided and filled in here from the user's input.

With the goose GUI, it made it easy to configure more information about each parameter, such as the type of data it would be, and whether it was required from the user's end or not:

Goose Mac app showing "tag_style" with description "Style you want the tag to be like" and input type of "string", requirement of "Required".

This allows users to easily input the recipe parameters on a new chat from the start:

The start of a new chat with goose on the Christmas tag maker recipe - it asks the user to input multiple fields of data to customise the end result.

3 - .goosehints file

goose comes with few tweaks made out of the box. Editing the .goosehints file allows you to set clear rules that you want every future chat to follow.

In their words:

The use of .goosehints ensures that goose understands your requirements better and can execute tasks more effectively.

In the earlier challenges, I had some issues where it felt like goose was crashing or unresponsive, but it turns out that it was trying to run commands like npm run dev in a prior response, and getting stuck in a loop there. This had meant that it wasn't answering new chats as it was waiting for the previous command to finish.

Part of me is curious as to whether goose will update in future to have an auto timeout, or some mechanism to stop this, but in the mean time, changing the .goosehints file allowed me to make sure the agent told the user to run this, instead of doing it itself. I mentioned that bigger commands that would take a considerable amount of time should be handed to the user to run - this stopped me having issues in future.

This can be used in many more powerful ways though. If your favourite colour is red, and you want all future websites/apps it makes to have a red theme, you could enforce this in the .goosehints file with some sort of prompt like:

If the user requests you to build any UI in the future, such as in a React webapp, CSS, or anything similar, use their favourite colour, which is Red

Which goose would follow in all future sessions. This file can be changed at any time.

I've seen more advanced developers define rules such as using React + Vite for sites by default, rather than other frameworks, without asking the user.

4 - Subagents

Subagents are built into goose, but feel sort of hidden to me. It's a way to distribute work to multiple agents which work in parallel, separately, to bring you one result at the end. To me these feel relatively hidden. They have a page on their site about these, but it's basically up to you to prompt the agent to use subagents, it's not in the UI with a simple "Use Subagents" button or anything.

I got this screenshot from when goose was working on the day 11 task:

Screenshot of the goose Mac app showing that goose started to write 3 different markdown files for different subagents.

Within these markdown files that goose had created for the subagets, the subagents were provided with a clear mission and given the requirements for it. It's really useful having goose expand on what I tried to say, but with more technical detail for these subagents.

I'm still surprised by this. I'm curious as to how many you can run at once too, I'll likely try to test this in the future!

You can view the markdown files it made for the 3 subagents here:

when should i use goose cli vs gui?

I personally switch between the two frequently, but I'm unsure if others use both or just one. I've found that if I want to initiate a new project with a new idea, it can be quicker to just use the goose CLI tool to get it started. However, when I'm refining a project and have ideas for how something should look or function, it can be useful to use the goose GUI app where you can easily attach images through pasting (at least more easily).

Personally, I also find it much easier to use the extensions through the UI. You can use the goose configure command with the CLI, but it's a bit of a hassle to navigate around with the keyboard shortcuts as you have to reopen the same page whenever you close it. As far as I can tell, the CLI copies from the GUI in the settings/extensions you configure, so it can be useful to even just configure the extensions in the GUI and reopen the CLI after.

summary

goose is a great tool! I think it's worth a shot if you frequently use AI to code, or haven't even tried it. The way they simplify MCP servers into "Extensions", and provide the LLMs with everything they need to put together a project, with everything I've discussed above.

What would I change though? Personally, I'm not a fan of the desktop GUI app, as I mentioned above, although I'm not a proper dev so I can't really criticise since I can't make a better one 🙃