| 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
-
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.
