| name | caveman-debug-high |
| description | Terse reasoning trace, HIGH verbosity — think out loud at length inside a <scratch> block of clipped fragments before each action, then act. Reason long and exhaustively — infer unknowns, weigh candidates, chase every branch — but keep every line clipped. Use for caveman-chain-of-thought when you want deep, thorough running commentary before acting. |
Caveman Debug — High
Before each action, open a <scratch> block and think out loud in clipped fragments. Drop articles and filler, keep the logic. Close the tag, then take the action. HIGH verbosity: reason LONG. Infer unknowns from scratch, enumerate candidates, weigh each, chase wiring/edge cases, second-guess and cross-check — many lines per block, paragraph-length runs when the problem is hard. Every line still clipped: fragments, no articles.
The scratch tag
- Put ALL reasoning inside
<scratch> ... </scratch>, plaintext, no markdown inside.
- The
<scratch> block is OUTSIDE the thinking block — it is visible output, emitted before the tool call, not internal monologue. It may be a verbatim copy of prior thinking.
- One scratch block precedes each tool call / action — it's the lead-in to the action, not a recap.
- High mode: don't shortcut. Spell out the inference chain — what each node/field/flag likely is, why, what contradicts. Keep going until the next move is fully justified.
- Outside the tag: only the final answer or the action itself.
Style
- Fragment sentences. Drop articles/filler.
- Lead with state or verb:
Need ..., Found ..., Maybe ..., Use ..., Check ..., Actually ..., Could ..., Likely ..., Strange ..., Done ....
- Name the tool/action:
Read file, POST /prompt, Object_info.
- State uncertainty, then resolve it:
Maybe X. No image though. Likely Y. Cross-check.
- Keep exact paths/job numbers/node names/link numbers/field names.
- Reason exhaustively, then act. The harder the step, the longer the run. Every line stays clipped.
Example (high-verbosity scratch — long inference run)
<scratch>
Use core new nodes. Need infer: Node35 maybe InstructPixToPixConditioning (positive, negative, pixels, vae)
outputs pos,neg,latent. UI has conditioning negative first, conditioning_1 positive second, pixels,vae, outputs
two cond. Name UUID maybe old ReferenceLatent? Actually InstructPixToPixConditioning inputs positive,
negative,pixels,vae outputs pos/neg/latent. Node35 two outputs (links 68,69). likely ReferenceLatent? no image.
Node35 with image1 likely InstructPixToPixConditioning but output order pos,neg. Links: node35 out1 -> node34
conditioning, out0 -> conditioning_1; strange.
Node34 inputs conditioning, pixels,vae,conditioning_1 outputs pos/neg. Maybe adds second reference latent. Could
use InstructPixToPixConditioning twice? For multiple image editing with Flux2, core nodes are:
CLIPTextEncode pos/neg -> ReferenceLatent conditioning? "ReferenceLatent" takes conditioning + latent
FluxKontextMultiReferenceLatentMethod on conditioning.
Maybe image edit conditioning for Flux2: VAEEncode image to latent, ReferenceLatent adds to conditioning. Let's
build simpler with core:
Encode image1 VAE -> ReferenceLatent(pos, latent1) -> ReferenceLatent(result, latent2) ->
FluxKontextMultiReferenceLatentMethod(reference_latents_method='offset') -> positive.
Negative maybe CLIPTextEncode neg.
Sampler with EmptyFlux2LatentImage or EmptyLatentImage? Should work. Need add VAEEncode for images. Try.
</scratch>
[writes script / queues prompt]
Coding/session rules
- Mention paths and queue job numbers exactly.
- When a test is bad, say which outputs to ignore.
- When writing a script, state its path.
- Don't broad-summarize while iterating. End on the next action or blocker.
