Plain-English guide to Sol Advisor

Why use Sol Advisor?

You can ask a model to "build this feature" in one prompt. Sol Advisor adds structure on top of that: it keeps one session honest about architecture and acceptance while a pinned, verifiable worker does the typing.

The payoff

What structure buys you

โ‡†

Separation of concerns

The architect doesn't also implement and review its own work in the same breath. Roles are explicit.

๐Ÿ”’

No silent fallback

If the expected role, model, or reasoning effort can't be confirmed, the lane stops. You don't discover later that a weaker model quietly did the work.

โŠ˜

Fresh review

Acceptance runs in a fresh context, so the reviewer isn't the orchestrator rubber-stamping its own output.

๐ŸŽš๏ธ

Right lane per risk

Use the native Terra / High lane for routine work, or opt into user-visible Luna / Max tasks when you want trackable, visible implementation.

๐Ÿงพ

Routing evidence

Spawn metadata (and a read-only inspector when needed) prove which role and model actually ran. Public and local evidence must agree.

โœ…

A real acceptance gate

The session can't report done until the Sol reviewer returns ship. Fix-first and rethink are first-class outcomes.

Comparison

Hand-rolled prompt vs. Sol Advisor

AreaA single "build it" promptSol Advisor
Who reviewsThe same session that wrote itA separate, fresh-context Sol review
Model for implementationWhatever the session defaults toPinned Terra / High (or Luna / Max)
If the model is wrongOften silentThe lane stops with an error
Evidence of what ranNoneSpawn metadata + read-only inspector
AcceptanceInformalExplicit ship / fix / rethink gate
Visibility (Luna)n/aUser-visible tasks you can monitor
Note: this is an independent framing of the project's design. See the official repository for the authoritative description.
Try it โ†’ Read the FAQ