Verification Convergence

Use this skill when the user asks for /verify ..., /converge ..., or asks to verify, harden, audit, stress-test, or improve something through repeated expert review until it converges.

This is a personal high-intensity protocol, not a GoalFlow core feature and not a generic discussion format. The assistant owns orchestration: build the review panel, collect findings, judge them coldly, accept only what protects the objective, improve when needed, verify again, and stop when converged.

Core Principles

• Preserve the original goal. Do not let review suggestions change the objective.
• Prefer simple, elegant fixes. Treat abstraction and scope expansion as suspicious until proven necessary.
• Treat /verify or /converge as an explicit request to use specialist subagents for this protocol; outside those triggers, do not apply this protocol automatically.
• Specialist agents provide evidence, not commands.
• The main assistant arbitrates every finding and decides block, fix, accept risk, defer, or reject.
• Judge disagreements by evidence and objective fit, not by vote count.
• A pass verdict requires explicit evidence.
• Continue until convergence, bounded by the requested round limit.
• If the user specifies a maximum round count, honor it. Otherwise use maximum 5 rounds.
• Use 3-5 specialist agents by default. This skill is for stronger-than-normal validation.
• Do not add a ritual "no-change" round after every fix. Stop when the latest evidence is enough to judge convergence.
• Do not narrow later rounds to patch-only review. After accepted fixes, every round must keep a compact original-target lane plus a proportional delta/regression lane.

Intake

Before launching agents, state or internally fix:

• artifact_type: implementation, plan, document, strategy, operation, business idea, trading idea, architecture, proposal, or other
• objective: what must remain true
• non_goals: what must not be expanded into
• success_criteria: what would count as verified or converged
• risk_level: low, medium, high, or critical
• max_rounds: user-requested maximum, otherwise 5
• approval_boundaries: actions requiring user approval, such as external messages, public posts, destructive changes, Gateway restart, deployment, or financial/legal commitments
• context_sources: the 1-3 most relevant project principles, specs, plans, or memory files to include; avoid broad document sweeps

If one missing decision blocks safe verification, ask. Otherwise make a reasonable assumption and proceed.

Reviewer Profile Spec

Do not use a fixed persona list. Generate reviewer profiles dynamically from:

• artifact type
• domain
• risk level
• required expertise
• likely failure modes
• user-specified priorities

Default panel size is 3-5 agents.

For development implementation verification, include at least two code-capable reviewers:

• one focused on correctness, requirements, API/schema/contract, data flow, and edge cases
• one focused on tests, regression risk, runtime behavior, operational context, concurrency, and state boundaries

Use the remaining 1-3 reviewers for the specific risk surface, such as DB/data integrity, security/permissions, frontend behavior, domain logic, trading/backtest validity, deployment/operations, architecture simplicity, UX, or business model.

For non-development work, still use 3-5 reviewers, but adapt the panel. Examples:

• planning/design review: treat the target as a proposal to converge into an implementation-ready plan through specialist brainstorming, while still classifying findings as block, fix, accept risk, defer, or reject and preserving the original objective
• proposal: simplicity, usability, failure modes, goal-fit, overengineering
• business idea: customer pain, competition, revenue model, execution feasibility, risk/regulation
• trading strategy: leakage/overfit, market structure, execution/slippage, risk, data quality
• document: target evaluator, evidence strength, structure, missing claims, language clarity

Agent Instructions

Give each agent only the context it needs. Ask for independent findings, not a rewrite.

Tell each specialist agent not to send user-visible messages, use messenger/delivery tools, or notify chat channels. Agents should return findings only to the main assistant.

Require this output shape:

• finding
• severity: P0, P1, P2, or P3
• evidence: file/line/test/log/source/reasoning anchor
• why_it_matters
• minimal_fix_or_test
• scope_risk: objective protection or scope expansion
• confidence: high, medium, or low

For coding tasks, tell agents to inspect the codebase directly when relevant. If they are asked to edit files, give disjoint ownership. Usually for /verify, agents should review and report; the main assistant performs accepted fixes.

Round Loop

For each round:

1. Send a visible Round N start message before specialist work begins. Include only the target, panel focus, and intended verification gate.
2. Run deterministic checks first when possible: diff, tests, logs, existing docs, current state, or direct artifact inspection.
3. Launch the dynamic panel of 3-5 agents, unless the user constrained otherwise.
4. Collect findings and deduplicate by failure mode, not by wording.
5. Classify each finding:
   • block: cannot pass in current state
   • fix: should be fixed within the current objective
   • accept risk: real but acceptable, explicitly carried
   • defer: valid but outside current scope
   • reject: weak evidence, overengineering, goal drift, or bad tradeoff
6. Convert every accepted finding into an actionable item with Fix, Evidence, and Check.
7. Apply only accepted fixes or improvements.
8. Choose a risk-proportionate verification gate. Prefer tests, smoke checks, type checks, lint, API calls, logs, or direct artifact inspection as appropriate; do not force tests for tiny, obvious patches where inspection is enough.
9. Reserve pass for cases with enough evidence from the chosen gate. Use pass_with_risks, needs_fix, or stop when evidence is incomplete or risk remains.
10. Send a visible Round N summary in the exact summary shape below. If the user interrupts or asks for status, preserve the round label in the status response.

