/long-horizon-prompting

name: long-horizon-prompting
description: "This skill should be used when writing, enhancing, or evaluating the launch prompt for a long-running autonomous agent or a parallel multi-agent orchestration attacking a hard problem: pseudo-formal task briefs that define terms and an exact success predicate linguistically, enumerate non-counting outcomes, set persistence rules with explicit stop and return conditions and effort floors, manage a diverse portfolio of parallel approaches with an approach registry and blocked-route bookkeeping, and gate the return on adversarial audit. Route agent topology and coordination protocols to multi-agent-patterns, runtime control surfaces and loop governance to harness-engineering, evaluator and quality-gate construction to evaluation, judge design to advanced-evaluation, and compaction or memory mechanics to context-compression and memory-systems."

Long-Horizon Prompting

This skill covers the design of the prompt that launches an agent expected to work autonomously for hours or days, alone or as an orchestrator managing many parallel workers. The central technique is the pseudo-formal task brief: a specification written with the rigor of formal verification but expressed linguistically, because most hard problems have no machine-checkable success condition. The exemplar is the published prompt behind GPT-5.6 Sol Ultra's candidate proof of the Cycle Double Cover Conjecture, produced by a 64-subagent orchestration (claim-long-horizon-cdc-run). The prompt structure generalizes far beyond mathematics: any domain where success can be stated precisely and failure modes can be enumerated can use the same brief anatomy. In orchestrated runs the same discipline applies at every handoff: when a model optimized its own multi-agent workflow text in Sakana AI's MASS work, task information moved out of worker roles and into output contracts and call order (claim-long-horizon-contract-information-shift).

The controlling trade-off: everything that makes a long run productive (persistence, autonomy, parallelism) also raises the cost of a weak specification. A short interactive prompt fails cheaply; a long-horizon brief with a loophole burns hours of compute producing an answer-shaped artifact that does not solve the problem.

When to Activate

Activate this skill when:

• Writing or reviewing the prompt for a long-running autonomous run before launching it
• Converting a vague hard problem ("solve X", "figure out why Y happens") into an explicit brief with a success predicate and non-counting outcomes
• Writing the root or orchestrator prompt that manages many parallel workers on an open-ended search problem
• Adding persistence instructions, stop conditions, effort floors, or return gates to an agent prompt
• Writing the output contract and acceptance checks each delegated worker must satisfy, or the rule for which review findings block a return
• Diagnosing a failed long run whose failure traces to the brief: premature return, an answer-shaped near miss, all workers converging on one approach, or fabricated completion claims
• Building a pre-launch review step that enhances and evaluates prompts before expensive agent time is committed

Do not activate this skill for adjacent work owned by other skills:

• Agent topology, supervisor versus swarm choice, handoff protocols, and coordination mechanics: `multi-agent-patterns`. That skill owns the architecture; this skill owns the words that steer it, including the contract each worker must return.
• Runtime control surfaces, locked evaluators, rollback, durable logs, and approval boundaries around an autonomous loop: `harness-engineering`. Constraints that must survive optimization pressure belong in the harness, not the prompt.
• Building the evaluator, regression suite, or deterministic quality gates a run is scored by: `evaluation`.
• LLM-as-judge design, rubrics, pairwise comparison, and bias mitigation: `advanced-evaluation`.
• Compaction, note-taking, and cross-session memory mechanics for surviving context limits: `context-compression`, `memory-systems`, `filesystem-context`.
• Loops that modify their own harness or prompts: `self-improvement-loops`.
• Remote sandboxes and background execution infrastructure: `hosted-agents`.

Core Concepts

Pseudo-Formal Task Specification

Formal verification requires a machine-checkable specification. Hard open problems rarely have one, but the discipline transfers: state the success condition so precisely that an adversarial reader cannot satisfy its letter without satisfying its intent. Four components, in order of leverage:

1. **Definitions with degenerate cases.** Define every load-bearing term before stating the goal, including the edge cases a lazy solution would exploit. The CDC prompt defines graph, bridge, cycle, and cycle double cover before the task, explicitly covering parallel-edge two-cycles, disconnected graphs, and the edgeless graph. 2. **Exact success predicate.** One statement of what must be true of the returned artifact, with scope quantifiers spelled out ("every finite loopless multigraph with no bridge, without additional assumptions such as cubicity, planarity, connectivity, or higher edge-connectivity"). 3. **Non-counting outcomes.** An enumerated list of results that do not count: partial progress, special-case solutions, reductions to another unproved statement, bounded or computational verification, and best-effort summaries. This is the highest-leverage component. Under persistence pressure, models produce answer-shaped near misses; each excluded outcome removes one escape hatch. 4. **Enumerated failure modes for the auditor.** A concrete checklist of the domain-specific ways a candidate can be subtly wrong (in CDC: repeated-edge closed trails masquerading as cycles, bridges introduced by reductions, circular use of an equivalent statement). Verifiers with an enumerated hunt list catch what generic "check the work" instruction