Mk Vibe

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 handles orchestration across /mk-worktree, /mk-plan, /mk-cook, /mk-fix, /mk-code-review, /mk-ship, and /mk-review-pr. Does NOT bypass those skills' approval gates, tests, code-review blockers, branch protections, or security policies.

Inputs

Accepted forms:

/mk-vibe <github-issue-url>
/mk-vibe --ship --beta <github-issue-url>
/mk-vibe --advice <github-issue-url>
/mk-vibe --ship <feature request>

Flags:

--advice is orthogonal to ship mode and composes with both stable and beta ships.

Advisory supervision (--advice)

When --advice is present, run the whole pipeline under kongming supervision. kongming is an advisory-only supervisor: it returns counsel, never code, and the main agent stays responsible for every decision, edit, and gate.

Spawn kongming at these checkpoints:

• After each pipeline phase completes - after the plan gates (step 3), after implementation (step 5), and after the local code review (step 6). Pass the phase goal, what changed, and the evidence; ask for a go/no-go and the next risk to watch before continuing.
• When stuck - repeated failures, a blocked step, or contradictory evidence; pass everything already tried and the exact obstacle.
• Before a high-stakes decision - a design fork, a public-contract or security-sensitive change, or an irreversible action; get counsel first.
• After the PR is opened and CI is green - this is the mandatory review gate described below.

Invoke with the runtime's live agent-delegation capability using subagent_type="kongming" and a prompt containing the task, evidence, approaches tried, and the exact question. Give it enough context to answer in one reply; it does not interview.

Mandatory post-PR review gate: once the PR is opened, watch and fix CI until every required check is green, then spawn kongming to review the whole implementation and post its assessment plus concrete next steps as a comment directly on the PR and the source issue when one exists.

--advice adds supervision; it never bypasses this skill's approval gates, tests, code-review blockers, branch protections, or security policy.

Pipeline

1. Parse and analyze request

   • Strip --ship, --beta, and --advice 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.
   • Classify implementation route:
     • Bugfix route when the issue/request is a bug, regression, broken behavior, failing test/CI, production/staging incident, error log, or explicitly says fix/debug/repair.
     • Feature route for net-new capability, enhancement, refactor, or ambiguous product work.
   • Detect an existing plan if the user provides a plan path, the issue body/comments link a plans/.../plan.md, or a current worktree already contains a matching plan. Verify the file exists before treating it as reusable.
   • If any of those are ambiguous enough to change implementation, ask before worktree creation. Otherwise proceed and carry the extracted requirements into planning and issue updates.

2. Create isolated worktree and branch

   • Activate /mk-worktree to create an isolated worktree and branch.
   • Use a descriptive branch name derived from the issue/request.
   • If an existing clean feature worktree/branch already matches the request, reuse it and record why.
   • Never work directly on main, master, dev, beta, or develop.

3. Plan intake and gates

   • If a valid existing plan.md was detected, set plan.md to its absolute path, reuse it, and skip /mk-plan --tdd.
   • If no valid plan exists, in the new worktree activate:

     /mk-plan --tdd "<source issue or feature request>"
     

     Add --advice when the vibe invocation included --advice.
   • For newly created plans, capture the absolute plan.md path from /mk-plan --tdd.
   • Always run both gates, even when the plan already existed:

     /mk-plan validate <plan.md>
     /mk-plan red-team <plan.md>
     

   • Before implementation, perform the whole-plan consistency sweep required by /mk-plan.
   • Do not proceed to implementation while validation failures, accepted red-team findings, or unresolved contradictions remain.

4. Create or update GitHub issue

   • Ensure labels exist:

     gh label list --json name --jq '.[].name' | grep -Fx "ready to cook" >/dev/null \
       || gh label create "ready to cook" --color "0E8A16" --description "Plan validated; ready for mk-cook or mk-fix"
     gh label list --json name --jq '.[].name' | grep -Fx "in progress" >/dev/null \
       || gh label create "in progress" --color "FBCA04" --description "Implementation is in progress"
     gh label list --json name --jq '.[].name' | grep -Fx "ready to ship stable" >/dev/null \
       || gh label create "ready to ship stable" --color "5319E7" --description "PR reviewed and ready for stable merge"
     gh label list --json name --jq '.[].name' | grep -Fx "ready to ship beta" >/dev/null \
       || gh label create "ready to ship beta" --color "1D76DB" --description "PR reviewed and ready for beta merge"
     

   • If label creation fails for anything other than an existing label, stop and report the exact gh error.
   • Compute relative plan link from repo root.
   • If source issue exists, update/comment on it. If input was natural language, create a new issue.
   • Issue update must include:
     • branch name
     • implementation route (feature via /mk-cook or bugfix via /mk-fix)
     • implementation summary
     • relative plan link
     • ship mode (official or beta)
     • acceptance criteria from the plan
   • Add ready to cook; remove stale ready to ship stable and ready to ship beta.

