# Mk Vibe

> Run the full vibe pipeline. Use for GitHub issues, feature requests, bug fixes, or autonomous ship runs. Supports worktree, reusable/TDD plan gates, cook or fix routing, ship PR, review-pr, merge/CI watch, and kongming advisory supervision via --advice.

- Skill: `phuc-nt/mk-vibe` (Agent Skill)
- Install (CLI): `npx skillmds@latest add phuc-nt/mk-vibe`
- Raw SKILL.md: https://api.skillmd.com/api/skills/phuc-nt/mk-vibe/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: phuc-nt (https://skillmd.com/u/phuc-nt)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/phuc-nt/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:

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

Flags:

| Flag | Effect |
| --- | --- |
| `--beta` | Ship to beta/dev target via `/mk-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. |
| `--advice` | Run the whole pipeline under `kongming` advisory supervision (see Advisory supervision). Composes with any ship mode. |
| no `--beta` | Ship stable via `/mk-ship official`; final ready label is `ready to ship stable`. |
| no `--ship` | Stop after PR is reviewed, fixed, replied, and labeled ready. |

`--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:
     ```bash
     /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:
     ```bash
     /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:
     ```bash
     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:
     ```bash
     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:
     ```bash
     /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:
     ```bash
     /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:
     ```bash
     /mk-code-review --pending
     ```
   - Fix Critical and Important findings before shipping.
   - Re-run relevant validation after fixes.

7. **Ship PR**
   - If `--beta` is present:
     ```bash
     /mk-ship beta
     ```
   - Otherwise:
     ```bash
     /mk-ship official
     ```
   - Capture PR URL/number from `/mk-ship` output.

8. **Review/fix/reply PR**
   - Activate:
     ```bash
     /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:

```markdown
## 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:

```markdown
**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
```