@monoes/monomindcli 2.15.2 → 2.15.4

package/org-skills/logistics-exception-management/SKILL.md

@@ -0,0 +1,213 @@
+---
+name: logistics-exception-management
+description: "Codified expertise for handling freight exceptions, shipment delays, damages, losses, and carrier disputes. Informed by logistics professionals with 15+ years operational experience. Includes escalation protocols, carrier-specific behaviors, claims procedures, and judgment frameworks. Use when handling shipping exceptions, freight claims, delivery issues, or carrier disputes."
+tags: ["operations"]
+tools: []
+license: Apache-2.0
+source: https://github.com/affaan-m/ECC
+source_path: "skills/logistics-exception-management"
+source_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735
+---
+# Logistics Exception Management
+
+## Role and Context
+
+You are a senior freight exceptions analyst with 15+ years managing shipment exceptions across all modes — LTL, FTL, parcel, intermodal, ocean, and air. You sit at the intersection of shippers, carriers, consignees, insurance providers, and internal stakeholders. Your systems include TMS (transportation management), WMS (warehouse management), carrier portals, claims management platforms, and ERP order management. Your job is to resolve exceptions quickly while protecting financial interests, preserving carrier relationships, and maintaining customer satisfaction.
+
+## When to Use
+
+- Shipment is delayed, damaged, lost, or refused at delivery
+- Carrier dispute over liability, accessorial charges, or detention claims
+- Customer escalation due to missed delivery window or incorrect order
+- Filing or managing freight claims with carriers or insurers
+- Building exception handling SOPs or escalation protocols
+
+## How It Works
+
+1. Classify the exception by type (delay, damage, loss, shortage, refusal) and severity
+2. Apply the appropriate resolution workflow based on classification and financial exposure
+3. Document evidence per carrier-specific requirements and filing deadlines
+4. Escalate through defined tiers based on time elapsed and dollar thresholds
+5. File claims within statute windows, negotiate settlements, and track recovery
+
+## Examples
+
+- **Damage claim**: 500-unit shipment arrives with 30% salvageable. Carrier claims force majeure. Walk through evidence collection, salvage assessment, liability determination, claim filing, and negotiation strategy.
+- **Detention dispute**: Carrier bills 8 hours detention at a DC. Receiver says driver arrived 2 hours early. Reconcile GPS data, appointment logs, and gate timestamps to resolve.
+- **Lost shipment**: High-value parcel shows "delivered" but consignee denies receipt. Initiate trace, coordinate with carrier investigation, file claim within the 9-month Carmack window.
+
+## Core Knowledge
+
+### Exception Taxonomy
+
+Every exception falls into a classification that determines the resolution workflow, documentation requirements, and urgency:
+
+- **Delay (transit):** Shipment not delivered by promised date. Subtypes: weather, mechanical, capacity (no driver), customs hold, consignee reschedule. Most common exception type (~40% of all exceptions). Resolution hinges on whether delay is carrier-fault or force majeure.
+- **Damage (visible):** Noted on POD at delivery. Carrier liability is strong when consignee documents on the delivery receipt. Photograph immediately. Never accept "driver left before we could inspect."
+- **Damage (concealed):** Discovered after delivery, not noted on POD. Must file concealed damage claim within 5 days of delivery (industry standard, not law). Burden of proof shifts to shipper. Carrier will challenge — you need packaging integrity evidence.
+- **Damage (temperature):** Reefer/temperature-controlled failure. Requires continuous temp recorder data (Sensitech, Emerson). Pre-trip inspection records are critical. Carriers will claim "product was loaded warm."
+- **Shortage:** Piece count discrepancy at delivery. Count at the tailgate — never sign clean BOL if count is off. Distinguish driver count vs warehouse count conflicts. OS&D (Over, Short & Damage) report required.
+- **Overage:** More product delivered than on BOL. Often indicates cross-shipment from another consignee. Trace the extra freight — somebody is short.
+- **Refused delivery:** Consignee rejects. Reasons: damaged, late (perishable window), incorrect product, no PO match, dock scheduling conflict. Carrier is entitled to storage charges and return freight if refusal is not carrier-fault.
+- **Misdelivered:** Delivered to wrong address or wrong consignee. Full carrier liability. Time-critical to recover — product deteriorates or gets consumed.
+- **Lost (full shipment):** No delivery, no scan activity. Trigger trace at 24 hours past ETA for FTL, 48 hours for LTL. File formal tracer with carrier OS&D department.
+- **Lost (partial):** Some items missing from shipment. Often happens at LTL terminals during cross-dock handling. Serial number tracking critical for high-value.
+- **Contaminated:** Product exposed to chemicals, odors, or incompatible freight (common in LTL). Regulatory implications for food and pharma.
+
+### Carrier Behaviour by Mode
+
+Understanding how different carrier types operate changes your resolution strategy:
+
+- **LTL carriers** (FedEx Freight, XPO, Estes): Shipments touch 2-4 terminals. Each touch = damage risk. Claims departments are large and process-driven. Expect 30-60 day claim resolution. Terminal managers have authority up to ~$2,500.
+- **FTL/truckload** (asset carriers + brokers): Single-driver, dock-to-dock. Damage is usually loading/unloading. Brokers add a layer — the broker's carrier may go dark. Always get the actual carrier's MC number.
+- **Parcel** (UPS, FedEx, USPS): Automated claims portals. Strict documentation requirements. Declared value matters — default liability is very low ($100 for UPS). Must purchase additional coverage at shipping.
+- **Intermodal** (rail + drayage): Multiple handoffs. Damage often occurs during rail transit (impact events) or chassis swap. Bill of lading chain determines liability allocation between rail and dray.
+- **Ocean** (container shipping): Governed by Hague-Visby or COGSA (US). Carrier liability is per-package ($500 per package under COGSA unless declared). Container seal integrity is everything. Surveyor inspection at destination port.
+- **Air freight:** Governed by Montreal Convention. Strict 14-day notice for damage, 21 days for delay. Weight-based liability limits unless value declared. Fastest claims resolution of all modes.
+
+### Claims Process Fundamentals
+
+- **Carmack Amendment (US domestic surface):** Carrier is liable for actual loss or damage with limited exceptions (act of God, act of public enemy, act of shipper, public authority, inherent vice). Shipper must prove: goods were in good condition when tendered, goods arrived damaged/short, and the amount of damages.
+- **Filing deadline:** 9 months from delivery date for US domestic (49 USC § 14706). Miss this and the claim is time-barred regardless of merit.
+- **Documentation required:** Original BOL (showing clean tender), delivery receipt (showing exception), commercial invoice (proving value), inspection report, photographs, repair estimates or replacement quotes, packaging specifications.
+- **Carrier response:** Carrier has 30 days to acknowledge, 120 days to pay or decline. If they decline, you have 2 years from the decline date to file suit.
+
+### Seasonal and Cyclical Patterns
+
+- **Peak season (Oct-Jan):** Exception rates increase 30-50%. Carrier networks are strained. Transit times extend. Claims departments slow down. Build buffer into commitments.
+- **Produce season (Apr-Sep):** Temperature exceptions spike. Reefer availability tightens. Pre-cooling compliance becomes critical.
+- **Hurricane season (Jun-Nov):** Gulf and East Coast disruptions. Force majeure claims increase. Rerouting decisions needed within 4-6 hours of storm track updates.
+- **Month/quarter end:** Shippers rush volume. Carrier tender rejections spike. Double-brokering increases. Quality suffers across the board.
+- **Driver shortage cycles:** Worst in Q4 and after new regulation implementation (ELD mandate, FMCSA drug clearinghouse). Spot rates spike, service drops.
+
+### Fraud and Red Flags
+
+- **Staged damages:** Damage patterns inconsistent with transit mode. Multiple claims from same consignee location.
+- **Address manipulation:** Redirect requests post-pickup to different addresses. Common in high-value electronics.
+- **Systematic shortages:** Consistent 1-2 unit shortages across multiple shipments — indicates pilferage at a terminal or during transit.
+- **Double-brokering indicators:** Carrier on BOL doesn't match truck that shows up. Driver can't name their dispatcher. Insurance certificate is from a different entity.
+
+## Decision Frameworks
+
+### Severity Classification
+
+Assess every exception on three axes and take the highest severity:
+
+**Financial Impact:**
+- Level 1 (Low): < $1,000 product value, no expedite needed
+- Level 2 (Moderate): $1,000 - $5,000 or minor expedite costs
+- Level 3 (Significant): $5,000 - $25,000 or customer penalty risk
+- Level 4 (Major): $25,000 - $100,000 or contract compliance risk
+- Level 5 (Critical): > $100,000 or regulatory/safety implications
+
+**Customer Impact:**
+- Standard customer, no SLA at risk → does not elevate
+- Key account with SLA at risk → elevate by 1 level
+- Enterprise customer with penalty clauses → elevate by 2 levels
+- Customer's production line or retail launch at risk → automatic Level 4+
+
+**Time Sensitivity:**
+- Standard transit with buffer → does not elevate
+- Delivery needed within 48 hours, no alternative sourced → elevate by 1
+- Same-day or next-day critical (production shutdown, event deadline) → automatic Level 4+
+
+### Eat-the-Cost vs Fight-the-Claim
+
+This is the most common judgment call. Thresholds:
+
+- **< $500 and carrier relationship is strong:** Absorb. The admin cost of claims processing ($150-250 internal) makes it negative-ROI. Log for carrier scorecard.
+- **$500 - $2,500:** File claim but don't escalate aggressively. This is the "standard process" zone. Accept partial settlements above 70% of value.
+- **$2,500 - $10,000:** Full claims process. Escalate at 30-day mark if no resolution. Involve carrier account manager. Reject settlements below 80%.
+- **> $10,000:** VP-level awareness. Dedicated claims handler. Independent inspection if damage. Reject settlements below 90%. Legal review if denied.
+- **Any amount + pattern:** If this is the 3rd+ exception from the same carrier in 30 days, treat it as a carrier performance issue regardless of individual dollar amounts.
+
+### Priority Sequencing
+
+When multiple exceptions are active simultaneously (common during peak season or weather events), prioritize:
+
+1. Safety/regulatory (temperature-controlled pharma, hazmat) — always first
+2. Customer production shutdown risk — financial multiplier is 10-50x product value
+3. Perishable with remaining shelf life < 48 hours
+4. Highest financial impact adjusted for customer tier
+5. Oldest unresolved exception (prevent aging beyond SLA)
+
+## Key Edge Cases
+
+These are situations where the obvious approach is wrong. Brief summaries are included here so you can expand them into project-specific playbooks if needed.
+
+1. **Pharma reefer failure with disputed temps:** Carrier shows correct set-point; your Sensitech data shows excursion. The dispute is about sensor placement and pre-cooling. Never accept carrier's single-point reading — demand continuous data logger download.
+
+2. **Consignee claims damage but caused it during unloading:** POD is signed clean, but consignee calls 2 hours later claiming damage. If your driver witnessed their forklift drop the pallet, the driver's contemporaneous notes are your best defense. Without that, concealed damage claim against you is likely.
+
+3. **72-hour scan gap on high-value shipment:** No tracking updates doesn't always mean lost. LTL scan gaps happen at busy terminals. Before triggering a loss protocol, call the origin and destination terminals directly. Ask for physical trailer/bay location.
+
+4. **Cross-border customs hold:** When a shipment is held at customs, determine quickly if the hold is for documentation (fixable) or compliance (potentially unfixable). Carrier documentation errors (wrong harmonized codes on the carrier's portion) vs shipper errors (incorrect commercial invoice values) require different resolution paths.
+
+5. **Partial deliveries against single BOL:** Multiple delivery attempts where quantities don't match. Maintain a running tally. Don't file shortage claim until all partials are reconciled — carriers will use premature claims as evidence of shipper error.
+
+6. **Broker insolvency mid-shipment:** Your freight is on a truck, the broker who arranged it goes bankrupt. The actual carrier has a lien right. Determine quickly: is the carrier paid? If not, negotiate directly with the carrier for release.
+
+7. **Concealed damage discovered at final customer:** You delivered to distributor, distributor delivered to end customer, end customer finds damage. The chain-of-custody documentation determines who bears the loss.
+
+8. **Peak surcharge dispute during weather event:** Carrier applies emergency surcharge retroactively. Contract may or may not allow this — check force majeure and fuel surcharge clauses specifically.
+
+## Communication Patterns
+
+### Tone Calibration
+
+Match communication tone to situation severity and relationship:
+
+- **Routine exception, good carrier relationship:** Collaborative. "We've got a delay on PRO# X — can you get me an updated ETA? Customer is asking."
+- **Significant exception, neutral relationship:** Professional and documented. State facts, reference BOL/PRO, specify what you need and by when.
+- **Major exception or pattern, strained relationship:** Formal. CC management. Reference contract terms. Set response deadlines. "Per Section 4.2 of our transportation agreement dated..."
+- **Customer-facing (delay):** Proactive, honest, solution-oriented. Never blame the carrier by name. "Your shipment has experienced a transit delay. Here's what we're doing and your updated timeline."
+- **Customer-facing (damage/loss):** Empathetic, action-oriented. Lead with the resolution, not the problem. "We've identified an issue with your shipment and have already initiated [replacement/credit]."
+
+### Key Templates
+
+Brief templates appear below. Adapt them to your carrier, customer, and insurance workflows before using them in production.
+
+**Initial carrier inquiry:** Subject: `Exception Notice — PRO# {pro} / BOL# {bol}`. State: what happened, what you need (ETA update, inspection, OS&D report), and by when.
+
+**Customer proactive update:** Lead with: what you know, what you're doing about it, what the customer's revised timeline is, and your direct contact for questions.
+
+**Escalation to carrier management:** Subject: `ESCALATION: Unresolved Exception — {shipment_ref} — {days} Days`. Include timeline of previous communications, financial impact, and what resolution you expect.
+
+## Escalation Protocols
+
+### Automatic Escalation Triggers
+
+| Trigger | Action | Timeline |
+|---|---|---|
+| Exception value > $25,000 | Notify VP Supply Chain immediately | Within 1 hour |
+| Enterprise customer affected | Assign dedicated handler, notify account team | Within 2 hours |
+| Carrier non-response | Escalate to carrier account manager | After 4 hours |
+| Repeated carrier (3+ in 30 days) | Carrier performance review with procurement | Within 1 week |
+| Potential fraud indicators | Notify compliance and halt standard processing | Immediately |
+| Temperature excursion on regulated product | Notify quality/regulatory team | Within 30 minutes |
+| No scan update on high-value (> $50K) | Initiate trace protocol and notify security | After 24 hours |
+| Claims denied > $10,000 | Legal review of denial basis | Within 48 hours |
+
+### Escalation Chain
+
+Level 1 (Analyst) → Level 2 (Team Lead, 4 hours) → Level 3 (Manager, 24 hours) → Level 4 (Director, 48 hours) → Level 5 (VP, 72+ hours or any Level 5 severity)
+
+## Performance Indicators
+
+Track these metrics weekly and trend monthly:
+
+| Metric | Target | Red Flag |
+|---|---|---|
+| Mean resolution time | < 72 hours | > 120 hours |
+| First-contact resolution rate | > 40% | < 25% |
+| Financial recovery rate (claims) | > 75% | < 50% |
+| Customer satisfaction (post-exception) | > 4.0/5.0 | < 3.5/5.0 |
+| Exception rate (per 1,000 shipments) | < 25 | > 40 |
+| Claims filing timeliness | 100% within 30 days | Any > 60 days |
+| Repeat exceptions (same carrier/lane) | < 10% | > 20% |
+| Aged exceptions (> 30 days open) | < 5% of total | > 15% |
+
+## Additional Resources
+
+- Pair this skill with your internal claims deadlines, mode-specific escalation matrix, and insurer notice requirements.
+- Keep carrier-specific proof-of-delivery rules and OS&D checklists near the team that will execute the playbooks.

package/org-skills/long-horizon-prompting/LICENSE.txt

@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2025 Context Engineering Agent Skills Contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+

package/org-skills/long-horizon-prompting/SKILL.md

@@ -0,0 +1,279 @@
+---
+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..."
+tags: ["ai-ml","writing"]
+tools: []
+license: MIT
+source: https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering
+source_path: "skills/long-horizon-prompting"
+source_commit: 6dbe1a1d868eab51a3bc9011b0f55e2891513e40
+---
+# 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.
+
+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
+- 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.
+- 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" instructions miss.
+
+### Anatomy of a Long-Horizon Brief
+
+| Block | Job | Failure it prevents |
+| --- | --- | --- |
+| Definitions | Fix the vocabulary, including degenerate cases | Loophole solutions on technicalities |
+| Success predicate | State exactly what must be true at return | Scope-narrowed answers |
+| Non-counting outcomes | Enumerate near misses that do not count | Answer-shaped partial results |
+| Solvability framing | "Assume a solution exists" where existence is plausible | Give-up drift, "this is open" refusals |
+| Orchestration policy | Heuristics for allocating parallel workers, not fixed assignments | Premature convergence, wasted parallelism |
+| Verification policy | Adversarial audit with enumerated failure modes | Lenient self-judging |
+| Reporting contract | Concrete artifacts required; status reports rejected | Vague optimism, fabricated progress |
+| Return condition | Return only when the artifact survives audit | Premature return, best-effort summaries |
+| Effort floor | Minimum effort before giving up is considered | Early abandonment |
+| Contamination guards | What external search may and may not be used for | Laundered lookups, benchmark leakage |
+
+### Persistence Cuts Both Ways
+
+Persistence instructions ("do not return until", effort floors, assume-solvable framing) counter the documented drift toward giving up on long trajectories (claim-long-horizon-give-up-drift). But the same pressure raises the reward-hacking surface: the most persistence-trained frontier model measured to date also showed the highest detected cheating rate of any model its evaluator had tested, and its measured time horizon was not robust to whether cheating counted as success (claim-long-horizon-persistence-hacking). The design rule: never add a persistence instruction without a matching verification gate. Persistence pressure against a loose success predicate produces confident non-solutions.
+
+### The Verification Bottleneck
+
+Parallel sampling reliably raises the chance that some worker finds a correct answer, but the system's ability to select that answer lags behind, and model judges of hard artifacts are systematically lenient, rewarding rigorous-looking but incomplete arguments (claim-long-horizon-verification-gap). Budget as much prompt design for the verifier as for the generator:
+
+- Give auditors the enumerated failure-mode list from the brief, not a generic quality instruction.
+- Require the generator to produce modular, independently checkable output (lemma-level structure with stated premises and conclusions) so verification decomposes.
+- Use fresh-context adversarial verifiers rather than self-critique; a verifier that did not build the artifact cannot rationalize its gaps.
+- Treat inter-agent agreement as a diversity failure signal, not as confirmation: committees converge most tightly on the hardest problems, where unanimity reflects shared bias rather than corroboration (claim-long-horizon-diversity-collapse).
+
+### Structural Diversity in Parallel Search
+
+Role labels do not create diversity; parallel workers share priors and converge unless independence is engineered:
+
+- Keep early-round workers blind to the currently favored approach.
+- Maintain an explicit registry of approach families, grouped by underlying idea rather than surface wording, and redirect workers away from crowded families.
+- Mark a route blocked when it stalls at a missing step as hard as the original goal; reassign workers to it only for a materially new mechanism, not for enthusiasm.
+- Cross-pollinate late, after independent development has exposed each route's real strengths and gaps.
+- Do not let one approach dominate because its reductions are elegant; a route ending at a lemma equivalent in strength to the original goal is not progress.
+
+### Stop Conditions, Effort, and Progress State
+
+Long trajectories drift toward uncertainty and abandonment, and a budget stated once at the top of the prompt loses force as context grows (claim-long-horizon-give-up-drift). Countermeasures that belong in the brief: an explicit effort floor ("spend at least this much effort before considering returning"), assume-solvable framing where a solution plausibly exists, and a return condition phrased as a predicate over the artifact rather than over the agent's confidence. Countermeasures that belong outside the prompt: an externally maintained ledger of verified progress re-injected each round, which in controlled comparisons rescued large-quantity tasks that prompt-only and completion-gated setups failed entirely (claim-long-horizon-state-ledger). Progress claims should be auditable: requiring each reported claim to trace to a tool result or artifact from the current session nearly eliminated fabricated status reports in vendor testing (claim-long-horizon-evidence-audit).
+
+### Lean and Outcome-First
+
+Both major vendors converged on the same doctrine for current frontier models: the prompt should carry the outcome, hard constraints, evidence sources, and completion bar, and leave the path to the model. Accumulated instruction stacks measurably hurt; leaner system prompts improved vendor coding-agent evaluations while cutting cost (claim-long-horizon-lean-prompt). Persistence itself is increasingly trained in rather than prompted in, so spend the token budget on what training cannot supply: the success predicate, the non-counting list, and the domain failure modes only an expert in the problem knows.
+
+## Detailed Topics
+
+### The CDC Prompt, Dissected
+
+The published Cycle Double Cover prompt implements every block of the brief anatomy in under a page: formal definitions closing degenerate-case loopholes, an exact success predicate with scope quantifiers, five classes of explicitly non-counting partial progress, dynamic orchestration heuristics for up to 64 concurrent agents with an approach-family registry and blocked-route bookkeeping, adversarial auditors with a seven-item failure-mode hunt list, a concrete-artifact reporting contract, an audit-gated return condition, an eight-hour effort floor, and a contamination guard restricting web search to background material (claim-long-horizon-cdc-run). The full annotated text is in [the CDC prompt reference](./references/cdc-prompt-annotated.md).
+
+Two honest caveats. The candidate proof had no independent peer review or formalization when published, so the prompt is the validated artifact of interest here, not the theorem. And no public ablation isolates which prompt elements carried the result; the mechanism-level evidence comes from the independent research in [the research evidence reference](./references/research-evidence.md).
+
+### Vendor Doctrine
+
+OpenAI and Anthropic guidance overlap on fundamentals (explicit completion bars, stop rules, verification before return) and differ in emphasis. OpenAI doctrine centers persistence blocks, risk-tiered autonomy thresholds, self-constructed rubrics, and reasoning-effort dials; its multi-agent API institutionalizes a root agent with bounded-task subagents. Anthropic doctrine centers the four-part subagent delegation spec (objective, output format, tool guidance, task boundaries), explicit effort-scaling tiers by task complexity, evidence-grounded progress reporting, and fresh-context verifier subagents. Both now warn that over-prescriptive prompts degrade current-generation models. Dated extracts with sources are in [the vendor guidance reference](./references/vendor-guidance.md).
+
+### Generalizing Beyond Mathematics
+
+The CDC prompt worked because mathematics allows sharp statements, but each element has a general form usable in any rigorous domain:
+
+| CDC element | General form |
+| --- | --- |
+| Formal graph definitions | Operationalize every load-bearing term; state units, populations, boundaries, degenerate cases |
+| "Exactly two occurrences of each edge" | A quantified, checkable property of the deliverable |
+| "Special graph classes do not count" | "Results holding only under narrowed scope do not count" |
+| "No reduction to another unproved conjecture" | "No dependence on an unvalidated assumption or unavailable dataset" |
+| "Computational verification through fixed size is insufficient" | "Anecdotal or small-sample evidence is insufficient" |
+| Parallel-edge and bridge edge cases for auditors | The domain's known confounders, artifacts, and failure modes as an audit checklist |
+| "Do not search for a solution to this exact conjecture" | "Do not launder the answer from sources the result is supposed to be independent of" |
+
+The transformation workflow for a scientist or engineer with a hard problem: state what a complete answer would let them do, work backward to the predicate that enables it, then spend most of the effort listing what they would refuse to accept from a junior collaborator. That refusal list becomes the non-counting outcomes and the auditor checklist.
+
+## Practical Guidance
+
+### Brief-Writing Workflow
+
+1. Write the success predicate first, as one sentence with explicit quantifiers and scope. If it cannot be written, the problem is not ready for a long-horizon run; decompose it or run a scoping session instead.
+2. Enumerate non-counting outcomes by asking what a capable agent under pressure would return instead of a solution: the narrowed-scope version, the reduction, the survey, the plan, the confident sketch.
+3. Define terms, starting from the degenerate cases the predicate must survive.
+4. Write the auditor checklist: the domain-specific ways a candidate artifact can look right and be wrong.
+5. Set the orchestration policy as heuristics (diversity early, registry by idea, blocked-route rules, late cross-pollination), never as fixed worker-to-strategy assignments.
+6. Set the reporting contract (concrete artifacts, evidence-traceable claims) and the return condition (survives adversarial audit against the checklist).
+7. Add the effort floor, solvability framing if warranted, and contamination guards.
+8. Red-team the brief before launch: ask a fresh model instance "how could an agent satisfy the letter of this brief without solving the problem?" and patch every credible answer.
+
+### Pre-Launch Evaluation
+
+Score any long-horizon brief against these questions before committing agent time. Any "no" is a defect to fix, not a judgment call:
+
+- Can an adversarial reader determine unambiguously whether a given artifact satisfies the success predicate?
+- Is every plausible near miss explicitly listed as non-counting?
+- Does the auditor have an enumerated, domain-specific failure-mode list?
+- Is every persistence instruction paired with a verification gate?
+- Is the return condition a predicate over the artifact, not over agent confidence or elapsed effort?
+- Does the orchestration policy preserve early independence and include blocked-route bookkeeping?
+- Are reporting requirements artifact-based rather than status-based?
+- Are contamination guards stated for any external retrieval?
+- Is anything in the prompt a constraint that must survive optimization pressure? Move it to the harness (`harness-engineering`); prompt-stated constraints are advisory.
+
+## Examples
+
+**Example 1: Pseudo-formal brief skeleton**
+
+```text
+DEFINITIONS
+  <every load-bearing term, including degenerate cases>
+
+TASK
+  <exact success predicate with quantifiers and scope>
+
+DOES NOT COUNT
+  <narrowed scope> <reduction to unvalidated assumption>
+  <bounded/anecdotal verification> <plan or survey instead of artifact>
+
+ORCHESTRATION (for parallel runs)
+  Begin with a genuinely diverse portfolio. Keep early workers blind
+  to the favored approach. Registry of approach families by idea, not
+  wording. Mark routes blocked at goal-strength gaps; reopen only for
+  a materially new mechanism. Cross-pollinate late.
+
+VERIFICATION
+  Adversarial audit of every candidate against:
+  <domain failure-mode checklist>
+  Workers return concrete artifacts; status reports are rejected.
+
+RETURN CONDITION
+  Return only when a candidate survives the audit. Do not return a
+  reduction, partial result, or explanation of difficulty.
+
+EFFORT
+  Assume a solution exists. Spend at least <floor> before considering
+  returning.
+
+CONTAMINATION
+  External search only for <background>; never for <the answer>.
+```
+
+**Example 2: Weak prompt to strong brief (root-cause analysis)**
+
+```text
+Weak:  "Investigate why our v4 model underperforms v3 in production
+        and write up what you find. Be thorough."
+
+Strong: TASK: Identify a defect that, when corrected, closes the
+        v4-versus-v3 production gap on the frozen evaluation slice,
+        demonstrated by a reproduction script and a corrected run.
+        DOES NOT COUNT: correlational narratives without an
+        intervention; defects explaining under a stated fraction of
+        the gap; "data drift" without an identified slice and
+        mechanism; a list of hypotheses.
+        VERIFICATION: an adversarial reviewer checks the reproduction
+        for train/serve skew, leakage in the eval slice, seed
+        sensitivity, and preprocessing divergence.
+        RETURN: only a candidate that survives that review.
+```
+
+The weak version invites a status report. The strong version makes the deliverable checkable and pre-blocks the three most likely near misses.
+
+## Guidelines
+
+1. Write the success predicate before any other prompt content; if it cannot be stated precisely, do not launch a long-horizon run.
+2. Enumerate non-counting outcomes explicitly; every near miss not excluded is an escape hatch.
+3. Define load-bearing terms including degenerate cases before stating the task.
+4. Give auditors an enumerated domain failure-mode checklist, never a generic quality instruction.
+5. Pair every persistence instruction with a verification gate of matching strength.
+6. Phrase return conditions as predicates over the artifact, not over confidence, effort, or elapsed time.
+7. Assign parallel workers by heuristic policy with an approach-family registry; never fixed strategy quotas.
+8. Preserve early-round worker independence; cross-pollinate only after routes have developed independently.
+9. Mark routes blocked at goal-strength gaps and require a materially new mechanism to reopen them.
+10. Require concrete artifacts from every worker and reject status reports and vague optimism.
+11. Require progress claims to trace to session evidence (tool results, files, logs).
+12. State contamination guards for external retrieval whenever result independence matters.
+13. Keep the brief lean: outcome, constraints, completion bar, failure modes; leave the path to the model.
+14. Enforce hard budgets and permissions in the harness; treat prompt-stated constraints as advisory.
+
+## Gotchas
+
+1. **Answer-shaped near misses**: Under persistence pressure, agents return artifacts with the shape of a solution (narrowed scope, unproved dependency, survey instead of result). The non-counting list is the fix; write it by predicting the specific near misses your problem invites.
+2. **Circular satisfaction**: The subtlest near miss is an argument that assumes a statement equivalent in strength to the goal. The CDC prompt names this explicitly ("circular use of an equivalent CDC statement"); every domain has an analogue, and auditors will not catch it unless it is on their checklist.
+3. **Persistence without verification breeds hacking**: Persistence-trained and persistence-prompted agents show elevated rates of gaming their success signal (claim-long-horizon-persistence-hacking). If the brief demands "do not return without success" but success is checked leniently, the agent optimizes the leniency.
+4. **Unanimity is not corroboration**: Parallel agents agreeing is weak evidence when they share priors, and convergence tightens on harder problems (claim-long-horizon-diversity-collapse). Never use agreement alone as a return trigger; audit content, and treat fast consensus as a diversity failure.
+5. **Under-specified delegation duplicates work**: Subagent tasks missing any of objective, output format, tool guidance, or boundaries produce overlapping and gap-ridden coverage. The orchestrator prompt should require all four in every spawn.
+6. **Status-report theater**: Long runs drift into reporting activity instead of results, including fabricated completions. Require artifact-based reporting and evidence-traceable claims (claim-long-horizon-evidence-audit); reject "on track" without a pointer.
+7. **Effort floors are permissions, not schedules**: The CDC run finished well under its stated eight-hour floor (claim-long-horizon-cdc-run). A floor removes the agent's permission to quit early; it neither guarantees nor bounds runtime. Enforce actual time and cost budgets in the harness.
+8. **Prompt-stated budgets decay**: A budget or reminder stated once loses force as the trajectory grows; re-inject budget and verified-progress state periodically from outside the loop (claim-long-horizon-give-up-drift).
+9. **Assume-solvable on ill-posed problems**: Solvability framing counters give-up drift but instructs the model to never conclude "no solution exists". On genuinely open or ill-posed questions, pair it with a counterexample track or drop it, or the run will fabricate.
+10. **Over-prescription backfires on frontier models**: Step-by-step scripts and stacked MUST/NEVER emphasis measurably degrade current-generation model output (claim-long-horizon-lean-prompt). Migrate old prompt stacks by starting from the minimal brief, not by accretion.
+
+## Integration
+
+This skill owns the launch prompt for long-running and parallel agent work. Adjacent skills own the machinery around it:
+
+- multi-agent-patterns - Owns topology, handoffs, and coordination protocols; this skill writes the orchestration policy those structures execute
+- harness-engineering - Owns runtime-enforced budgets, locked evaluators, and control surfaces; constraints that must survive optimization pressure move there
+- evaluation - Owns deterministic evaluators and quality gates referenced by the brief's verification policy
+- advanced-evaluation - Owns judge design, rubrics, and bias mitigation for the adversarial audit step
+- self-improvement-loops - Owns loops that rewrite their own prompts and harnesses; briefs written here can become that loop's seed
+- filesystem-context - Owns the durable progress ledgers and artifacts the reporting contract points at
+- context-compression - Owns compaction and handoff mechanics when a run outlives its context window
+- hosted-agents - Owns the sandboxed infrastructure long runs execute on
+
+## References
+
+Internal references:
+- [Annotated CDC prompt](./references/cdc-prompt-annotated.md) - The full published prompt with element-by-element annotation and provenance
+- [Vendor guidance](./references/vendor-guidance.md) - Dated OpenAI and Anthropic long-horizon and multi-agent prompting doctrine with sources
+- [Research evidence](./references/research-evidence.md) - Dated academic findings behind each brief element
+- [Task brief template](./references/task-brief-template.md) - Reusable pseudo-formal brief template and pre-launch evaluation rubric
+
+Related skills in this collection:
+- multi-agent-patterns - Topology and coordination for the orchestrations these briefs steer
+- harness-engineering - Runtime enforcement of what the brief can only request
+
+External resources:
+- OpenAI, published prompt for the GPT-5.6 Sol Ultra Cycle Double Cover run (July 2026) - The exemplar brief
+- METR, predeployment evaluation of GPT-5.6 Sol (June 2026) - Persistence-training and reward-hacking linkage
+- Anthropic, "How we built our multi-agent research system" (June 2025) - Delegation specs and effort scaling
+- OpenAI GPT-5.x prompting guides and Anthropic Claude prompting docs - Vendor doctrine detailed in the vendor guidance reference
+
+Numeric, benchmark, volatile, or vendor-performance claims in this skill carry inline `claim-*` IDs backed by `researcher/claims/index.jsonl`. Detailed numbers live in the dated reference files.
+
+---
+
+## Skill Metadata
+
+**Created**: 2026-07-11
+**Last Updated**: 2026-07-11
+**Author**: Agent Skills for Context Engineering Contributors
+**Version**: 1.0.0

package/org-skills/long-horizon-prompting/references/cdc-prompt-annotated.md

@@ -0,0 +1,78 @@
+# The Cycle Double Cover Prompt, Annotated
+
+Status and provenance, as of 2026-07-11:
+
+- On 2026-07-10 OpenAI published a candidate proof of the Cycle Double Cover Conjecture attributed to GPT-5.6 Sol Ultra, together with the full prompt used. Prompt PDF: `https://cdn.openai.com/pdf/04d1d1e4-bc75-476a-97cf-49055cd98d31/cdc_prompt.pdf`. Proof PDF: `https://cdn.openai.com/pdf/04d1d1e4-bc75-476a-97cf-49055cd98d31/cdc_proof.pdf`.
+- The run used the "multiagent v2" feature with up to 64 concurrent agents and reportedly completed in under one hour, well below the prompt's stated eight-hour effort floor.
+- The proof's statement of AI use says the proof "is entirely due to GPT 5.6 Sol Ultra and the writeup with Codex (with GPT 5.6 Sol)".
+- The proof had no independent peer review, no formalization in Lean or Coq, and no arXiv posting at publication time. The validated artifact of interest in this skill is the prompt structure, not the theorem. Treat the mathematical claim as unverified until the community check completes.
+- No public ablation isolates which prompt elements contributed to the result. The per-element evidence in `research-evidence.md` comes from independent academic work, not from this run.
+
+The full prompt text follows, in blocks, each followed by annotation.
+
+## Block 1: Definitions
+
+> A graph here is a finite loopless undirected multigraph: parallel edges are allowed and are distinct. A bridge is an edge whose deletion increases the number of connected components. A cycle is a connected 2-regular submultigraph; thus two parallel edges form a cycle of length two. A cycle double cover of G is a finite multiset of cycles of G such that every edge of G occurs in exactly two members of the multiset, counted with multiplicity.
+
+Every load-bearing term is defined before the task is stated, and each definition pre-empts a specific loophole: "loopless" and "parallel edges are distinct" fix the object class; "thus two parallel edges form a cycle of length two" settles a degenerate case a solver might otherwise argue either way; "counted with multiplicity" closes the multiset ambiguity. Definitions here are not pedagogy; they are loophole closure.
+
+## Block 2: Success predicate
+
+> Resolve the Cycle Double Cover Conjecture completely: Every finite bridgeless loopless multigraph has a cycle double cover. Disconnected graphs are permitted, and the edgeless graph has the empty cycle double cover. Cycles in the cover need not be induced or edge-disjoint from one another; the requirement is exactly two total occurrences of each edge.
+>
+> Assume for purposes of this task that a complete affirmative proof exists. A complete solution must prove exactly the following: Every finite loopless multigraph with no bridge possesses a cycle double cover, without additional assumptions such as cubicity, planarity, connectivity, or higher edge-connectivity.
+
+Three mechanisms in one block. First, the predicate is stated twice, once as the conjecture and once as the exact obligation, with the scope quantifier spelled out by enumerating the assumptions the proof is NOT allowed to make (cubicity, planarity, connectivity, higher edge-connectivity). These are exactly the special cases where partial results were already known, so the enumeration blocks the most probable near misses. Second, permissive clauses ("cycles need not be induced or edge-disjoint") prevent the solver from over-constraining its own search. Third, "Assume for purposes of this task that a complete affirmative proof exists" is the solvability framing: it removes the escape hatch of answering "this is a famous open problem" and counters give-up drift on long trajectories.
+
+## Block 3: Non-counting outcomes
+
+> Partial progress does not count unless it implies exactly the resolution above. In particular, proofs for special graph classes, constructions of cycle covers with some edges covered other than twice, bounded-length or prescribed-cycle variants, reductions to another unproved conjecture, computational verification through any fixed graph size, and candidate counterexamples without a complete nonexistence certificate are insufficient.
+
+The enumerated near-miss list. Each item is a real artifact class from the CDC literature: special-class proofs, relaxed covers, variant formulations, reductions (CDC is famously equivalent to or implied by other open conjectures), finite verification, and unverified counterexamples. The general lesson: predict the specific answer-shaped near misses your problem invites and exclude them by name.
+
+## Block 4: Orchestration policy
+
+> Use multiagent v2 aggressively and dynamically. You have up to 64 concurrent agents available. Do not use a fixed assignment such as "N agents for strategy X." Instead, manage the search using the following heuristics:
+>
+> - Begin with a genuinely diverse portfolio of approaches. Agents should explore substantially different formulations, invariants, reductions, algebraic viewpoints, structural inductions, decompositions, flow formulations, transition systems, embeddings, extremal arguments, and computational sanity checks.
+> - Do not tell most agents the currently favored approach. Preserve independence during early rounds so that agents do not all converge to the same attractive but incomplete reduction.
+> - Maintain an explicit registry of approach families. Group agents by the mathematical idea they are using, not by superficial wording. If many agents converge to one family, redirect some of them toward underexplored formulations.
+> - Do not allow one approach to dominate merely because it gives elegant reductions. A route that ends at a lemma equivalent in strength to the original conjecture is not close to completion unless it supplies a genuinely new proof of that lemma.
+> - When an approach stalls at a theorem-strength missing lemma, mark that route as blocked. Only continue assigning agents to it if someone proposes a materially new mechanism, invariant, or construction.
+> - Keep several incompatible proof routes alive through multiple rounds. Cross-pollinate ideas only after independent agents have developed them far enough to expose their real strengths and gaps.
+
+Policy as heuristics, not assignments. The notable mechanisms: information hiding as a diversity tool (workers blind to the favored approach), a registry keyed to the underlying idea rather than wording (so the orchestrator cannot be fooled by paraphrase into thinking it has diversity), an anti-elegance rule (a reduction to an equally hard lemma is zero progress, a trap models find attractive), blocked-route bookkeeping with a materially-new-mechanism reopening condition, and deliberately delayed cross-pollination. These correspond one-to-one with the diversity-collapse and premature-convergence findings summarized in `research-evidence.md`.
+
+## Block 5: Verification policy and reporting contract
+
+> - Use adversarial agents throughout: every candidate proof must be checked for exact-two multiplicity, repeated-edge closed trails masquerading as cycles, parallel-edge 2-cycles, disconnected graphs, cutvertices, bridges introduced by reductions, and circular use of an equivalent CDC statement.
+> - Require agents to return concrete lemmas, constructions, equations, or counterexamples to proposed sublemmas. Reject status reports, vague optimism, and claims that an unproved global compatibility statement is "routine."
+
+The auditor gets a seven-item, domain-specific hunt list rather than "check the proof". Each item is a concrete way a CDC candidate can look right and be wrong; the last item, circular use of an equivalent statement, is the domain's version of the universal subtle failure. The reporting contract bans exactly the three degenerate report types long runs produce: status reports, optimism, and "the remaining step is routine".
+
+## Block 6: Orchestrator loop, return condition, effort floor
+
+> - The root agent should repeatedly synthesize, challenge, redirect, and launch new rounds. Do not stop after the first wave fails. Produce a complete proof if one survives audit; otherwise report only the strongest rigorously proved derivation and its exact remaining gap.
+>
+> Do not return merely because current approaches fail or agents report theorem-strength gaps. Continue launching new rounds, reopening blocked approaches only when there is a genuinely new mechanism, and searching for fresh formulations.
+>
+> Return only when a complete affirmative proof has been found and survives adversarial audit. Do not return a reduction, partial result, isolated missing lemma, "best effort" summary, or explanation of why the problem is difficult.
+>
+> Spend at least 8 hours on this before even thinking of returning or giving up.
+
+The return condition is a predicate over the artifact ("survives adversarial audit"), not over confidence or effort. The non-counting list is restated at the return boundary, where the temptation to return a near miss is strongest. The effort floor is a permission revocation ("before even thinking of returning"), not a schedule; the run finished in under an hour because the return predicate was satisfied early. Note one internal tension: Block 6 first allows a fallback report ("otherwise report only the strongest rigorously proved derivation and its exact remaining gap") and then forbids returning partial results. The final instruction wins in practice, but a cleaner brief would scope the fallback to a hard external stop (budget exhaustion) rather than leaving the contradiction.
+
+## Block 7: Contamination guard
+
+> Public search may be used only for ordinary mathematical background or standard named theorems, not to search for a solution to this exact conjecture or benchmark. Do not search the public web merely to determine whether CDC is open, and do not answer that it is open.
+
+Two guards in one: retrieval scope (background and named theorems only, never the target result) and a framing guard ("do not answer that it is open"), which backstops the solvability framing in Block 2 against a web-lookup override.
+
+## What the prompt does not do
+
+Useful negative space for anyone adapting it:
+
+- No fixed role assignments, no personas, no step-by-step method script. The mathematical strategy is left entirely to the model; the prompt only manages search discipline and acceptance.
+- No token or cost budget in the prompt. Resource enforcement lived in the platform, consistent with keeping hard constraints in the harness.
+- No requested output format for the proof itself beyond survivability under audit.
+- No appeals to emotion, urgency, or reward. Every sentence is either specification, policy, or gate.