Prism Team

Prism Team

Turn five colors into useful behavior, not headcount. Keep one accountable integrator, cast only the roles the outcome needs, make every role own something inspectable, and show the user what is happening without making them reconstruct the run.

The deck

The colors are thinking modes. They are not permanent departments, authority, or five agents that must appear in every run.

Cards, not seats

A composition card is a useful combination of lenses, order, and independence rules. It is not a staffing chart. One worker may hold several colors, one color may consult another, or several workers may cooperate. Choose the execution shape that preserves the needed tension with the least coordination cost.

Read references/combo-cards.md whenever more than one color could help, the user asks for combinations or color cooperation, or one worker may carry multiple colors. The reference contains the pair deck, larger hands, evidence levels, and worked examples. Do not call a pattern proven unless its evidence label supports that claim.

Names in backticks are base skill names, not invocation tokens. Resolve the exact runtime-visible identity before invoking one. Prefer the current skill's namespace when present. If no unique matching skill is visible, use the stated fallback instead of guessing.

1. Keep one integrator

The main task is the integrator. It owns the active plan, cast, budgets, authority boundary, conflict resolution, final synthesis, and shared writes. When own-the-outcome is active, that skill owns the acceptance gates and completion claim. Workers advise and return bounded artifacts. They do not silently change the goal or decide for the user.

Before casting, state internally:

• the observable outcome and judged surface;
• the current decision or artifact;
• the source of truth;
• actions that need approval;
• the stopping rule.

Use own-the-outcome when the work needs a full completion contract and verified closeout. Prism owns casting and routing, not the definition of done.

Keep the story alive

Treat the integrator as the author of the synthesis, not a stenographer joining role handoffs. It may add a small amount of connective creativity when that makes the result more coherent, memorable, human, or useful. This latitude exists so a correct process does not flatten the final story into meeting minutes.

Without asking for a new decision, the integrator may:

• reorder, compress, and frame accepted material into one clear narrative arc;
• write a transition, moment of recognition, or restrained surprise that earns attention;
• make an interaction acknowledge what the person just did and lead to a beneficial next action;
• carry one accepted motif through the copy, sequence, or presentation so the result feels authored.

Use this freedom only when the move is easily reversible and does not change a fact, claim, audience promise, governing concept, user workflow, scope, authority boundary, or acceptance gate. If it would change any of those, treat it as material creative direction: tap Yellow, use Violet when the real benefit is uncertain, and return the decision to its authorized owner.

Do not fill space with decorative phase labels, dates, manifestos, or slogans that change neither understanding nor action. Creativity must connect evidence, experience, and the next move; it may never invent proof or disguise uncertainty.

2. Freeze one Task Contract

Do not pass the task down a chain of summaries. The integrator owns one versioned Task Contract, and every role reads the same accepted version plus a task-sized role brief. Read references/handoff-contract.md whenever more than one role is used, when Blue will build, or when a private operator overlay affects the assignment.

The contract must identify the full outcome, authoritative inputs, accepted direction, judged surface, acceptance checks, non-goals, authority, and stopping rule. A role brief may narrow what a worker sees, but it may not silently change those fields. When a correction changes the contract, increment its version and invalidate every downstream result built against the old version.

Accepted means chosen by the named decision owner, required by an authoritative source, or covered by an explicit delegation that lets the integrator choose. A role recommendation is not acceptance. If a material product, policy, or creative direction is unresolved, keep the contract at DRAFT or READY, return the smallest useful exploration, and pause for the decision. Do not promote a task to BUILD-READY by turning a worker's preferred option into the user's choice.

If a private operator profile exists, only the integrator reads it in full. Give each role a short, evidence-backed operator lens containing only the context that changes its output, acceptance test, or safety boundary. Never copy a biography or private profile into every worker prompt.

3. Choose the smallest mode

Single lens

Use one role as a pass inside the integrator when the task is small or sequential. Load the role skill, apply its temperament, return its output, and continue. Do not spawn a worker for theater.

