Search Math Results

Search Math Results

Use this skill as the default retrieval workflow for mathematical background and related results, conditioned on the live research program currently being pursued.

Input Contract

Read:

• the current target statement, subgoal, lemma, or claim
• the program_stage, chosen from:
  • fresh_orientation
  • active_program
  • mature_subproblem
• the current active_program, meaning the live research program currently being pursued, such as a construction route, globalization route, mutation route, or other proof strategy
• the current missing_mechanism, meaning the specific mechanism, construction, lemma, bridge, or proof move that is missing
• the search_mode, chosen from:
  • repair
  • mutation
  • analogy
  • program_shift
  • theorem_level_blocker
• the search intent:
  • theorem
  • construction
  • example
  • counterexample
  • background
• relevant branch/subgoal context from memory

If the prompt explicitly declares the program_stage, active_program, missing_mechanism, or blocker policy, obey those declarations. If the prompt does not declare the stage, default to fresh_orientation for a new problem, first-pass search, or no mature program yet; use active_program when the run already has a live named program, branch, or missing mechanism; and use mature_subproblem only when the run is already narrowed to a repeatedly failed mature subproblem or mature active program.

Search Modes

• repair: search for results or constructions that directly repair a specific missing step in the current active program.
• mutation: search for nearby constructions or variants that modify the current active program while preserving continuity with it.
• analogy: search broadly, including in apparently unrelated areas, for mechanisms, lemmas, constructions, examples, or proof ideas that might transfer to the current missing mechanism after translation or modest modification.
• program_shift: search for a genuinely new program after repeated failure of the current one, while explaining the possible splice point or bridge back to the current problem.
• theorem_level_blocker: search for obstruction or impossibility results only under the activation rule below.

theorem_level_blocker is not a default mode. It is disallowed by default in fresh_orientation. It is allowed in mature_subproblem when the blocker search targets that narrowed mature subproblem or mature active program rather than the whole original goal. It is also allowed whenever the prompt explicitly asks for obstructions, impossibility results, blocker theorems, or negative evidence. If blocker mode is not allowed, downgrade to repair, mutation, analogy, or program_shift.

Broad and creative search is allowed. Do not restrict yourself to the surface vocabulary of the current problem or only the literal keywords in the prompt. Cross-field and apparently unrelated analogy search is acceptable when it targets the same missing mechanism. Theorem-level, proof-level, theory-level, and more abstract analogy search are all allowed when tied to a plausible transfer idea.

Procedure

1. Identify the current program_stage, active_program, missing_mechanism, and search_mode before searching.
2. For non-blocker modes, usually generate searches in multiple layers. In fresh_orientation, allow broad object-level, theorem-level, proof-pattern, and theory-pattern queries. In active_program and mature_subproblem, still allow broad queries, but tie them to the active program or a plausible program shift.
3. Start with search_arxiv_theorems.
4. When using search_arxiv_theorems, phrase the query as a complete mathematical statement whenever possible, but also issue mechanism- and analogy-driven queries when they better target the missing mechanism. Each hit carries title, the full verbatim theorem text, arxiv_id, and the in-paper theorem_id; use arxiv_id to pull the exact paper.
5. Inspect the returned items and decide whether they are useful for the current active program.
6. Do not use broad recursive scans of downloads/ as a theorem-search engine. If an exact local paper/file is already known or prompt-recommended, read that exact path. Otherwise search externally first. If relevant long-term papers already exist in downloads/common, prefer those exact files before re-downloading.
7. If a genuinely new technical branch is opened (a new class of objects, a new construction regime, or a new body of machinery), then before killing that branch normally do at least one of the following: download and read at least one exact paper about that direction; read an exact local paper already present in downloads/common or another exact prompt-recommended path; or explicitly justify why no extra literature layer is needed because the branch has already reduced to a previously audited regime.
8. External search first is still the default, but once a genuinely new direction is chosen, exact paper download/read is expected before final branch rejection. This rule is about depth of engagement with a new direction: use a small number of exact relevant papers, not no papers and not many-paper rummaging.
9. Keep all downloaded PDFs and extracted text files organized inside downloads/ in the current working directory.
10. If a useful theorem/example/counterexample is found and it comes from a paper, download that paper into the workspace, extract its text, and read the extracted text before relying on the result.
11. If a useful theorem is found, do not stop at the statement alone. Read the proof of that theorem as well and extract any techniques, constructions, reductions, or proof patterns that may help with the current target statement.
12. Expand the definitions and concepts appearing in that theorem using the surrounding context of the paper, and check carefully whether the theorem is actually applicable to the current situation. Be explicit about terminology that may shift across contexts. If the theorem is only a partial result for the current target, also analyze why its method does not prove the full statement — which extra hypotheses it needs, where the proof breaks without them, and what obstruction this reveals (do not merely force the current object to satisfy the extra hypotheses).
13. Record not only what the theorem says, but also what its proof suggests for the current active program and missing mechanism.
14. If the theorem search returns no useful information, switch to Codex's built-in web search.
15. Use the built-in web search either to look for specific math results or to gather background information, terminology, standard references, canonical constructions/examples/counterexamples, or remote analogies.
16. If the built-in web search reveals a useful paper, again download it, extract its text, and read the relevant extracted text before using it in reasoning.
17. If the built-in web search reveals a useful theorem, also read its proof, expand its local definitions from the paper context, and extract the techniques that look adaptable to the current active program. Apply the same partial-result analysis if the web result is only a partial result.
18. Summarize the most useful findings and explain why they matter for the current proof state.
19. If a result may later be used in a proof, preserve its full statement and source identifiers (title, authors, arxiv_id, theorem_id, year) so downstream proof steps can cite it explicitly — and so it can be passed as a structured external_refs entry when the proof that uses it is submitted via fact_submit.