Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jsagir/mindrian-os-plugin/llms.txt

Use this file to discover all available pages before exploring further.

When you need a fast read on the room’s current state, /mos:status shows the governing thought per section plus health glyphs. The 10-second status check — run it after filling a section, before grading, or any time you need a grounded sense of where the venture stands.

Usage

/mos:status
/mos:status <section>
/mos:status --stale-only
InvocationWhat it shows
/mos:statusEvery section in the active room
/mos:status market-analysisOne section’s full governing thought, arguments, MECE check, artifacts, and identity
/mos:status --stale-onlyOnly sections flagged stale (artifacts newer than the MINTO governing thought)

What happens

1

Run the renderer

Larry runs scripts/mos-status.cjs against the active room. The renderer reads each section’s MINTO governing thought and reasoning_health_score from lib/core/folder-memory.cjs readTriple, with cache hits served through lib/core/statusline-cache.cjs. No Brain queries. No SIGNAL sweeps. Pure local room read.
2

Health glyph assignment

Each section gets a Canon Part 2 health glyph based on the MINTO reasoning health score and whether a governing thought exists at all.
3

Render the Shape E report

The renderer emits the full Body Shape E (Action Report): header, per-section rows, summary line, and next actions. Larry presents the output verbatim — no added commentary, no emoji.
4

F.1 next-move selector

The report closes with a single recommended next action as an F.1 selector, based on what the room state reveals.

Room health glyphs

GlyphMeaningCondition
checkHealthyGoverning thought present, reasoning_health_score ≥ 0.7
warnNeeds attentionPresent, but score between 0.4 and 0.7
lowWeakPresent, but score below 0.4
--Empty or staleNo MINTO yet, or artifacts are newer than the governing thought
Stale sections carry a (stale: reason) suffix. Empty sections carry (no MINTO yet). The renderer under-promises — it never fakes content.
What “room health” means in practice: section coverage (how many sections have a governing thought), evidence quality (the reasoning_health_score distribution), and whether any sections are stale. A healthy room has check on 4+ sections and no low sections going into a grade.

Example output

Running /mos:status on a five-section room:
/mos:status — room: my-venture

check  market-analysis:      "TAM of $12B is bottom-up defensible"
warn   problem-definition:   "IT integration is the wedge"
low    team-execution:        "Team of 3 with biotech + IT mix"
--     business-model:        "Freemium plus seat-based" (stale: artifacts_newer_than_minto)
--     competitive-analysis:  (no MINTO yet)

5 sections, 4 filled, 1 stale, median reasoning health 0.55

Next: /mos:reason <section> to regenerate stale MINTOs
Or:   talk to Larry about a specific section

Session-aware view

/mos:status shows section health as it stands now — a snapshot of what has been filed, whether pre-existing or added in this session. Use it:
  • After a methodology run to confirm the artifact was filed and the governing thought updated
  • Before /mos:grade to see which sections are weak before Larry scores them
  • After a stale warning to identify which sections need their MINTO regenerated with /mos:reason <section>

Example

/mos:status
/mos:status — room: supply-chain-venture

check  problem-definition:   "Manual reconciliation creates 3-day reporting lag"
check  market-analysis:      "Mid-market logistics: $4.2B addressable, 14% CAGR"
warn   solution-design:       "API-first middleware layer" (reasoning_health: 0.51)
--     competitive-analysis:  (no MINTO yet)
--     business-model:        (no MINTO yet)
--     team-execution:        (no MINTO yet)

6 sections, 2 check, 1 warn, 3 empty, median health 0.48

Next: /mos:reason competitive-analysis
/mos:status solution-design
/mos:status — section: solution-design

Governing thought: "API-first middleware layer"
reasoning_health_score: 0.51  [warn]

Arguments
  - Middleware reduces integration cost vs. rip-and-replace
  - REST/webhooks cover 80% of target stack
  MECE check: NOT exhaustive — no argument for data-residency constraints

Artifacts (3)
  - solution-design/arch-sketch-2025-01-14.md  [pipeline: discovery, stage: 3]
  - solution-design/api-spec-draft.md
  - solution-design/integration-assumptions.md

Stale: No

Next: /mos:reason solution-design — add data-residency argument to strengthen health score

Pairs well with

/mos:grade

Score the room after checking health. Status tells you what’s weak; grade tells you by how much.

/mos:suggest-next

Turn the health picture into a ranked recommendation for what to fill next.

/mos:pipeline

Run a methodology chain to fill the empty sections status surfaces.

Build docs developers (and LLMs) love