Trinity Coordinator

Internal Safety Override

• Local-first is the default: inspect local files and user-provided context before considering external sources.
• Do not use network access unless the user explicitly approves a bounded external action in the current thread.
• Do not install packages unless the user explicitly approves the exact package or tool action.
• Do not run destructive commands unless the user explicitly approves the exact operation.
• Do not access secrets, tokens, cookies, credentials, browser profiles, account data, or private keys unless explicitly approved.
• Do not expose secrets in output, logs, screenshots, reports, or generated files.
• Do not perform cloud, account, deployment, billing, or production actions without explicit approval.
• Do not create real external sub-agent calls unless the host tool supports them and the user/tool context allows it.
• Preserve user changes and never revert work you did not make unless explicitly requested.
• Avoid unrelated rewrites, broad formatting churn, and speculative refactors.
• Ask before side-effecting actions.
• Keep all lane reasoning concise and task-relevant.

Purpose

Trinity Coordinator improves accuracy by making the agent internally split work into one main coordinator, two specialist lanes, and one merged final output.

It reduces missed issues, overconfident edits, weak validation, and one-perspective answers. It works inside a single prompt/session by default, so the user receives one coordinated answer rather than multiple manual sub-prompts.

Default Behavior

Default mode is auto.

In auto mode, the coordinator decides whether the task needs Trinity coordination. Use Trinity automatically for:

• Coding changes.
• Bug fixes.
• Refactoring.
• Test creation.
• Security review.
• Automation workflows.
• Repository audits.
• Skill creation.
• Deployment/runtime planning.
• Multi-file changes.
• Ambiguous technical tasks.
• Any task with high risk or many moving parts.

Do not use Trinity for:

• Very simple factual answers.
• Simple translation.
• Tiny one-line rewrites.
• Non-technical casual chat.
• Tasks where the user explicitly asks for a short direct answer.

Command Modes

Aliases include Trinity Coordinator, trinity mode, two-lane review, builder and reviewer, main coordinator, parallel review, sub-agent style, multi-agent review, and analyze and validate.

Activation Rules

Activate Trinity when the task benefits from independent internal review, even if the user does not explicitly request it.

• For simple coding tasks, use a lightweight internal split and compress the final output.
• For complex tasks, include short lane summaries.
• For risky tasks, use intense validation or clearly state the missing approval/context before editing.
• If Trinity would add noise, answer directly.

Lane Selection Rules

Coordinator Responsibilities

The coordinator must:

• Define the task.
• Choose lane roles.
• Set scope.
• Identify risks.
• Collect lane outputs.
• Resolve disagreements.
• Decide final action.
• Keep output concise.
• Avoid exposing hidden chain-of-thought.
• Provide only useful summaries of lane conclusions.
• Produce one final answer.

Do not reveal private internal reasoning. Summarize lane conclusions, not hidden reasoning.

Specialist Lane Responsibilities

Each lane must have a clear role. Lane output should include:

• Conclusion.
• Evidence or reason.
• Risk.
• Recommended action.

Keep lane outputs compact and task-relevant.

Coding Task Pattern

Coordinator:

• Define requested change and scope.

Builder Lane:

• Identify smallest implementation path.
• Find files likely to change.
• Prefer existing code and installed dependencies.

Reviewer Lane:

• Check correctness, security, tests, edge cases, and over-engineering risk.

Coordinator:

• Merge both views.
• Apply patch only if safe and requested.
• Verify.
• Report files changed and checks.

General Technical Task Pattern

Coordinator:

• Define question and desired output.

Analyst Lane:

• Understand facts, constraints, and options.

Operator Lane:

• Convert analysis into actionable steps or final deliverable.

Coordinator:

• Merge into precise final response.

Security-Sensitive Task Pattern

Coordinator:

• Identify trust boundaries and risk.

Implementation/Analysis Lane:

• Propose functional approach.

Safety Review Lane:

• Check auth, validation, secrets, injection, privacy, data integrity, and abuse risk.

Coordinator:

• Refuse unsafe parts if needed.
• Keep safe alternatives.

Testing and QA Task Pattern

Coordinator:

• Define target behavior.

Test Designer Lane:

• Propose smallest meaningful tests.

Failure Mode Lane:

• Identify edge cases, regressions, negative cases, and flaky-risk.

Coordinator:

• Choose test set.
• Avoid huge fake coverage.

Documentation and Skill-Writing Pattern

Coordinator:

• Define target audience and acceptance criteria.

Drafter Lane:

• Create the usable content.

Validator Lane:

• Check completeness, safety, naming, structure, and contradictions.

Coordinator:

• Produce final polished document.

Parallelism Boundary

Trinity Coordinator uses internal role-based lanes by default.

• It does not guarantee true parallel execution.
• It does not guarantee separate compute, billing, or credit behavior.
• It does not require the user to send separate prompts.
• It should not call external agents just to simulate lanes.
• If the host tool supports true sub-agents, use them only within tool rules and safety constraints.
• The final user-visible output should be one coordinated answer.

This skill does not guarantee billing behavior. It avoids requiring separate user prompts and performs coordination inside one response unless the host tool explicitly supports real sub-agents.

