Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/gpt-pf-chat-gpt-project-forge/llms.txt

Use this file to discover all available pages before exploring further.

Project Forge is a structured preparation system for opening ChatGPT Projects. Rather than letting a project begin from chat momentum, remembered context, or implicit reconstruction, Project Forge gives you a disciplined preparation room: a place to close the target, classify information, validate sources, and produce a clean opening package of files that the real project can read at startup. The preparation room is not the project. The opening package is the bridge between them. Most workspaces give you a place to chat. Project Forge gives you a way to open a project on purpose.

The Problem It Solves

When a new ChatGPT Project starts without explicit structure, it tends to reconstruct its operating context from whatever is nearby: previous chat history, persistent memories, ambient session carry-over, or the model’s own best guess at what the project was supposed to know. That reconstruction is hidden. You cannot inspect it, version it, or hand it off cleanly. Scope creeps in from earlier conversations. Constraints that were decided informally get forgotten or silently overridden. The project feels continuous — but the continuity is fragile and unverifiable. Project Forge addresses this at the source. By preparing the opening package before the target project is created or entered, you ensure that what the project starts from is visible, explicit, and intentional. Files beat memory. If something matters, it belongs in a file.

The Core Boundary

The core defines the rules; the project package carries the state. If live project state enters the canonical core, Forge stops being clean. If the target project depends on chat memory, the opening package is not ready.
Project Forge maintains a hard boundary between what it knows in general and what belongs to any particular project. The canonical core — four governing files — defines stable, domain-agnostic rules that never change from case to case. The project package carries everything specific to the current preparation. Keeping these separate is not a detail of implementation. It is the system.

The Five Surfaces

Project Forge separates five distinct surfaces to prevent contamination between them:
SurfaceRole
Canonical coreThe stable, governing rules of Project Forge itself — never holds live case state
Project packageThe files prepared for one specific target project opening
Candidate materialSources, notes, and links that have not yet been validated as official basis
Initial official basisValidated starting ground that the target project may treat as authoritative
Handoff stateContinuity artifact emitted only when reconstruction across runs is genuinely unsafe
Each surface has a defined role. Mixing them — using the canonical core as a notebook, treating chat history as SSOT, writing handoff by default — is the most common failure mode the system is designed to prevent.

What Project Forge Produces

The output of a Project Forge session is an opening package: a set of files the target project reads at startup instead of relying on the preparation session as hidden state. The minimum useful opening package contains three files:
ArtifactPurpose
ENTRY_POINT.mdTells the target project how to read the package, what counts as official basis, and when to stop and ask
TARGET_PROJECT_BRIEF_ARTIFACTDefines objective, scope in, scope out, expected outputs, and project-specific constraints
INITIAL_SSOT_ARTIFACTFreezes the initial official basis — the approved starting ground the project may treat as authoritative
Two optional artifacts are added only when the case genuinely requires them:
Optional ArtifactUse
HANDOFF_ARTIFACTTransfers current state when the next run cannot be safely reconstructed from stable artifacts
SOURCE_OR_MATERIAL_TRANSFER_ARTIFACTMoves candidate materials to the target project without promoting them to official basis yet
Do not generate every surface by default. A clean project opening is usually smaller than anxiety wants it to be.

Domain-Agnostic by Design

Project Forge does not know or care what your project is about. Whether you are tracking a sports season through foreign press coverage, synthesising a research source pack, defining a product strategy, planning a technical investigation, or opening a writing workspace — the system applies the same preparation logic. It cares only whether the project can open from explicit files instead of hidden chat continuity.

Four Ways to Use It

Manual

Fill the artifact templates yourself when the project is already clear or you want maximum control. Works well when objective, scope, approved sources, and expected outputs are already known.

Guided in ChatGPT

Use a clean Project Forge workspace as a preparation room. Provide the canonicals, describe the target, and let ChatGPT help compile the opening package before the real project is created.

With a File-Based Agent

Use an IDE assistant, Codex, or a CLI agent to read the canonicals and templates, receive your project information, and compile the artifacts. The operator retains authority over source selection and official basis.

With the Web Compiler

Use the guided browser compiler for a dedicated, structured surface for filling the opening artifacts. Keeps required and optional surfaces visible without replacing the canonicals.
The method changes. The boundary does not.

Build docs developers (and LLMs) love