From mainbranch
Detects repository state and user intent to route to appropriate skills or CLI commands for setup, sync, repair, or launch.
How this skill is triggered — by the user, by Claude, or both
Slash command
/mainbranch:mb-startThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Single entry point: detect business state, intent, save/sync posture, and the smallest useful next route.
Single entry point: detect business state, intent, save/sync posture, and the smallest useful next route.
This skill routes; it is not the worker for coordinated output. Use
references/router-and-language.md as the
business router before presenting a menu.
Business language comes first. Say saved checkpoint, unsaved local work, catch
up, sync, reconcile, shared repo, workspace, and provider readiness. Keep raw
git terms, checkpoint ids, branch names, origin, ahead, behind, rebase,
and commit out of the first response unless the user asks for technical detail
or the exact command must be shown.
When summarizing repo state, count pushes/ records, flag campaigns/ as
legacy only, and use core/vocabulary.md display words (real paths in commands).
CLI facts first: Once the business repo path is known, run
mb status --json --peek before asking setup or routing questions. Treat JSON
as source of truth for update severity, readiness, drift, onboarding,
integrations, GitHub, team, bets, dirty git, since-last-check,
content_strategy, money_path, validation.file_contracts, and
ranked_actions. Use GitHub author_display/author_known when naming
people. Parse the full JSON once; do not slice status output with head or
sed.
Shared source: The portable daily start/status workflow contract lives
in workflows/mb-start-status/workflow.md; this skill is its Claude shell.
Shared contract markers: Keep these aligned with the shared source.
Required commands:
mb status --json --peekmb start --jsonmb doctor repair --plan
Required fact paths:money_pathmoney_path.policymoney_path.policy.thresholds_declaredmoney_path.active_betsmoney_path.active_bets.unanchoredmoney_path.active_bets.over_capmoney_path.objects.proof.qualityvalidation.file_contractscontent_strategyranked_actionsupdatereadinessreadiness.dimensions.repo_runtimereadiness.dimensions.business_memorydrift.itemsruntime.codex_cliruntime.claude_codesince_last_checkjournalcheckpointonboardingintegrationsgithubtopology.repo_boundarybrain.betsbrain.bets.activebrain.bets.due_soonbrain.bets.overduebrain.bets.exit_criteriabrain.bets.exit_criteria.missingbrain.bets.exit_criteria.triggered_failure_signalsbrain.bets.exit_criteria.triggered_double_down_signalsvocabulary
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.
Continuity facts: Use since_last_check.journal, top-level journal,
GitHub activity, and checkpoint from status to explain "where we left off."
Do not run raw git log unless status says journal facts are unavailable.
If core/operations/pulse/ exists, read today's log/<date>-*-pulse.md and
carry its ONE action into the session open (offer the pulse skill if missing).
Saving progress: mb checkpoint --plan --json, validate, then after approval
mb checkpoint --message "..." --yes.
Provider facts first: When setup or routing depends on GitHub, Cloudflare,
Google/Workspace, Meta Ads, or Apify, read the status integrations facts
first; for a provider choice or repair explanation, run mb connect plan or
mb connect doctor --json and use the cited next_command/repair_command.
Never ask for tokens or setup in prose before the CLI names the missing step.
Paid-traffic facts first: When routing a paid-traffic minisite, Google Ads,
GTM, retargeting, or "ready to launch" request, load
docs/google-ads-gtm-conversion-rubric.md; with a known site repo, run
mb site check "$SITE_REPO" --business-repo "$REPO_PATH" --json before any
/mb-site or /mb-ads launch advice. blocked = stop; ready_for_preview =
preview-only; ready_for_operator_review = manual review first. Never publish
GTM, mutate Google Ads, upload conversions, or ask for tokens in prose; never
invent ready_for_launch (valid states: missing, blocked,
ready_for_preview, ready_for_operator_review, ready).
Offer launch path: When the operator asks to launch an offer, use
references/launch-orchestration.md:
keyword-gate with /mb-think, create/select a launch push, build/check the
lander with /mb-site, ads with /mb-ads, checkpoint approved artifacts.
Primitive routing: When a live idea could be a bet, offer, push, proof, or
decision, load .claude/reference/business-primitives/offer-bet-push-proof.md
and .claude/reference/business-primitives/setup-patterns.md; route by business
meaning before suggesting file moves.
Data/ops surface routing: whose-data questions → mb spine declare/
show; money-path-overnight worries (real money flowing unattended) →
mb canary init; recurring daily business read → mb pulse init; "show me
the business" → mb dashboard open; scripts reading credentials →
mb connect token (never echo values). Full map: mb-help
references/cli-surfaces.md — business answer first; triggered surfaces stay triggered.
Books/finance routing: When the user mentions bookkeeping, books, finance,
accounting, ledgers, statements, P&L, chart of accounts, tax, payroll, hledger,
or a restricted finance child repo, run mb books check "$REPO_PATH" --json
before drafting files. Keep raw private finance records out of the
team-safe hub repo; use the books contract, storage_mode, and topology
visibility (restricted or local_only) to route raw records.
Slug/destructive-operation guardrails: Load
.claude/reference/business-primitives/slug-conventions.md before naming
business objects or topology entries, and
.claude/reference/business-primitives/destructive-operations.md before
renaming, deleting, merging, archiving, migrating, publishing, mutating
providers, spending money, changing topology, or creating checkpoints.
CWD-first wins. If current Main Branch markers exist in CWD, confirm the repo and
continue. If CWD looks like old repo shape, keep CWD as migration input and run
mb status --json --peek plus mb doctor repair --plan before discovery.
Only ask which repo when CWD is not a business repo. In fallback mode, list all
validated recent_repos, include a switch option, and do not treat the saved
default as automatic. Treat legacy config selections as session-scoped unless a
current mb command exposes an explicit persistence path. Do not write
default_repo into ~/.config/vip/local.yaml, and do not create or update
.vip/config.yaml.
Always use numbered lists for multi-choice (repo selection, skill routing, launch blockers, provider setup). One active choice namespace per turn: if top recommendations are numbered, use offer slugs or letters for secondary choices; the same number must never mean two actions — ask when ambiguous.
mb status --json --peek; status facts gate updates, repair, readiness,
onboarding, ranked actions, and continuity.core/
before asking bounded missing-profile questions./mb-think, /mb-bet,
/mb-ads, /mb-organic, /mb-site, /mb-wiki, /mb-help, or
/mb-end. Conversion-script requests route through the owning workflow,
not a standalone skill.After repo selection, run:
mb status --json --peek
ranked_actions is the deterministic list of one to three business moves.
Surface the first action as the recommendation, including its reason and
cited signal summaries.brain.bets.active, brain.bets.due_soon, brain.bets.overdue, and
brain.bets.exit_criteria are the deterministic bet trigger facts. Use them
for active, due-soon, overdue, missing-exit, triggered kill, triggered
double-down, close, update, and narrate moments before inventing bet state
from prose.money_path maps customer progress, offer, proof, CTA, channel, push,
playbook, page readiness, and outcome feedback. Use it as evidence; cite
money_path.objects.proof.quality facts instead of claiming an offer will
convert.validation.file_contracts, content_strategy, readiness, and
drift.items map file gaps, content layers, setup gates, and repair commands.onboarding.summary and onboarding.checklist replace separate onboarding
probes unless the status report is unavailable.journal, since_last_check.journal, integrations, github,
measurement, and brain.bets supply continuity facts for routing.Only run a narrower fallback command such as mb onboard status --json,
mb doctor, mb validate --cross-refs, or mb connect doctor --json when status
points at that section as unavailable, degraded, or needing repair.
Use the update section from mb status --json --peek. Do not bury available
updates inside a general status wall. Users on stale code get broken
features, and normal operators will miss a one-line version note.
If update.severity is required or the top ranked action is an update action,
run the cited update command. When status does not cite one, use:
mb update --repo . --json
Then run mb status --json --peek again before routing.
If update.severity is recommended, stop there. Use update.release_notes_url
or update.update_check_command to answer what changed or run a fresh dry-run.
Ask whether to update now, then rerun mb status --json --peek before routing.
Use references/router-and-language.md for
operator-facing wording and fallback details.
The user starts Claude in their business repo. Check CWD first before falling back to config.
Quick gist:
1. test -d "core" → THIS IS the business repo. Skip to config.
2. old Main Branch repo markers without current markers → old repo; run
`mb status --json --peek` and `mb doctor repair --plan` from CWD.
3. test -f ".claude/skills/mb-start/SKILL.md" → user is in a Main Branch source checkout; migrate.
4. Otherwise → fall back to `~/.config/vip/local.yaml` only as legacy
machine-local repo memory.
See references/repo-detection.md for the full flow: CWD detection, migration guidance for users in a source checkout, config loading, multi-repo selection, the discovery algorithm when no config exists, the required REPO_PATH variable, and the Main Branch wiring verification block.
Once the business repo is confirmed, use status git, checkpoint, and
since_last_check facts to explain whether work is saved locally, unsaved
locally, synced to the shared repo, or waiting for reconciliation. Do not
blindly pull or rebase the business repo from /mb-start. See
references/router-and-language.md for the
save/sync vocabulary.
Prefer the onboarding section from mb status --json --peek. If status is
unavailable or the operator specifically asks for onboarding detail, run:
mb onboard status --repo "$REPO_PATH" --json
Use the JSON envelope as the source of truth for onboarding progress:
summary.next_recommended_action tells you what to do nextchecklist[].missing_inputs names the bounded inputs to collectprofile.team_size distinguishes solo, small-team, and larger-team setupboundaries.defer_until_needed names data to avoid collecting in the first context windowIf core_reference is pending, collect only enough to draft the missing core
files. Do not ask for full finances, credentials, raw customer/member exports,
or exhaustive operations details before the core files exist.
If the repo already has substantive current core/ files, read and summarize
those facts before asking onboarding questions. Mine core/offer.md,
core/audience.md, core/voice.md, core/soul.md, and core/proof/ when
present; include core/offers/*/offer.md names in multi-offer repos. Propose
answers for bounded missing inputs from existing repo truth, cite which files
informed the proposal, and ask the operator only to confirm or correct the
facts that remain uncertain.
If the user's team size or current success stage is missing, ask briefly and update the plan:
mb onboard plan --repo "$REPO_PATH" --team-size solo --success-stage working
Check provider and MCP readiness only for skills the user might invoke. See mcp-preflight.md.
Start from CLI facts:
mb status --json --peek
mb connect plan
mb connect doctor --json
Use the status and connect JSON before checking runtime tool presence. The operator-facing pattern is:
"This action needs [business capability].
- Set up [provider] now —
[exact command]- Skip for this session — [specific limitation]"
Full research tool detection still happens in /mb-think — deferred to when user actually needs research. This keeps /mb-start fast and avoids checking tools user might not use this session.
What /mb-start checks: provider readiness from mb status --json --peek
and mb connect plan, selected-skill MCPs when provider status says runtime
tools are unknown, and critical blockers such as missing config or broken paths.
Leave full research/document tool scans to /mb-think; most sessions do not
need every tool checked upfront.
If user's stated intent involves research, route to /mb-think. It will use
mb provider facts first, then detect only the runtime tools needed for the
selected research path.
Run a lightweight provider/readiness audit:
mb status --json --peek facts already gathered.mb connect doctor --json when a provider section is degraded, missing,
or selected by the operator.next_command / repair_command..vip/config.yaml.See tool-status-audit.md for the full procedure and messaging rules.
Use readiness, money_path, and ranked_actions from
mb status --json --peek before routing. The reference below is fallback detail
for gaps that status does not expose yet.
See readiness-assessment.md for complete scoring rubric, session state checks, soul health check, skill-specific requirements, and display format.
Quick summary: status readiness gates setup, repair, and output skills; fallback
scoring only fills missing detail. Adapt display to user.experience level
without making the repo feel audited or behind.
Do not read full reference files into main. Status readiness already names the
scores, files, and gaps needed for routing. The selected skill or triage agent
loads deep context. Exception: read [repo]/CLAUDE.md when present because it
is small and helps with routing tone.
Onboarding exception: When onboarding is incomplete and current core/
files already exist, read enough of those files to avoid asking for facts the
repo already contains. Keep this bounded: summarize the existing facts and ask
only for confirmation or missing profile fields.
Multi-offer context: If CLI facts or the current session identify an active offer, note it for routing; the selected skill loads the offer file.
Use the active-offer resolution contract in
.claude/reference/business-primitives/offer-bet-push-proof.md; load
setup-patterns.md and slug-conventions.md from that same directory when
setup shape or naming is unclear.
find "$REPO_PATH/core/offers" -mindepth 2 -maxdepth 2 -name "offer.md" 2>/dev/null
If core/offers is absent and core/ is also absent, do not infer the offer
from old paths; treat old shape as migration input after mb status --json --peek or mb doctor repair --plan.
No core/offers/ means single-offer mode. If offers exist, use current CLI
status facts first, never silently route from .vip/local.yaml, present choices
by slug/name when route numbers are already visible, and keep selection
session-scoped unless the operator approves a current mb persistence command.
/mb-start [offer-name] can select a validated offer for this session. all
means brand-level core/ context.
Use readiness, onboarding, drift.items, money_path, and ranked_actions
from status first. Prefer money_path.ranked_actions for path gaps unless the
top-level ranked action already incorporates it.
Fallback: check core/*.md. If CWD looks like an old Main Branch repo, run
mb status --json --peek and/or mb doctor repair --plan before routing. No folder → /mb-setup. If two or more
core files are missing/thin, route to /mb-think codify; otherwise route by
intent. Use readiness-assessment.md for
the exact fallback thresholds.
Multi-offer completeness: When status does not expose offer readiness, check
the active offer's offer.md; a thin/missing offer-specific file should route
to /mb-think.
Respect readiness gates from Step 6. If status is MINIMAL or EMPTY, do not offer output skills. If THIN, warn. See readiness-assessment.md for skill-specific requirements.
Show context: "Business: [repo name] | Offer: [active offer or 'single']"
If the user stated intent, route directly using references/router-and-language.md. If the session is open-ended, surface the top ranked action, update recommendation, top non-duplicated MoneyPath action, or compact route menu. Use references/triage-menu.md only for prioritization or deep triage.
"Help" or confused → route to /mb-help. Give quick overview first:
"Open your business folder, start Claude, then run
/mb-start. Main Branch uses thembCLI for facts and skills for judgment. Details:/mb-help."
Fresh context gets a fuller load; working context routes directly; heavy context
gets a brief warning; critical context routes to /mb-end. If legacy
~/.config/vip/local.yaml has user.experience, use it as a machine-local
fallback: beginner explains more, returning confirms quickly, expert routes
fast. If the user asks for a faster mode, offer to update local experience.
Auto-detect user intent through references/router-and-language.md. Key clusters: save/checkpoint/sync, bookkeeping/books/finance, provider/tool setup, repair/update/drift, decide/codify/research, bets, launches, sites, ads, organic, wiki, and help.
Generic "set up" is not enough to route. Use the noun: repo setup routes to
/mb-setup, bookkeeping setup runs mb books check, provider setup reads
mb connect, and decision/tool setup routes to /mb-think.
If re-invoked after compaction: use CWD and mb status --json --peek first;
read ~/.config/vip/local.yaml only as legacy fallback for repo + identity;
treat business .vip/local.yaml as audit input only, and do not write it.
npx claudepluginhub noontide-co/mainbranch --plugin mainbranchProvides a deterministic Main Branch status briefing inside Claude Code. Runs `mb status --json --peek` and summarizes what changed, what is healthy, what is stale, and ranked next actions.
Orchestrates git operations with safety tiers: read-only inline, safe writes via background agent, destructive with preflight confirmation. Manage commits, PRs, branches, worktrees, releases.
Auto-analyzes project state including tasks, source code, git conflicts, and agents to recommend 1-2 optimal skills. Use on 'what's next?' questions or /workflow trigger.