System Prompt — Project Bootstrap (ALWAYS LOAD)

vmblu

Vizual Model Blueprint (vmblu) is a file format, graphical editor, and toolchain that maintains an explicit, runnable architecture of a software system (the blueprint).

vmblu models software as interconnected nodes that communicate by sending messages through pins. Humans and LLMs interact with the blueprint directly; the graphical editor is a visualization and inspection tool layered on top of it.

Authoritative source of truth

The single authoritative source for the architecture is the blueprint file: <model-name>.mod.blu

This file is:

• validated by blu.schema.json in the
• semantically defined by blu.annex.md

All other artifacts (visual layouts, generated applications, profiles, tests, MCP files) are derived from the blueprint and must not be edited manually, except where explicitly allowed (for example, the test model file).

CLI overview

vmblu provides a CLI that exposes commands for scaffolding, generating, testing, and profiling vmblu applications:

• vmblu init
• vmblu make-app
• vmblu make-test
• vmblu profile

Task-specific details live in the role prompts.

File roles and authority

• <model-name>.mod.blu The authoritative vmblu blueprint (architecture).

  • Format: blu.schema.json
  • Semantics: blu.annex.md

• <model-name>.mod.viz Editor-only visualization and layout.

  • Format: viz.schema.json
  • Derived artifact: do not edit
  • Do not consult unless explicitly asked

• <model-name>.src.prf Auto-generated profile of message handlers and transmissions found in source code.

  • Format: prf.schema.json
  • Generated by: vmblu profile <model-name>.mod.blu
  • Consult-only; do not edit
  • If profile information conflicts with the blueprint, the blueprint is authoritative

• <model-name>.app.js Generated application entry point. Do not edit manually.

• <model-name>.mcp.js Generated MCP tool description. Do not edit manually.

Hard rules (non-negotiable)

• Carefully read blu.schema.json and blu.annex.md before modifying a blueprint.
• All modifications to <model-name>.mod.blu must strictly follow the schema.
• Do not rename nodes, interfaces, or pins unless explicitly instructed. Renames are breaking architectural changes.
• Use the types section for payload structure. Pin contracts should reference types; do not duplicate payload shapes elsewhere.
• An interface name may be empty ("") for small nodes (at most one per node).

Role routing

Only load one additional role prompt, depending on the task:

• For architecture changes, node implementation, app generation, or profile work: load develop.prompt.md.
• For test-model generation, mirrors, sequencer, running tests, or producing results logs: load test.prompt.md.