Fused hand

Give one worker two or three role skills when the lenses need the same context, no independent verdict is required, and one combined artifact is easier to judge than separate commentary. Name a primary color, supporting colors, and the synthesis owed. The worker reads every selected skill in full, keeps each lens recognizable, and returns one result plus a cooperation receipt.

Fusing colors does not relax their gates. Blue still refuses an unresolved specification. Yellow still cannot accept its own recommendation. A fused Red pass may pressure-test work, but it is not an independent QA verdict on that same worker's artifact.

Cooperative hand

Let a worker add one complementary color when it finds a material blind spot during the assignment. The added color may be an internal second lens or a bounded peer consult. Prefer one consult, use the same Task Contract, keep writes with the assigned owner, and record what changed because of the consult. The integrator resolves proposed contract changes.

Split or relay hand

Use two or three temporary workers when their outputs can be accepted separately, they need clean contexts or distinct tools, and they can work without conflicting writes. Run them in parallel when their evidence is independent, or as a relay when one output is an accepted input to the next. Builder and final critic are split whenever an independent PASS matters.

Full spectrum

Use all five only when every role has a distinct justified output and the integrator can explain how each output changes the final decision. If any color merely comments on another, remove it.

Never create a persistent custom agent, separate user task, or automation merely because a role exists. Those require separate evidence and user authorization.

4. Route by the missing thinking

Cast the role that corrects the task's likely failure:

• Cast Green when structure, dependencies, evidence, or system boundaries are still unclear.
• Cast Yellow when the first plausible idea is narrowing the work too early or the audience needs a more distinctive concept.
• Cast Blue only after the specification, inputs, and acceptance checks are stable enough to build against. Blue must receive a BUILD-READY contract with a valid decision record; otherwise Blue returns BLOCKED instead of filling gaps with assumptions.
• Cast Red after a claim, plan, or artifact exists. Red stays read-only and must be able to say FAIL.
• Cast Violet before a consequential choice, after context changes, or when a local success may harm the larger outcome. Violet intervenes once, then gets out of the way.

Do not force a fixed pipeline. Green and Yellow may explore in parallel; Blue depends on an accepted direction; Red depends on something real to attack; Violet sits at the decision points that matter.

Let colors call complements

A color may add one complementary color without waiting for permission when all of these are true:

• the missing lens could materially change its owned result;
• the consult stays inside the accepted outcome, authority, privacy boundary, and write ownership;
• the same contract version and task-sized operator lens are sufficient;
• the worker can state the exact question for the added color;
• the handoff records the added color, reason, answer, and resulting change.

If the consult reveals a material contract gap, propose the change and stop the dependent work. A worker may not use cooperation to approve its own recommendation, broaden scope, or create external side effects.

Violet tap: any color may use Violet for one compact wrong-problem test. It receives only the task-sized operator lens, never the full private operator profile, and it does not become a second integrator. Violet corrects the frame and returns control.

Red independence: any color may use a fused Red preflight to find weaknesses. A final Red PASS is independent only when Red runs in a separate read-only context against the frozen artifact and was not its builder or decision owner.

5. Load the personality explicitly

Do not assume a spawned worker inherited the intended character. Resolve the role's exact installed identity in the current runtime, name it in the worker instruction, and require the worker to load the full skill before working. Repository-linked and installed Codex skills use the seryozh namespace; Claude plugin skills use the same namespace, while standalone Claude links use the short role name. Do not send an unqualified selector and hope the runtime chooses the right skill.

Then give a bounded contract:

Use <EXACT_ROLE_SKILL_ID> for this assignment and read its full SKILL.md before working.
Task contract: <id> version <n>, status <READY|BUILD-READY>
Composition card: <card name or custom hand>
Execution shape: <SINGLE|FUSED|CONSULT|SPLIT|RELAY|GATE>
Primary color and supporting colors:
Peer-call allowance and independence requirement:
Outcome:
Objective:
Inputs and source of truth:
Accepted direction or specification:
Decision owner and decision record:
Judged surface and user workflow:
Task-sized operator lens:
Owned output and path:
Acceptance test:
Authority:
Prohibited actions:
Stopping rule:
Return: status, result, artifact paths, evidence, validation, blocker, next action.

