Add vibekit to algokit cli + implement it to init #716
Add vibekit to algokit cli + implement it to init #716p2arthur wants to merge 8 commits intodecouplingfrom
Conversation
…ibekit if missing and run it to the generated project
|
+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. |
There was a problem hiding this comment.
this should be removed, decoupling branch is already on uv we likely just forgot to remove the poetry lockfile
| 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 |
There was a problem hiding this comment.
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:
- move
vibe.py→src/algokit/cli/tasks/vibe.pyand register viatask_group.add_command(vibe_group)insrc/algokit/cli/task.py. user getsalgokit task vibe setup/algokit task vibe status - remove the init integration — imho the value of embedding it in init is saving the user from typing
algokit task vibe setupafter init, but the cost is a new prompt shown to every interactive init user, 25 lines of gating logic with an implicitrun_bootstrapcoupling, and a broadexcept Exceptionin 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) - keeping it as
algokit task vibecommand group
| VIBEKIT_INSTALL_URL = "https://getvibekit.ai/install" | ||
|
|
||
|
|
||
| @click.group("vibe", short_help="Give your AI assistant Algorand superpowers using VibeKit.") |
There was a problem hiding this comment.
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]: |
There was a problem hiding this comment.
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.") |
There was a problem hiding this comment.
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")) |
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
should this be done in a separate pr?
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.