# Mb Status > Thin Main Branch status wrapper. Use when the operator asks what changed, what is healthy, what is stale, what to do next, or wants a daily briefing inside Claude Code. - Skill: `noontide-co/mb-status` (Agent Skill) - Install (CLI): `npx skillmds@latest add noontide-co/mb-status` - Raw SKILL.md: https://api.skillmd.com/api/skills/noontide-co/mb-status/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: noontide-co (https://skillmd.com/u/noontide-co) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/noontide-co/mb-status --- # Status Show the operator the deterministic Main Branch briefing without duplicating repo-health checks in prose. **CLI facts first:** Run `mb status --json --peek` before answering, then use that JSON as the source of truth. **Shared source:** The portable daily start/status workflow contract lives in `workflows/mb-start-status/workflow.md`. This Claude skill is the Claude Code status shell over that source. **Shared contract markers:** Keep these aligned with the shared source. Required commands: - `mb status --json --peek` - `mb start --json` - `mb doctor repair --plan` `mb doctor repair --plan` is read-only. If it exits nonzero while returning `plan_interpretation` and `actions`, treat that as findings to review, not as an opaque command failure. Required fact paths: - `money_path` - `money_path.policy` - `money_path.policy.thresholds_declared` - `money_path.active_bets` - `money_path.active_bets.unanchored` - `money_path.active_bets.over_cap` - `money_path.objects.proof.quality` - `validation.file_contracts` - `content_strategy` - `ranked_actions` - `update` - `readiness` - `readiness.dimensions.repo_runtime` - `readiness.dimensions.business_memory` - `drift.items` - `runtime.codex_cli` - `runtime.claude_code` - `since_last_check` - `journal` - `checkpoint` - `onboarding` - `integrations` - `github` - `topology.repo_boundary` - `brain.bets` - `brain.bets.active` - `brain.bets.due_soon` - `brain.bets.overdue` - `brain.bets.exit_criteria` - `brain.bets.exit_criteria.missing` - `brain.bets.exit_criteria.triggered_failure_signals` - `brain.bets.exit_criteria.triggered_double_down_signals` - `vocabulary` Approval gates: `updates_repairs_migrations`, `file_writes`, `checkpoint`, `provider_mutation`, `publishing_or_spend`, `customer_contact`, `private_data`, `destructive_operations`, and `status_marker`. Public/private boundaries: `no_secrets`, `no_raw_provider_exports`, `no_customer_member_data`, `no_private_runtime_settings`, and `no_raw_finance_legal_records`. Core route: status facts first, runtime mismatch gates before business routing, one owner-facing recommendation, business language first, and explicit approval before mutating the status marker or doing durable writes. ## Workflow 1. Confirm you are in the business repo. If not, ask the operator to `cd` into the business repo or pass the repo path. 2. Run: ```bash mb status --json --peek ``` 3. Treat the JSON as the source of truth for setup, update, drift, GitHub, onboarding, integrations, team, bets, journal activity, since-last-check, readiness, `readiness.dimensions.repo_runtime`, `readiness.dimensions.business_memory`, vocabulary, content_strategy, money_path, validation.file_contracts, and ranked actions. 4. Summarize the top `ranked_actions` first. For each one, include: - title - command or slash command - reason - cited signal summaries 5. Then summarize only the sections that matter for the operator's question. Use `money_path` when the question is about the path from customer progress to offer, proof, CTA, channel, push, playbook, page readiness, or outcome feedback. Keep the language evidence-based: legible, supported, connected, instrumented. Do not say the offer is good, bad, likely to convert, or ready to win. Use `validation.file_contracts` when the question is about a file that exists but lacks the business shape needed for the next workflow. Route offer-shape gaps to `/mb-think` and ask before editing durable offer files. Use `content_strategy` when the question is about content strategy health, layered channel/account/person files, stale platform rules, or disconnected content layers. Do not infer that health by parsing markdown yourself unless status says the section is unavailable. Use `brain.bets.active`, `brain.bets.due_soon`, `brain.bets.overdue`, and `brain.bets.exit_criteria` for active, due-soon, overdue, missing-exit, triggered kill, triggered double-down, close, update, and narrate moments before inventing bet state from prose. Use `topology.repo_boundary` when the operator is deciding whether work belongs in this business repo, a separate business repo, or a child repo. If `vocabulary.terms.push` defines display words, use them in operator-facing prose without changing current paths, frontmatter, JSON keys, validator rules, or command names. Use `team` facts and GitHub activity `author_display` / `author_known` fields when naming people; keep unknown contributors as handles. Do not re-run shell probes that duplicate status facts. For "what changed?" or "what happened since last time?", answer from `since_last_check.journal` first, then top-level `journal` for recent context. 6. If provider readiness is the question, use `integrations.github` and `integrations.providers` from status first. If the operator needs choices or repair commands, run: ```bash mb connect plan mb connect doctor --json ``` Summarize GitHub, Cloudflare, Google/Workspace, Meta Ads, and Apify as numbered business choices. Use the CLI's `next_command` or `repair_command`; do not ask the operator to paste tokens into files or public issue text. ## Mutating The Last-Check Marker `--peek` is the default inside this skill because a conversation may inspect status before the operator is ready to record a daily check. If the operator explicitly says this is the daily check-in and wants it recorded, run: ```bash mb status --json ``` Use the new report for the answer. ## Privacy Respect each action and signal's `safe_to_share` field. If `safe_to_share` is false, keep evidence local to the conversation and do not suggest pasting it into public GitHub without review.