Mb Execute logo

Mb Execute

Community
mrvladd-d
mb-execute

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

Overview

Publishermrvladd-d
Repositorymemobank
Skill namemb-execute
Stars
56
Forks
11
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by mrvladd-d on GitHub. Read the source before you install it.

Installation

Install the Mb Execute AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/mrvladd-d/memobank/tree/main/skills/mb-execute
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/mrvladd-d/memobank.git /tmp/memobank
mkdir -p .claude/skills
cp -r /tmp/memobank/skills/mb-execute .claude/skills/mb-execute
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Mb Execute in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Mb Execute on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Mb Execute is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

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_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: 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/<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
  • 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/<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.

Frequently asked questions

What does the Mb Execute AI skill do?

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

Why use Mb Execute on TypingMind?

Because you install it once and use it with any model. Mb Execute is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Mb Execute in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/mrvladd-d/memobank/tree/main/skills/mb-execute. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Mb Execute?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Mb Execute?

As many as you like. As long as a model supports skills, you can use Mb Execute with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Mb Execute AI skill free?

Yes. It is published on GitHub by mrvladd-d under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