ak-vibe

name	ak:vibe
description	Run the full vibe pipeline from request intake to PR readiness, with optional merge and post-merge CI convergence. Orchestrates worktree, plan, cook/fix, code-review, ship, and review-pr. Use for GitHub issues, feature requests, bug fixes, or autonomous ship runs.
user-invocable	true
when_to_use	Invoke when a user wants one command to take a GitHub issue or feature request from planning through implementation, PR review, shipping, and optional merge.
category	dev-tools
keywords	["vibe","pipeline","autonomous","ship","worktree","plan","cook","fix","review-pr","ci"]
argument-hint	[--ship] [--beta] <github-issue-url | feature request>
license	MIT
metadata	{"author":"agentkit","version":"1.0.0"}

Vibe Pipeline

Run a full autonomous product-development pipeline from request intake to PR readiness, with optional merge and post-merge CI convergence.

This skill orchestrates across /ak:worktree, /ak:plan, /ak:cook, /ak:fix, /ak:code-review, /ak:ship, and /ak:review-pr. It does NOT bypass those skills' approval gates, tests, code-review blockers, branch protections, or security policies.

Inputs

Accepted forms:

/ak:vibe <github-issue-url>
/ak:vibe --ship --beta <github-issue-url>
/ak:vibe --ship <feature request>

Flags:

Flag	Effect
--beta	Ship to beta/dev target via /ak:ship beta; final ready label is ready to ship beta.
--ship	After review/fix/reply, merge the PR and watch/fix CI until success or true external blocker.
no --beta	Ship stable via /ak:ship official; final ready label is ready to ship stable.
no --ship	Stop after PR is reviewed, fixed, replied, and labeled ready.

Pipeline

1. Parse and analyze request

   • Strip --ship and --beta from arguments.
   • If remaining input is a GitHub issue URL/number, treat that issue as the source of truth. Do not create a duplicate.
   • If remaining input is natural language, treat it as the feature request and create the GitHub issue after plan validation/red-team.
   • Resolve repo with gh repo view --json nameWithOwner,defaultBranchRef.
   • For GitHub issue URLs, parse OWNER/REPO from the URL and compare it with the current repo. If it differs, stop and ask the user to switch to the matching repo/worktree or provide an issue from the current repo.
   • For issue inputs, read the title, body, and comments with gh issue view. For natural-language inputs, use the text directly.
   • Extract concrete outcome, acceptance criteria, scope boundary, non-negotiable constraints, blockers, and likely touched surfaces.