Prompt surfaces

Construct has one public prompt surface and several internal prompt-adjacent layers.

Understanding the split tells you where to look when something behaves unexpectedly and where to customize when you want to change Construct's voice or behavior.

Public vs internal

Public prompt surface:

• personas/construct.md is the sole public persona and the only user-facing entry surface.

Internal execution surfaces:

• specialists/prompts/cx-*.md are internal specialist prompts used only through Construct's routing.
• skills/roles/*.md are internal role overlays that encode anti-patterns, counter-moves, and self-checks.
• commands/**/*.md are command prompt assets that support specific workflows but do not replace the public persona.

offline-only regression surfaces:

• examples/** contains shipped example fixtures for regression, evaluation, and future harnesses.

Runtime contract

At runtime:

• the user talks to Construct
• Construct classifies the request and routes work internally when needed
• when a request arrives as a file in inbox/, classifyRdIntake writes a triage packet that names the owner persona and the recommended chain (see intake and triage)
• per dispatched specialist, buildContextPacket (role-aware context router) selects only the artifact kinds that role prioritizes within an explicit token budget: unrelated artifacts are omitted with a stated reason
• specialists and role overlays are implementation detail, not peer user-facing personas

The routing contract lives in code and prompt policy, not in the examples corpus.

File responsibilities

• personas/construct.md

  • public behavior contract
  • approval boundaries
  • routing discipline
  • quality gates

• specialists/prompts/cx-*.md

  • internal specialist voice and task posture
  • local constraints for that specialist
  • references to the relevant role overlay and domain skills

• skills/roles/*.md

  • reusable role anti-patterns and self-checks
  • shared behavioral guardrails reused across multiple specialists

• examples/personas/construct/**

  • public persona fixtures for Construct behavior

• examples/internal/roles/**

  • internal role fixtures for high-leverage routed behavior

Capability-tiered composition (local models)

The persona is authored once but rendered at a size matched to the model that will run it. Each ## section in personas/construct.md carries an inline <!-- cx:prio=N --> marker (the preamble is implicit prio 1); lib/persona-sections.mjs emits only the sections at or below a capability tier — floor (prio 1, must-keep: identity, anti-fabrication, commit approval, escalation, loop guard), mid (prio ≤ 2), full (all). Markers are metadata, stripped on every emit path, so no model ever sees them and the word-cap guard ignores them.

The tier is keyed to capability, not the context window. resolveCapabilityTier in lib/model-router.mjs maps cloud models to full (cloud configs are never slimmed), a COLLAPSED local probe verdict to floor, a local model ≥24B to mid, and smaller or unknown local models to floor. The reasoning: once the cx32k Modelfile variants set the real num_ctx, the full persona fits even an 8k window — the binding constraint on a small model is instruction-following, not tokens (see ADR-0038, ADR-0032).

For local hybrid setups this is paired with an architect/editor split. When the fast tier is local, sync emits a second construct-local agent pinned to it (a subagent with a tier-sized prompt, a tightened tool surface, and a task permission limited to handing off to construct). It executes bounded edits on the cheap local model and escalates planning, multi-file reasoning, and risk judgment to construct — which keeps the user's chosen model and is never pinned. Escalation is prompt-driven, because OpenCode has no runtime model-swap hook (ADR-0038).

Visual deliverables

Construct treats visual artifacts as real deliverables, not prose-only placeholders.

• construct routes the request and keeps the user-facing contract coherent
• cx-designer owns wireframes, low-fi layouts, product-facing diagrams, and presentation-grade packaging
• cx-architect joins when a diagram expresses system boundaries, contracts, sequencing, or dependency structure
• cx-product-manager or cx-operations may own the underlying written content, but a visual deck remains a visual deliverable when explicitly requested

Request visual work the same way you request any task: describe what you want and construct routes to the right specialist.

Why this split exists

The split is intentional:

• prompts stay lean enough to preserve token budget and avoid drift
• role overlays hold reusable failure-mode guidance instead of duplicating it in many prompt files
• examples stay outside runtime prompts so regression assets can grow without bloating execution context

Terminology

Use these terms consistently:

• persona: public prompt surface
• specialist prompt: internal specialists/prompts/cx-*.md surface
• role overlay: internal skills/roles/*.md guidance layer
• example fixture: offline regression/eval case under examples/**

Avoid calling internal specialist prompts and role overlays "core public surfaces".