SkillsAdd

mrvladd-d/memobank

mb-execute

Implementation handoff skill for one TASK-* using tier-selected protocol files, local gates, evidence, and explicit verification/sync handoff.

First seen Mar 5, 2026

Installation

$ npx skills add mrvladd-d/memobank --skill mb-execute
View on skills.sh ↗ GitHub repository ↗

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

execute-plan Similar name
buiducnhat/cobrew

Execute an approved implementation plan exactly and safely. Use for ExecPlan-style plan executi…

549 installs
execute Similar name
alirezarezvani/claude-skills

/cs:execute <decision> — Generate a 90-day execution plan with weekly milestones, DRIs, and che…

385 installs
gsd-execute-phase Similar name
open-gsd/gsd-core

SDD phase execution — execute all plans in a phase with dependency-aware wave parallelization

264 installs
plan-execute Similar name
longranger2/claude-gpt-workflow

Use when the user says "/plan-execute", "plan execute", "implement plan", or "execute plan" and…

246 installs
hyperexecute-skill Similar name
lambdatest/agent-skills

Operates HyperExecute end-to-end for TestMu AI/LambdaTest cloud test debug failures, and wire C…

204 installs
st-execute-task Similar name
e0ipso/strikethroo

Use when the user asks to run, execute, or implement one specific task ID within a Strikethroo …

150 installs

Also in this package

Other skills from mrvladd-d/memobank · top by installs.

npx skills add mrvladd-d/memobank
cold-start 50 mb-garden 41 mb-init 41 mb-map-codebase 40 mb-verify 39 mb-harness 39 mb-review 39 mb-from-prd 39 mb-red-verify 6 mb-analysis 6

Browse all from mrvladd-d/memobank

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 55
License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 6,857 B
  • docs SUMMARY.md 160 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 41 installs

SKILL.md

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 HUMANCHECKPOINT: done and ROLLBACKRECOVERY_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_ID>.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: sourceartifacts, normativeinputs,

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

specdesignlinks 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/<TASK_ID>/ for runtime artifacts.

T0 / T1: use compact protocol:

  • .protocols/<TASK_ID>/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/<TASK_ID>/context.md, plan.md, progress.md,

verification.md, handoff.md

T3: exact marker lines are closure requirements:

  • HUMAN_CHECKPOINT: done
  • ROLLBACKRECOVERYNOTE: 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/<TASK_ID>/
  • 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.