# Mb Execute > Implementation handoff skill for one TASK-* using tier-selected protocol files, local gates, evidence, and explicit verification/sync handoff. - Skill: `mrvladd-d/mb-execute` (Agent Skill) - Install (CLI): `npx skillmds@latest add mrvladd-d/mb-execute` - Raw SKILL.md: https://api.skillmd.com/api/skills/mrvladd-d/mb-execute/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: mrvladd-d (https://skillmd.com/u/mrvladd-d) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/mrvladd-d/mb-execute --- # mb-execute - Implementation Handoff ## Purpose `mb-execute` implements one scoped JSON task. It is not a mini-scheduler and it does not own task closure. Flow: read task -> minimal preflight -> protocol -> implement -> local gates -> evidence -> handoff. ## Status Transition Modes Status transitions have two modes. Scheduler mode: - `/autopilot` and `/autonomous` own task status transitions. - Scheduler decides closure/failure/blocking eligibility. - `/execute` returns scoped implementation handoff; it does not close tasks. - `/verify` gives functional verdict/evidence; in scheduler mode it does not close/fail/block/promote. - `/red-verify` gives semantic verdict for T2/T3; in scheduler mode it does not close/fail/block/promote. - Scheduler must write the closure/failure/blocking decision, final task status, and evidence links to the authoritative indexed `.memory-bank/tasks/TASK-*.task.json` record before `/mb-sync`. - `/mb-sync` records/reconciles already-written task state. It does not decide closure/failure/blocking/promotion and must not sync a decision that exists only in scheduler context. - T0/T1 scheduler closure may use compact evidence / functional PASS according to tier policy. - T2/T3 scheduler closure requires `VERDICT: PASS` plus `SEMANTIC_VERDICT: semantic-pass` before scheduler marks `done`. - T3 scheduler closure also requires exact markers `HUMAN_CHECKPOINT: done` and `ROLLBACK_RECOVERY_NOTE: present`. Manual mode: - Expected T0/T1 simple flow: `/execute -> /verify` for one TASK. - Manual closure is allowed only when an explicit closure owner exists. - `explicit standalone owner` means either the user directly asked the current top-level agent to close the task, or the top-level agent/orchestrator explicitly runs a manual workflow for one TASK and records that it owns closure. Subagents/worker prompts do not silently become closure owners. - `/verify PASS` may mark `T0` / `T1` `status: done` only when explicit closure ownership is present and completed evidence has been written to the task record `verify` field and the compact/full protocol required by tier. - If explicit closure owner is absent, `/verify` records `VERDICT: PASS`, evidence, and a closure recommendation, leaves `status` unchanged, and tells the scheduler/owner to close. - `T2` / `T3` manual closure requires `/verify PASS` plus `/red-verify` / `mb-red-verify` `SEMANTIC_VERDICT: semantic-pass` before `status: done` or `/mb-sync`; if semantic-pass is absent, leave closure pending or blocked, not done. - `semantic-concern` in manual mode means do not trust the existing `done` state without human review / follow-up. - Do not mix scheduler mode and manual mode inside one task run. - No persisted `mode` field is used. ## Inputs - `TASK_ID`, for example `TASK-123` - `.memory-bank/tasks/index.json` - indexed `.memory-bank/tasks/.task.json` - task `tier: T0|T1|T2|T3` - feature or epic docs referenced by the task - `.memory-bank/requirements.md` / REQ IDs when relevant - `.memory-bank/spec-index.md` and all linked authoritative SDD specs when the task record or linked feature contains SDD spec links, for any tier - richer task fields when present: `source_artifacts`, `normative_inputs`, `constraints`, `invariants`, `verification_targets` Authoritative SDD spec links are links to `.memory-bank/spec-index.md`, `.memory-bank/tech-specs/`, `.memory-bank/architecture/`, `.memory-bank/contracts/`, `.memory-bank/domains/`, `.memory-bank/states/`, `.memory-bank/adrs/`, `.memory-bank/testing/`, or `.memory-bank/runbooks/`. Missing richer fields or absent SDD spec links do not block classic `T0` / `T1` tasks; fall back to referenced docs. For `T2` / `T3`, missing linked SDD specs are a blocker for serious work. ## Minimal Preflight Stop with an explicit handoff error if: - task record/indexed file is missing - the record `id` does not match `TASK_ID` - `tier` is missing or is not `T0|T1|T2|T3` - task `status` is `blocked`, `failed`, or `done` - any `depends_on` task is missing or is not `done` - `tier` is `T2` / `T3` and neither task richer fields nor linked feature `spec_design_links` include relevant SDD spec links Do not block `T0` / `T1` only because SDD spec links are absent. Route only by `task.tier`. Do not use legacy `risk` / `risk.level`. ## Protocol Routing Create `.tasks//` for runtime artifacts. `T0` / `T1`: use compact protocol: - `.protocols//run.md`; record tier, goal, context, plan, changes, gates, evidence, and handoff notes - `VERDICT: PASS|FAIL|BLOCKED` is a local evidence marker only, not task closure `T2` / `T3`: use full protocol: - `.protocols//context.md`, `plan.md`, `progress.md`, `verification.md`, `handoff.md` `T3`: exact marker lines are closure requirements: - `HUMAN_CHECKPOINT: done` - `ROLLBACK_RECOVERY_NOTE: present` Record whether these markers are present or still needed; do not close the task. ## Implementation Rules - Keep scope bounded to the task and its acceptance criteria. - For any tier, if the task record or linked feature contains authoritative SDD spec links, read `.memory-bank/spec-index.md` and all linked authoritative SDD specs before editing; treat them as normative inputs. - Record goal, non-goals, constraints, touched areas, and gates before broad edits. - If fan-out is needed, use narrow non-overlapping worker scopes. - Preserve unrelated changes and do not rewrite generated `shared-*` files. - Keep protocol notes factual: what changed, what was checked, where evidence is. ## Local Gates Run relevant local gates from project instructions: lint/typecheck, unit tests, and integration/e2e checks only when relevant. If a gate cannot run or fails, record command, result, evidence path, and the blocker in the protocol/handoff. Do not convert that into final task status. ## Output / Handoff Contract Finish with: - changed files summary - protocol file paths - local gates run and results - evidence paths under `.tasks//` - verification targets and risk notes for verifier/reviewer - MB-SYNC handoff notes: what should be synchronized and by whom - recommended next owner: scheduler, verifier, red-verifier, explicit standalone owner, or human ## Non-Ownership Rules `mb-execute` never: - closes tasks - writes final task status - runs `/mb-sync` - runs `/verify` or `/red-verify` - promotes, blocks, or unblocks dependents - performs scheduler transitions such as in-progress, failed, or done Schedulers (`/autopilot`, `/autonomous`) or an explicit standalone owner perform verification orchestration, final status decisions, MB-SYNC, and dependent promotion/blocking.