GPT Pro Analysis — Deep Reasoning via GPT-5.4 Pro (Manual)

Prepare any problem + relevant files into a structured package for manual upload to ChatGPT Pro. Domain-agnostic — works for code debugging, architecture review, data analysis, writing feedback, reverse engineering, research synthesis, or anything that benefits from deep reasoning over multiple files.

Workflow

UNDERSTAND → SCOPE → COLLECT → PROMPT → SANITIZE → PACKAGE → REPORT

Everything runs locally. The final step is a tar.gz on disk + prompt on clipboard, ready for you to paste into chatgpt.com.

Why a Structured Package Beats a Chat Dump

ChatGPT Pro excels at deep, long-context reasoning — but quality in = quality out. A structured PROMPT.md that frames the problem, sets the role, defines the output format, and indexes the attached files consistently produces 10x better results than pasting raw code into the chat. This skill encodes the prompt patterns that work.

Step 1: Understand the Task

Ask or infer from conversation context:

What's the question? — "Why is this broken?", "Review this architecture", "Analyze this data"
What expertise should GPT Pro adopt? — Match to the domain (senior engineer, editor, data scientist, etc.)
What output format? — Code fixes with file:line? A report? A redesigned component? A comparison matrix?

Step 2: Collect the Files (Be Generous)

Philosophy: more is more. GPT-5.4 Pro has a huge context window and is excellent at triaging — it will decide which files to read deeply and which to skim or ignore. Don't pre-filter aggressively; you'll strip out the one file that turns out to hold the clue. When in doubt, include it. Missing context is a bigger failure mode than "too much context".

Always include:

The file(s) directly implicated in the problem
Adjacent / dependent code (callers, callees, shared utilities, types)
Config / env that affects behavior (sanitized)
Sample data showing the issue (logs, errors, outputs, examples)
A file tree of the repo (tree -L 4 -I 'node_modules|target|.git|__pycache__' > tree.txt) so GPT Pro sees the full universe even for files not attached
A recent git log (git log --oneline -n 50 > git-log.txt) — recent commits often explain what broke
Any README.md, CLAUDE.md, or architecture docs in the repo

Include generously when even tangentially related:

Tests (they document expected behavior)
Related modules in the same feature area
Prior version of the file (via git show HEAD~5:path/to/file > prior-version.txt)
Reference / comparison material — competitor code, working example, spec documents
Prior analysis / decision logs / ADRs
Package manifests (package.json, Cargo.toml, pyproject.toml) so versions are unambiguous

Only exclude:

Secrets (see Step 5 — mandatory sanitization)
Build artifacts: node_modules/, target/, dist/, build/, __pycache__/, .next/
Binary blobs (images, fonts, compiled libs) unless directly relevant
Machine-generated lockfiles >10MB (ok to include smaller ones)
Vendored third-party code unless it's the subject of the review

Step 3: Build the Package Directory

<descriptive-name>/
├── PROMPT.md           # THE key file — structured task + questions
├── tree.txt            # Full repo tree (tree -L 4 -I '...' > tree.txt)
├── git-log.txt         # Recent commits (git log --oneline -n 50)
├── source/             # Relevant source files (preserve original names)
│   ├── module_a.py
│   ├── module_b.rs
│   └── Component.tsx
├── adjacent/           # Callers, callees, shared utils, types
│   └── ...
├── tests/              # Related tests — document expected behavior
│   └── ...
├── data/               # Supporting evidence — logs, outputs, examples
│   ├── error_log.txt
│   ├── sample_output.json
│   └── expected_vs_actual.md
├── docs/               # README, architecture notes, ADRs, CLAUDE.md
│   └── ...
├── reference/          # Comparison material, prior analysis, competitor code
│   └── prior_findings.md
└── config/             # Sanitized config, package manifests
    ├── env_sanitized.txt
    ├── package.json
    └── Cargo.toml

Adapt the subdirectory names to the domain. For a book review it might be chapters/, research/, and feedback/. For data analysis it might be datasets/, schemas/, and notebooks/. Use whatever makes sense — and lean toward more folders / more files rather than fewer.

Step 4: Write PROMPT.md

This is the most important file. GPT-5.4 Pro starts with ZERO project knowledge — it cannot infer your stack, build tooling, conventions, or file layout without you telling it. Even though you're attaching many files, the PROMPT.md is what tells GPT Pro why those files are there, what to look at first, and what you actually want back. Without a strong PROMPT.md, a big bundle becomes noise.

The "Exhaustive Prompt" Pattern

Short, vague prompts on large bundles yield generic answers. Lean into depth — a strong prompt is typically 500-2000 words and follows this structure:

Top: Project briefing — stack, build/test commands, platform constraints, key directories
Middle: Exact question + what you already tried + verbatim errors
Bottom: Constraints + desired output format + file index

The more files you attach, the more the PROMPT.md needs to act as a map: point GPT Pro at the 2-3 files where the investigation should start, while making clear the rest are available as context to pull on.

PROMPT.md Template

# <Title — What You Want Analyzed>

## Your Role

You are a senior <domain expert> conducting <type of analysis>. You have deep expertise in <relevant technologies/fields>.

**Rules:**
1. Base every conclusion on evidence from the files provided. Flag speculation as `[HYPOTHESIS]`.
2. Don't tell me what's working. Tell me what's wrong/missing/improvable and how to fix it.
3. For each finding: root cause, evidence (file:line or specific quote), fix, expected impact.

## Project Briefing

<Stack, frameworks, language versions, platform targets. GPT Pro can't guess this.>
- **Stack:** <e.g., Next.js 15, TypeScript 5.8, Supabase, Vercel>
- **Build:** <e.g., `pnpm build`, `cargo test`, `npm run dev`>
- **Platform:** <e.g., macOS/iOS, Linux server, browser SPA>
- **Key directories:** <e.g., `src/` = app code, `lib/` = shared utils, `supabase/` = migrations>

## Context

<2-4 paragraphs explaining the system/project — what it does, how it works, current state. Include enough for GPT Pro to understand the architecture without needing to infer it from code alone.>

## Current Situation

<Quantified state — metrics, error rates, performance numbers, word counts, whatever is measurable. Concrete data, not vibes.>

## What We Already Tried

<Critical section. List what was attempted and why it didn't work. Prevents GPT Pro from suggesting things you already ruled out.>

1. <Approach 1> — <why it failed or was insufficient>
2. <Approach 2> — <result>

## Questions

### Q1: <Specific, answerable question>
**Data:** <Point to specific files in the package>
**Hypotheses:** <2-3 possible explanations to investigate>

### Q2: <Next question>
**Data:** <File pointers>

### Q3-N: <As many as needed, usually 3-7>

## Where to Start

<The bundle is large. Tell GPT Pro where to begin so it doesn't burn thinking budget on irrelevant files.>

**Start with:** `source/<primary-file>` and `data/<key-evidence>`. These are where the problem manifests.
**Then check:** `adjacent/<caller>` and `tests/<failing-test>` to verify the control flow.
**Everything else** (docs, reference, tree, git-log) is context — pull on it when the primary files raise questions.

## Files Included

<The bundle may contain dozens of files — this table is the navigation index. List every file with a one-line description of what it is and why it's attached. Group by folder.>

**Core (primary investigation)**
| File | Role |
|---|---|
| `sou

gpt-pro