5. Implement or fix

   • Before activating /mk-cook or /mk-fix, update the pipeline GitHub issue:

     gh issue edit <issue-number-or-url> --add-label "in progress" --remove-label "ready to cook"
     

   • If ready to cook is not currently on the issue, use --add-label "in progress" without --remove-label.
   • If the label update fails for any other reason, stop and report the exact gh error. Do not start implementation while the issue state still says ready to cook.
   • If the request is on the bugfix route, activate:

     /mk-fix --auto <plan.md>
     

     Add --advice when the vibe invocation included --advice.
   • Pass the source issue/request, failure evidence, validated plan path, scope boundary, and acceptance criteria into /mk-fix.
   • If the request is on the feature route, activate:

     /mk-cook --tdd --auto <plan.md>
     

     Add --advice when the vibe invocation included --advice.
   • Honor every hard gate in /mk-cook.
   • Honor every hard gate in /mk-fix on the bugfix route.
   • If implementation stops for user/business decision, update the GitHub issue with blocker details and stop.

6. Review local implementation

   • Activate:

     /mk-code-review --pending
     

   • Fix Critical and Important findings before shipping.
   • Re-run relevant validation after fixes.

7. Ship PR

   • If --beta is present:

     /mk-ship beta
     

   • Otherwise:

     /mk-ship official
     

   • Capture PR URL/number from /mk-ship output.

8. Review/fix/reply PR

   • Activate:

     /mk-review-pr <pr-url-or-number> --fix --reply
     

   • Do not continue until actionable findings are resolved or an external blocker is documented.
   • PR checks must be terminal and green unless the blocker is external and recorded.
   • When --advice is present, after CI is terminal and green, run the mandatory post-PR review gate: spawn kongming to review the whole implementation and post its assessment plus concrete next steps as a comment on the PR and the source issue when one exists (see Advisory supervision).

9. Apply ready label

   • If beta mode: add ready to ship beta.
   • Otherwise: add ready to ship stable.
   • Add the label to both the source issue and PR when possible.
   • Remove ready to cook and in progress after PR review/fix succeeds.

10. Optional merge and CI convergence

    • Only run this step when --ship is present.
    • Merge via GitHub using repository convention and branch protection. Prefer gh pr merge --auto when required checks are still pending; otherwise use the repo's allowed merge method.
    • Never force push. Never direct-push to protected target branches.
    • After merge, watch target-branch CI/deploy workflows for the merge commit.
    • If CI fails with a deterministic repo-fixable error:
      1. Inspect the failed run/job logs with gh run view.
      2. Create a follow-up fix branch/worktree from the target branch.
      3. Activate /mk-fix --auto with exact failing command/error evidence.
      4. Ship the follow-up in the same mode, run /mk-review-pr --fix --reply, merge, and watch again.
    • Stop only when target-branch CI succeeds, an external blocker remains, or the same blocker survives 3 fix attempts.

GitHub Issue Body

Use this body when creating a new issue or updating an execution section:

## Outcome
<user-visible outcome>

## Implementation
- Branch: `<branch-name>`
- Plan: `<relative/path/to/plan.md>`
- Mode: `<official|beta>`
- Route: `<feature|bugfix>`
- PR: `<url once created>`

## Acceptance Criteria
- [ ] <criterion from plan>

## Pipeline State
- [x] Worktree and branch created
- [x] TDD plan created or existing plan reused
- [x] Plan validated
- [x] Plan red-teamed
- [x] Issue labeled `in progress` before implementation
- [ ] Implementation complete
- [ ] PR reviewed and fixed
- [ ] Merged and CI green (only when --ship)

Security

• Never write secrets, tokens, customer data, or private env values into issues, PRs, comments, plans, or logs.
• Redact sensitive command output before posting to GitHub.
• If gh auth lacks permission to create labels, issues, PRs, reviews, or merges, stop and report the exact missing capability.
• If CI fails because of missing secrets, unavailable services, or required human approval, record it as an external blocker. Do not weaken tests or hide failures.

Completion Report

End with:

**Vibe Result**
- Source: <issue/request>
- Branch/worktree: <branch> | <path>
- Plan: <relative path>
- Issue: <url>
- PR: <url>
- Mode: official|beta
- Route: feature|bugfix
- Review: <approve/request-changes/comment + fix iterations>
- Merge: skipped|merged|blocked
- CI: green|failed|blocked

Unresolved questions:
- None