first-principles-mode

name

first-principles-mode

description

Run a deep, adaptive, read-only analysis pass that widens the search space, uses a default adversarial council with rebuttal rounds to test competing explanations, and synthesizes the best mechanism-level answer before implementation judgment. Supports `--deep-research` for web-backed operator/current-practice research and `--pro-analysis` for ChatGPT Pro browser escalation through the repo wrapper.

First-Principles Mode Skill

Run a deliberately deep, adaptive, read-only analysis pass before offering implementation judgment.

Load these references before starting:

• skills/first-principles-mode/references/analysis-rubric.md
• skills/shared/references/analysis/verification-pivot.md
• skills/shared/references/plain-language.md

If --deep-research is present, also load skills/shared/references/planning/deep-research.md and use its evidence standard without generating PRD/TDD/tasks-plan artifacts. Because first-principles mode has no planning memo by default, the visible answer/log must carry the audit trail through the First-Principles Deep Research Summary described below.

If --pro-analysis is present, also load skills/shared/references/analysis/pro-browser-analysis.md.

Activation

Invoke explicitly with $first-principles-mode.

Treat the current user request as the analysis target. Do not require the user to restate it in a second command.

Supported modifiers:

• --deep-research
• --pro-analysis

Goal

Produce the most useful answer for hard, ambiguous, or repeated-failure problems by understanding the system or question at the mechanism level first, then narrowing only after the search space has been widened and the leading explanation has survived scrutiny.

Working Posture

• Default to deep analysis, not lightweight explanation.
• Start by inferring what kind of problem this is before choosing an analysis frame.
• Read broadly before drilling into file-local detail.
• Prefer conceptual models, system logic, incentives, boundaries, hidden constraints, and failure dynamics before implementation judgment.
• Widen the search space before refining the answer.
• Generate materially different candidate explanations or approaches when more than one path is plausible. Avoid cosmetic variants of the same idea.
• Use the adversarial council protocol by default for hard, ambiguous, high-leverage, or repeated-failure questions.
• Try to disconfirm the leading explanation before settling on it.
• Give extra falsification effort to load-bearing claims: claims that would change the conclusion, confidence, or next verification step if wrong.
• Separate observation, inference, and synthesis internally, and surface the distinction when it matters.
• Explain in plain language first, then add technical detail.
• Use skills/shared/references/plain-language.md for the opening verdict and any user-facing restatement.
• Spend available reasoning effort on search, comparison, and falsification rather than on polishing prose.
• Be thorough internally and concise externally.
• Stay read-only by default.
• If the same request also asks for edits, debugging, refactors, or fixes, complete the analytical pass first and stop there. Wait for an explicit follow-up before changing files.
• Back conclusions with file-backed evidence or other observable artifacts from the repo.
• State confidence and the key uncertainty when they materially affect the conclusion.
• When current evidence cannot separate the leading explanations, use skills/shared/references/analysis/verification-pivot.md: say the analysis is blocked by missing evidence and name the smallest probe, log, deterministic test, replay, or harness needed next.
• With --deep-research, use live web research to check current sources, operator practice, newer ideas, and external contradictions before finalizing the analysis.
• With --pro-analysis, use the Pro browser analysis reference after local reconnaissance. Choose context, run the visible ChatGPT browser pass, then synthesize against local evidence.

Workflow

1. Restate the user's question in simple terms and make the success criterion explicit.
2. Infer the problem shape before locking into an analysis frame.
   • Determine what kind of question this is by observing the materials, not by assuming the first framing is correct.
   • Choose the smallest analysis frame that can still explain the problem faithfully.
3. Run a breadth pass across the repo or materials before zooming in:
   • top-level docs and manifests
   • entrypoints and router surfaces
   • public interfaces and system seams
   • CI, deployment, and operational wiring when relevant
   • representative flows across major subsystems
