Skip to content

Add vibekit to algokit cli + implement it to init #716

Open
p2arthur wants to merge 8 commits intodecouplingfrom
feat/vibe-algokit
Open

Add vibekit to algokit cli + implement it to init #716
p2arthur wants to merge 8 commits intodecouplingfrom
feat/vibe-algokit

Conversation

@p2arthur
Copy link
Copy Markdown

@p2arthur p2arthur commented Mar 13, 2026

Add algokit vibe spike + init prompt - Builds on top of decoupling branch

Hey! This PR adds a "spike" for VibeKit integration. It’s mostly opt-in for now so it doesn't break anyone's existing workflow.

What I did

New Commands: Added algokit vibe with setup and status subcommands.

setup checks if you have VibeKit, asks to install it if you don't, and then runs init.

status just checks the current VibeKit status.

Init Prompt: I added a prompt to algokit init. Now it asks if you want to set up VibeKit right away inside the new project folder.

Docs & Tests: Added a new docs page and wrote some tests to make sure the commands and the init prompt actually work.

Snapshot Fix: Had to update one init snapshot because of a small git config change.

A few notes

It's still a spike, so I kept everything optional.

I didn't add any automatic .gitignore logic for Vibe files yet—figured I'd keep it simple for this first pass.

I’m passing LocalNet context through env vars, but I made it non-blocking so it won't crash the setup if something is weird.

@p2arthur p2arthur changed the base branch from main to decoupling March 13, 2026 20:35
@Ganainmtech
Copy link
Copy Markdown

+1, some builders add VibeKit after algokit init (or vice versa), so being able to set it up in one go would improve the agentic dev experience or at least give builders the option while staying inside their AlgoKit project.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be removed, decoupling branch is already on uv we likely just forgot to remove the poetry lockfile

Copy link
Copy Markdown
Contributor

@aorumbayev aorumbayev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for spiking on this, good initiative on making it opt-in and non-blocking 👍 see inline comments for details — my main suggestion is moving this under algokit task and removing the init integration

from algokit.cli.project.bootstrap import bootstrap_group
from algokit.cli.project.deploy import deploy_command
from algokit.cli.task import task_group
from algokit.cli.vibe import vibe_group
Copy link
Copy Markdown
Contributor

@aorumbayev aorumbayev Mar 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the main concern with the pr — vibekit is an external third-party tool that we're wrapping, and we already have an established namespace for exactly this: algokit task. see how ipfs, analyze, wallet etc all live under algokit task as subcommands/subgroups in src/algokit/cli/tasks/. the ipfs subgroup is the closest analogue since it's also a click group with multiple subcommands wrapping an external service.

i'd suggest:

  1. move vibe.pysrc/algokit/cli/tasks/vibe.py and register via task_group.add_command(vibe_group) in src/algokit/cli/task.py. user gets algokit task vibe setup / algokit task vibe status
  2. remove the init integration — imho the value of embedding it in init is saving the user from typing algokit task vibe setup after init, but the cost is a new prompt shown to every interactive init user, 25 lines of gating logic with an implicit run_bootstrap coupling, and a broad except Exception in a critical flow. vibekit setup is a post-init task, not a project scaffolding concern — it doesn't belong in the init flow. If you do think its worth keeping then perhaps you can print a informational message that can now invoke this task command to setup vibekit (along with a short sentence on what this tool is and how it relates to algokit)
  3. keeping it as algokit task vibe command group

VIBEKIT_INSTALL_URL = "https://getvibekit.ai/install"


@click.group("vibe", short_help="Give your AI assistant Algorand superpowers using VibeKit.")
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: the marketing copy in the short_help feels a bit out of place compared to other command descriptions in the cli. compare with:

  • "Collection of useful tasks to help you develop on Algorand." (task)
  • "Upload files to IPFS using Pinata provider." (ipfs)
  • "Manage the AlgoKit LocalNet." (localnet)

i'd suggest something more descriptive and consistent like "Install and manage VibeKit for AI-assisted development." — tells the user what it does without the superpowers marketing

return ["sh", "-c", f"curl -fsSL {VIBEKIT_INSTALL_URL} | sh"]


def _build_vibekit_init_env() -> dict[str, str]:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we already have this exact logic in localnet_status at src/algokit/cli/localnet.py:293-301 — it does the same sandbox.ps()ps_by_name → check state pattern. rather than duplicating it here, i'd suggest extracting a small helper into core/sandbox.py like:

def is_localnet_running() -> bool:
    """Check if the AlgoKit LocalNet services are running."""
    ...

then both localnet status and vibe can reuse it. also note you're only checking ("algod", "indexer") but the canonical service list is SERVICE_NAMES = ("algod", "conduit", "indexer-db", "indexer") defined in localnet.py:276 — worth being consistent there

also the ComposeSandbox import at module level will pull in docker/container engine deps just from importing vibe.py — localnet handles this more carefully. given that localnet context is optional (your docs say vibekit init still runs without it), a lazy import inside the try block would be safer

)
except Exception as ex:
# Context injection should never block initialization.
logger.warning("Unable to inspect AlgoKit LocalNet status; proceeding without confirmed LocalNet state.")
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the warning doesn't tell the user what actually went wrong — could be docker not running, permission denied, network issue etc. at minimum include the exception so the user has something actionable. something like f"Unable to inspect LocalNet status ({ex}); proceeding without confirmed LocalNet state." — we do this in other places in the cli

"""Run VibeKit setup flow."""
vibekit_cmd = _resolve_vibekit_command()
if vibekit_cmd is None:
click.echo(click.style("VibeKit not found.", fg="yellow"))
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we generally use logger.warning() for warning-level messages throughout the cli rather than click.echo(click.style(...)) — see how _maybe_bootstrap, localnet commands, codespace etc handle this. using logger ensures consistent formatting with verbose mode and our log handlers

and git("commit", "-m", commit_message, bad_exit_warn_message="Initial commit failed")
and git(
"-c",
"commit.gpgsign=false",
Copy link
Copy Markdown
Contributor

@aorumbayev aorumbayev Mar 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be done in a separate pr?

Copy link
Copy Markdown
Contributor

@aorumbayev aorumbayev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comments above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants