Proof Plan

Proof Plan

Turn a raw proof idea into a compact GPT-pro prompt bundle that the user can review before spending GPT-pro budget.

This skill is a product-manager-style standardization agent. Codex clarifies, formalizes, and packages the user's idea: target claims, notation, source materials, user-stated givens, unresolved questions, and the exact questions GPT-pro should answer. Codex may perform only mechanical local checks needed to avoid malformed handoffs, such as verifying that cited files exist, normalizing notation, and flagging obvious inconsistencies from the supplied materials. Proof-gap diagnosis, substantive repairs, central theorem claims, and lemma completion belong in the GPT-pro task or another explicitly approved reviewer path, not in local silent completion. Assume GPT-pro is mathematically strong and broadly knowledgeable, but does not know this project's purpose, local notation, user intent, or which source materials are authoritative.

Output Directory

Create one run directory per idea:

mindflows/<YYMMDDHH-num>/

Use local time for YYMMDDHH. Use a two-digit counter such as 01, 02, 03; choose the next unused counter when several ideas are prepared in the same hour.

The minimal GPT-pro-facing bundle is:

mindflows/<YYMMDDHH-num>/task.md
mindflows/<YYMMDDHH-num>/materials.md

Optional local-only files may be added when useful:

mindflows/<YYMMDDHH-num>/codex-notes.md
mindflows/<YYMMDDHH-num>/review.md
mindflows/<YYMMDDHH-num>/sources/

Do not force a fixed section list into task.md or materials.md. Include only the information GPT-pro needs to do the assigned proof task well.

Workflow

1. Read the user's idea and only the local files needed to understand notation, user-stated conditions, and source materials.
2. Normalize the idea into a GPT-pro task:
   • what GPT-pro is being asked to prove, disprove, repair, or diagnose;
   • which local materials are authoritative inputs;
   • which givens or constraints the user explicitly stated;
   • which unresolved points should be passed to GPT-pro as questions rather than resolved locally;
   • which claims are targets or context rather than locally established facts.
3. Write task.md as the GPT-pro-facing instruction. Keep project motivation short; include only enough context for GPT-pro to understand why the task matters.
4. Write materials.md as the GPT-pro-facing task materials. This may contain pasted definitions, notation, source excerpts, formal target statements, and pointers to files in sources/.
5. If needed, copy directly readable source snapshots into sources/. Prefer exact local material over memory.
6. Write review.md when the user needs an approval checkpoint. This file should make it easy for the user to see what GPT-pro will be asked and which inputs are being sent.
7. If Codex performed a mechanical local consistency check, record it in codex-notes.md or review.md with its dependency on the supplied materials. Do not add local proof claims to task.md; ask GPT-pro to diagnose or prove them instead.
8. Stop for user review unless the user already explicitly approved handoff packaging.

GPT-pro Prompt Rules

task.md should tell GPT-pro to:

• give a direct conclusion first;
• separate proved statements, conjectures, imported results, repaired statements, and unsupported claims;
• classify gaps as detail-fillable, requiring additional assumptions, requiring an external theorem, or not currently provable from the supplied materials;
• label any assumption GPT-pro adds beyond the materials as a proposed repair;
• avoid inventing citations, theorem numbers, regret bounds, or proof obligations;
• use Obsidian-compatible Markdown math with $...$ and $$...$$.

Route-Neutral Task Rule

Assume GPT-pro is brilliant and needs the mathematical task, not Codex's proof strategy. Codex must not search for, evaluate, sketch, hint at, exemplify, or recommend possible technical routes in GPT-pro-facing files. Describe only the target claim or diagnosis task, authoritative inputs, explicit givens, constraints, and unresolved questions. Keep research goals, user taste, project purpose, budget concern, orchestration state, local plausibility checks, legacy skill comparisons, and any Codex-side route thoughts in codex-notes.md or review.md, do not dispatch legacy proof workers unless the user explicitly requests a legacy comparison, and never mark a statement as proved before GPT-pro output and a later audit support it.