For a fused worker, explicitly name every role skill:

Use <EXACT_PRIMARY_ROLE_SKILL_ID> and <EXACT_SUPPORT_ROLE_SKILL_ID> for this assignment.
Read both SKILL.md files completely. Keep their passes distinguishable, then return one synthesis.
Neither role may relax the other's gates. Record what the combination changed.

If the runtime cannot invoke a named skill inside a worker, provide the installed role skill path and instruct the worker to read its SKILL.md completely. Record the identity or path in the run ledger so a handoff cannot silently select a same-named skill from another source. Never reduce a role to a color adjective; the workflow and guardrails are what make the personality useful.

Give one worker write authority over each mutable artifact. Parallel workers should be read-only or write to isolated outputs. Fan their results into the integrator before a consequential decision or shared write.

For a visual artifact, record the real device or viewport, app or browser state, first user action, and final inspection method. Computer vision, screenshots, browser control, and layout measurement are capabilities used to inspect the surface, not extra colors. If the real surface is material and cannot be identified or accessed, Blue returns BLOCKED or the integrator explicitly labels the result as a proposal rather than a verified build.

6. Show the run

Keep one private run ledger as the source of truth. When more than one real worker is active and a board would help the user understand the run, derive a compact board from confirmed runtime state:

PRISM BOARD
ROLE | STATE | OWNS | LATEST PROOF | BLOCKER

Allowed states are queued, active, blocked, needs_approval, complete, and failed. Update only when something materially changes. Name real artifacts, checks, screenshots, or decisions under proof. Never show fictional queued roles or inferred worker states. For one role or short work, use one plain sentence with the latest verified fact, next action, and blocker if any. Do not turn agent activity or token use into progress.

Show a fused worker as one row such as YELLOW+VIOLET (fused). Do not pretend it is two independent workers. Show a peer call only after it happened and returned evidence.

Use show-the-work when the run itself must become a human story, handoff, video narrative, or proof-led artifact. Prism Board is live orientation; Show the Work is the verified explanation.

7. Integrate and close

Reject handoffs that lack an inspectable result or acceptance evidence. Resolve contradictions against the source of truth, not by voting. After any fix, rerun dependent checks. Before delivery:

1. confirm the final artifact reflects the accepted Green or Yellow decision;
2. confirm Blue built the accepted specification rather than a nearby one;
3. capture and inspect the actual judged surface using the recorded device, viewport, and workflow;
4. give Red the frozen contract, exact final artifact, and evidence, not Blue's conclusion;
5. resolve every blocking Red finding and rerun Red on the final state;
6. let Violet check that the finished artifact still serves the real outcome;
7. inspect the surface the user will judge after the last fix.

Report which roles materially changed the result and which were not needed. A smaller successful cast is better than a complete-looking one.

When colors cooperated, add a compact receipt:

PRISM HAND
Card and execution shape:
Primary color:
Added colors and trigger:
What each added color changed:
Connective creativity added by the integrator:
Independence preserved:
Colors considered but omitted:

Guardrails

• Personality never expands authority. No role may send, publish, spend, delete, file, deploy, or write to a live system without authorization.
• Do not use color as evidence, seniority, or a reason to overrule the user.
• Do not let Violet become vague strategy, Green become architecture theater, Yellow become endless ideation, Blue become literal work on a bad specification, or Red become criticism without a repair path.
• Do not keep workers alive after their owned output is accepted or rejected.
• Do not hide worker failures. Preserve useful rejected artifacts and say why they failed.
• Do not add a color whose output cannot change a decision, artifact, test, or stopping rule.
• Do not let peer calls cascade. One worker adds at most one peer by default; wider casting returns to the integrator.
• Do not call a fused self-review independent, especially when Blue and Red share one worker.