reflect

name	reflect
description	Iterative reflexion loop — generate, critique against EXTERNAL evidence (real tests, search), then revise until it converges. Grounded self-correction, not sycophantic self-review
user-invocable	true

Reflect - Grounded Reflexion Loop

Harden an answer or solution through cycles of generate → critique → revise — but ground each critique in EXTERNAL evidence (run the tests, search the facts) rather than letting the model grade its own homework. Pure self-critique is prone to sycophancy (the model agreeing with its own errors); external grounding is where the real gains are (roughly +30 percentage points on coding tasks).

Usage

/reflect [solution or claim to harden]
/reflect [rounds] [target]      (rounds default 2, max 3)

When to Use

• A draft solution/answer needs hardening before you ship it
• Correctness matters AND you can actually verify it (tests, types, facts)
• One-shot output feels plausible but you're not sure it's right

/reflect vs /judge

	/reflect	/judge
Shape	Iterative: critique → fix → re-check (one actor)	Parallel: many models vote once
Grounding	EXTERNAL (tests, build, search)	Model opinions
Use when	"Harden THIS solution"	"Which approach is best?"

Instructions

When user invokes /reflect [target] (parse optional leading round count, default 2, max 3):

Step 1: Generate the initial solution + critique frame

mcp__tachibot-mcp__execute_prompt_technique({
  technique: "reflexion",
  tool: "deepseek_reason",
  query: "[target]"
})

deepseek_reason is the actor (strong reasoner); fall back to grok_reason or kimi_thinking if unavailable.

Step 2: EXTERNAL verification (the key step — never skip)

Ground the critique in OBJECTIVE evidence, not the model's self-opinion. Use whatever applies to the target:

• Code change? Actually run it via Bash: npm test, build, typecheck, lint. Capture the real output.
• Factual claim? mcp__tachibot-mcp__grok_search({ query: "..." }) or mcp__tachibot-mcp__perplexity_ask({ query: "..." }) to confirm against reality.
• Edge cases? Construct a concrete failing input and run it.

Collect the objective results. THESE drive the next step — not "does the model think it's good?"

Step 3: Revise against the evidence

mcp__tachibot-mcp__nextThought({
  thought: "Revise the solution using EXTERNAL evidence (not self-opinion).\n\nCurrent solution: [current]\nExternal findings: [test output / search results / failing input]\n\nFix the SPECIFIC issues the evidence revealed. State exactly what changed and why.",
  model: "deepseek",
  executeModel: true,
  contextWindow: "all",
  nextThoughtNeeded: true
})

(Models: deepseek, grok, kimi — use a strong reasoner.)

Step 4: Loop or converge

Repeat Steps 2–3 until EITHER the external checks pass (tests green / search confirms / no new failing input) OR you hit the round limit. Each round must use FRESH external evidence — if you're just re-reading the model's own opinion, stop and run a real check.

Step 5: Final verdict

mcp__tachibot-mcp__nextThought({
  thought: "Final reflexion verdict for [target]:\n- What the solution is now\n- What external checks confirm it (cite the actual evidence: test output, search result)\n- Remaining risks NOT yet verified\n- Confidence (high/medium/low) + why",
  model: "gemini",
  executeModel: true,
  contextWindow: "all",
  nextThoughtNeeded: false
})

Examples

• /reflect this rate-limiter implementation (runs the tests as the critique evidence)
• /reflect 3 my claim that switching to BigInt fixes the overflow
• /reflect harden this SQL migration before I run it on prod