Round scope must not silently shrink:

• Round 1 is a full baseline review of the original target: objective, non-goals, success criteria, likely failure modes, and current artifact state.
• Round 2 and later use a two-lane review:
  • original target lane: re-check that the original objective, non-goals, approval boundaries, and success criteria still hold in the current state.
  • delta lane: check accepted fixes, changed files/artifacts, new assumptions, and proportional regression surfaces introduced since the previous round.
• Later rounds may focus more deeply on changed or risky surfaces, but they must explicitly state whether the original target still passes, passes with risk, or needs more work.
• Do not describe a later round target only as "accepted fixes" or "latest patch" unless the original target lane is also named and checked.
• Each reviewer or deterministic review pass should answer: "What would make the current convergence claim false?" Use this to counter patch-only confirmation bias.
• Ask reviewers to classify new findings as one of:
  • original-target-failure: the original objective is still not satisfied, was weakened, or was regressed.
  • patch-regression: the latest accepted fix introduced a new failure mode or adjacent risk.
  • known-risk: already accepted, deferred, or duplicate; reopen only with new evidence.

If accepted fixes were applied during a round, decide whether another specialist round is needed by risk:

• Run another round when the fix is broad, touches shared runtime/state/security/deployment behavior, causes reviewer disagreement, or creates a plausible new failure mode.
• Do not run another round just to prove "no findings" when the fix is narrow, the failure mode is directly covered by tests or inspection, and another round would mostly add noise.
• In either case, the visible summary must say whether the original target lane and delta lane have converged, still need another round, or are blocked.

For high-risk work, or whenever two or more rounds already focused heavily on fixes, add one fresh-scope reviewer when feasible. Give that reviewer the original objective, current artifact, success criteria, and current diff/state, but minimize exposure to prior reviewer conclusions. The goal is to catch remaining failure modes from first principles without anchoring on earlier arbitration.

Progress summary format:

Round N summary
- Original target: pass | pass_with_risks | needs_fix | blocked
- Patch regression: pass | pass_with_risks | needs_fix | blocked | none
- Found: ...
- Accepted fixes: ...
- Rejected/deferred: ...
- Checked: ...
- Next: ...

Do not include long raw logs in chat.

Do not expose subagent notifications, raw system events, internal tool envelopes, ledger internals, or agent transcripts directly to the user. Summarize only the main assistant's arbitration: what was found, what was accepted, what was rejected/deferred, what changed, and what evidence supports the result.

Convergence

Stop before the maximum round count when convergence is reached:

• no new P0/P1 findings
• no unresolved P0/P1 original-target failures
• the original objective, non-goals, approval boundaries, and success criteria were re-checked after the latest meaningful fix
• repeated findings are duplicates of known risks
• accepted fixes are complete
• prior accepted findings remain closed
• patch regression surfaces were checked proportionally to risk
• remaining items are accept risk or defer
• the chosen verification gate provides enough evidence, or failures are clearly outside scope
• another round would mostly add noise or scope expansion

Convergence does not require a separate no-change reviewer round. It requires a clear judgment that the original target still holds, accepted findings are handled, patch regression risk was checked proportionally, and the latest verification gate is proportionate to the risk. If a final fix was narrow and directly checked, declare convergence in the progress/final report instead of spawning another round by habit only after the original target lane has explicitly passed.

Continue when:

• there is a new P0/P1 finding
• reviewers disagree on a material point
• a fix introduced new risk
• verification failed
• the goal is still not satisfied
• the original target lane and delta lane cannot both be evidenced
• a later round became patch-only without re-checking the original target

If the requested round limit is reached without convergence, report needs_fix or stop with the blocking reason.

PR, Merge, And Deployment

Treat PR, merge, release, Gateway restart, and deployment as post-convergence actions, not part of every review round.

• /verify itself never implies PR creation, merge, release, deployment, install, or Gateway restart.
• Perform PR/merge/deploy only when the user explicitly asked for those actions outside the verification protocol, or explicitly confirms them after the convergence report.
• During early rounds, discuss PR/merge/deploy only as a possible final route, not as the immediate next action.
• Do not open or merge a PR until accepted findings are fixed and the current state is judged converged or pass_with_risks.
• Do not deploy before PR/merge unless the user explicitly asked for local-only application or emergency hotfix behavior.
• If deployment or Gateway restart is requested, follow the host's normal approval/preflight policy and report any interruption risk.
• Keep the final report clear about ordering: verification result first, then PR/merge/deploy outcome if performed.

Final Report

Use this concise structure:

Status: pass | pass_with_risks | needs_fix | stop
Rounds: N / max
Agents: brief dynamic panel summary
Original target: pass | pass_with_risks | needs_fix | blocked, with one-line evidence
Patch regression: pass | pass_with_risks | needs_fix | blocked | none, with one-line evidence
Done: accepted improvements or validated result
Checked: evidence from the chosen verification gate
Rejected/deferred: high-signal items only
Remaining: risks or next required action

For chat platforms, avoid markdown tables and keep the report compact. If a file was created or sent through a message tool, all follow-up output in that turn should use the same visible delivery path.

Make completion explicit. Use language that clearly says whether the verification converged, stopped, or still needs work.