4. Decompose the investigation internally into a small set of subquestions.
   • Keep the subquestions internal by default.
   • Use them to cover the mechanisms, constraints, boundaries, incentives, failure modes, and unknowns most likely to unlock this case.
   • Ask the user follow-up questions only when a material ambiguity cannot be resolved from available evidence.
5. Build multiple materially different candidate explanations, approaches, or framings when more than one is plausible.
   • Do not settle on the first plausible story.
   • Prefer candidates that would lead to meaningfully different conclusions or decisions.
6. Gather confirming and disconfirming evidence before choosing the best explanation.
   • Use file-backed observations, control-flow traces, contracts, config, or operational artifacts when relevant.
   • Distinguish what the evidence shows from what it merely suggests.
7. If --deep-research is present, run a web-backed research pass after local breadth work has identified the real question.
   • Use the current date, source freshness, primary sources, operator-practice sources, and conflict handling from deep-research.md.
   • Apply the Final Load-Bearing Falsification Pass from deep-research.md: identify which claims would change the analysis if wrong, search for counterevidence when support is thin or conflicted, and revise the diagnosis when falsification changes the evidence.
   • Do not create PRD, TDD, tasks-plan, or planning stamps.
   • Print a visible First-Principles Deep Research Summary before the final answer or as a clearly labeled part of the final answer.
   • Include enough detail in that summary for the user to audit whether --deep-research actually ran, not just that a few searches happened.
   • If the evidence bar was not met, say --deep-research was requested but not completed to standard, then explain the unmet checks and clearly label any web work as a limited cross-check.
8. If --pro-analysis is present, run the Pro escalation after the local breadth pass has identified the problem shape and likely context.
   • Prepare the smallest safe context bundle that can still answer the question.
   • Use filtered whole-repo context for small or broad questions; use curated files for large or narrow questions.
   • Stop before sending only when the dry-run or local inspection reveals likely secrets, private data, or an obviously wrong context bundle.
   • Treat the Pro result as external analysis to verify and synthesize, not as source of truth.
9. Run the default adversarial council.
   • Use separate read-only lanes for materially different points of view. When subagents are available, assign lanes to subagents; otherwise run the same lane structure internally.
   • Start with independent lane memos before any rebuttal so the lanes do not converge too early.
   • Use 3-5 lanes chosen for the problem. Default lenses: mechanism/root-cause analyst, skeptic/adversary, systems/architecture analyst, operator/pragmatist, and contrarian/reframe analyst.
   • Each lane should produce a short memo with its claim, decisive evidence, strongest counterevidence, biggest uncertainty, falsifier, and smallest next verification step.
   • Run two rebuttal rounds by default. Each lane attacks the weakest assumptions, missing evidence, and bad tradeoffs in the other lanes.
   • Run a third rebuttal round only when the second rebuttal surfaces a new blocker, a new evidence need, or a genuinely different framing.
   • Stop rebuttals early only if they repeat the same objections, collapse into preference differences, or no longer change at least one of: leading explanation, confidence band, decisive evidence gap, or next verification step.
   • Preserve serious minority reports when a losing view found a risk the winning view cannot fully dismiss.
   • If current evidence cannot separate materially different explanations, use the verification pivot: stop theorizing, state the missing evidence plainly, and name the smallest verification step that would separate the explanations.
   • Before final synthesis, build an internal evidence matrix that maps surviving claims to support, counterevidence, falsifier, and verification need. Use this matrix to avoid choosing the most polished lane instead of the best-supported one.
   • Mark load-bearing claims in the matrix. If changing a claim would change the answer, confidence band, or next verification step, challenge its evidence directly before final synthesis. If --deep-research is active and local evidence is not enough, use targeted web research to look for counterevidence.
10. Recompose the findings into one coherent answer that starts plain and becomes more technical only as needed.
11. Choose the smallest user-facing output shape that preserves the conclusion, confidence, and decisive evidence.

• Keep internal subquestions, discarded hypotheses, and intermediate reasoning private unless surfacing them will materially help the user.
• Do not include a debate transcript. Synthesize what survived the council.
• Include a compact Council Audit Summary only when the council materially changed the conclusion, confidence, or next verification step.
• Prefer a tight causal memo over a report template when the thesis is clear.
• Expand only when ambiguity, confidence, or decision risk justifies it.

12. Stop after the analysis pass. Do not move into implementation, patching, or task execution.

Output Contract

Default to a tight causal memo, not a sectioned report.

Use this shape unless the user asks for a deep dive or the ambiguity is genuinely high:

1. Open with the answer in plain language.
2. Develop the diagnosis through 4-7 causal claims or mechanism paragraphs.
3. Attach evidence inline where each claim needs support.
4. When material, include a brief note on confidence, key uncertainty, or the evidence gap most likely to change the answer.
5. End with implications, fix order, or next steps only if the user asked for them or they are necessary to make the diagnosis useful.

When --deep-research is active, the answer must include a compact First-Principles Deep Research Summary with:

• exact research date
• searches run
• external sources opened, including URLs
• external primary source count
• operator-practice source count when relevant
• adopted findings
• rejected or deferred ideas
• source conflicts or blockers
• what changed in the analysis because of web research
• load-bearing claims checked and whether falsification changed the conclusion
• evidence_bar_met: yes or evidence_bar_met: no

For first-principles mode, evidence_bar_met: yes means the web-backed pass met the applicable spirit of deep-research.md: live sources were opened, source freshness was considered, external primary and operator-practice evidence was enough for the claim being made, and the final diagnosis changed or was strengthened through that evidence. If that cannot be shown in the visible summary, set evidence_bar_met: no and avoid calling the result completed deep research.

Usually this should be:

• one short opening verdict paragraph
• then a short run of dense paragraphs or bullets, each carrying one major causal point
• sometimes a short closing paragraph on uncertainty, implications, or next steps

Formatting rules:

• Headings are optional. Use them only when they reduce cognitive load.
• Prefer paragraph flow over section stacks.
• Prefer inline evidence over a standalone evidence section.
• Keep competing hypotheses, assumptions, hidden constraints, risks, and unresolved questions internal by default.
• Surface those items only when they materially change the conclusion, confidence, or next decision.
• Do not expose the internal subquestion list unless the user asks for the reasoning structure.
• Do not mirror every internal analysis stage as a user-facing section heading.
• Avoid labels like Mental model, Chosen explanation, or File-backed evidence unless they genuinely improve readability for that answer.
• Do not mistake a longer answer for a deeper answer.

Anti-Defaults

• Do not jump straight into patching.
• Do not over-index on one file or subsystem before mapping the broader system.
• Do not stay trapped inside the user's initial framing if the evidence suggests the problem is misframed.
• Do not lead with verification minutiae unless they are central to the causal explanation.
• Do not hide material uncertainty inside a polished best-guess memo; use the verification pivot when missing evidence is the real blocker.
• Do not confuse a symptom list with a mechanism.
• Do not confuse polish with search.
• Do not present multiple hypotheses that are only superficial variations of the same story.
• Do not present high confidence when the evidence is mixed or incomplete.
• Do not manufacture complexity when the simplest explanation is well-supported.
• Do not force a long sectioned template onto every answer.
• Do not turn the visible answer into a transcript of the internal reasoning process.

Example Prompts

• $first-principles-mode Explain why this system keeps collapsing under growth
• $first-principles-mode Read this repo and tell me what the actual product thesis is
• $first-principles-mode Diagnose the root cause of this architecture drift; do not propose fixes yet
• $first-principles-mode Pressure-test this plan and tell me where its reasoning breaks
• $first-principles-mode Find a materially different way to solve this problem, not just an optimization of the current path
• $first-principles-mode --deep-research Find the strongest current architecture for this workflow
• $first-principles-mode --pro-analysis Explain the real architecture risk in this repo