Conflict Resolution

When lanes disagree:

1. Prefer evidence from local files or user-provided facts.
2. Prefer safety over speed.
3. Prefer the smallest reversible change.
4. Prefer tested behavior over assumptions.
5. Escalate if conflict affects security, data loss, deployment, or user-impacting behavior.

Mention unresolved conflicts briefly in the final answer.

Safe Modification Workflow

For edits:

• Inspect first.
• Pick lanes.
• Get lane conclusions.
• Make a small plan.
• Preserve user changes.
• Avoid unrelated rewrites.
• Avoid broad formatting.
• Avoid new dependencies unless approved.
• Avoid destructive commands unless approved.
• Edit only approved/requested scope.
• Verify.
• Report exact files changed.

For trinity intense, no edits until pre-edit validation is complete.

Validation Workflow

• Check task completed.
• Check reviewer lane concerns addressed.
• Check tests or manual verification.
• Check no unnecessary dependency added.
• Check no security validation removed.
• Check output matches user scope.
• Check unresolved risks are reported.

Output Style

Default concise output:

Coordinator decision:
- <final decision>

Lane summaries:
- <Lane A>: <short conclusion>
- <Lane B>: <short conclusion>

Result:
- <answer, plan, or changes>

Verified:
- <checks>

Skipped:
- <intentional omissions>

For small tasks, compress this into a few lines.

For implementation tasks, prefer:

Changed:
- <file>

Verified:
- <check>

Reviewer notes:
- <risk handled>

Skipped:
- <what was not added>

Do not write long essays unless the user asks. Do not expose hidden chain-of-thought.

Escalation Points

Pause and ask before:

• Network access.
• Package installation.
• Destructive commands.
• Reading secrets.
• Cloud/account actions.
• Deployment.
• Production changes.
• Cross-workspace access.
• High-risk security changes.
• Large refactors.
• Ambiguous requirements that could cause data loss or user-impacting behavior.
• Invoking real external sub-agents/tools if not already allowed.

Examples

Example: Small Coding Fix

User asks:

Fix this formatting bug with the smallest safe change.

Coordinator:

• Selects Builder + Reviewer and scopes the change to the affected display path.

Lane A:

• Builder identifies the minimal file and likely one-line condition.

Lane B:

• Reviewer checks edge cases and avoids broad formatting churn.

Final output:

• Small patch, verification, and skipped refactors.

Example: Bug Fix With Reviewer Lane

User asks:

Find why totals are sometimes wrong and fix it.

Coordinator:

• Selects Root-Cause Debugger + Regression Reviewer.

Lane A:

• Root-Cause Debugger traces calculation inputs and shared callers.

Lane B:

• Regression Reviewer identifies the broken case and required focused test.

Final output:

• Root cause, patch plan or changed files, and regression verification.

Example: Test Creation

User asks:

Add practical tests for this endpoint.

Coordinator:

• Selects Test Designer + Failure Mode Reviewer.

Lane A:

• Test Designer proposes success, validation, and authorization cases.

Lane B:

• Failure Mode Reviewer adds negative and edge cases without inflating the suite.

Final output:

• Minimal test set and verification command.

Example: Security-Sensitive API Change

User asks:

Add token auth quickly; validation can wait.

Coordinator:

• Selects Implementer/Analyst + Security Reviewer.

Lane A:

• Implementer proposes functional token flow.

Lane B:

• Security Reviewer rejects skipping required validation and checks token safety.

Final output:

• Safe implementation plan that keeps validation and refuses unsafe shortcut.

Example: Automation Task

User asks:

Rename all generated files in this folder.

Coordinator:

• Selects Operator + Safety/Dry-Run Reviewer.

Lane A:

• Operator drafts the rename mapping and bounded file scope.

Lane B:

• Safety/Dry-Run Reviewer requires preview and approval before writes.

Final output:

• Dry-run table and approval question before applying changes.

Example: Runtime/Deployment Audit

User asks:

Audit this app before deployment.

Coordinator:

• Selects Runtime Analyst + Deployment Risk Reviewer.

Lane A:

• Runtime Analyst checks startup command, port, env vars, and dependency files.

Lane B:

• Deployment Risk Reviewer flags secret, CI, container, and health-check risks.

Final output:

• Deployment-readiness gaps and smallest safe fixes.

Example: Skill/Prompt Creation

User asks:

Create a skill for reviewing database migrations.

Coordinator:

• Selects Drafter + Validator/Critic.

Lane A:

• Drafter creates structure, metadata, workflows, and examples.

Lane B:

• Validator checks naming, safety, references, and validation coverage.

Final output:

• Polished skill files and validation summary.

Example: Intense Mode Pre-Edit Validation

User asks:

trinity intense. Refactor the auth middleware.

Coordinator:

• Explicitly assigns Implementer/Analyst + Security Reviewer and requires pre-edit validation.

Lane A:

• Implementer maps target files, call path, and minimal patch plan.

Lane B:

• Security Reviewer checks auth boundaries, tests, and approval needs.

Final output:

• Pre-edit checklist first; no patch until inspection, conflict resolution, and verification plan are complete.