A session is the operating unit of the GPT Project Skill System. Every skill you load, every capability you activate, and every semantic rule you bring into play exists only for the duration of the current chat. When the chat closes, the active skill set is gone — nothing persists into the next conversation. Understanding this boundary lets you design focused, purposeful sessions rather than accumulating stale context across unrelated tasks.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/XxYouDeaDPunKxX/ChatGPT-SKILL-SYSTEM/llms.txt
Use this file to discover all available pages before exploring further.
Booting the core
Before any skill can be loaded, the system core must be unpacked and activated. This happens through theSKILL CORE UNPACK command.
You do not have to type this yourself on the first turn. The CUSTOM_INSTRUCTIONS.txt file — added to your Project’s custom instructions during setup — tells ChatGPT to run core unpack automatically at the start of each new chat in the Project.
When SKILL CORE UNPACK runs it performs these steps in order:
Remove the previous core
Any existing
/mnt/data/GPT.SKILLS/ directory is deleted. Any legacy /mnt/data/sistema_madre/ directory is also removed. This guarantees a clean slate before extraction.Extract the core package
GPT.SKILLS.zip is extracted into /mnt/data/GPT.SKILLS/. The ZIP must produce exactly this root — a hard fail is raised if any other root path is produced.Validate the core manifest
/mnt/data/GPT.SKILLS/SYSTEM_CORE/MANIFEST.json is read and validated. Required fields, types, system_name, version, path safety, and the load_sequence are all checked mechanically.Mount the core load-sequence files
Each file declared in
load_sequence — ENTRY.md, README.md, SEMANTICS.md, and OPERATIONAL_RULES.md — is read and validated as a required UTF-8 text file. All four are required; a missing or unreadable file in load_sequence causes a hard fail.The core runtime files
The four files mounted during core boot form the active semantic perimeter of the system. Each has a distinct role.ENTRY.md
The bootstrap and activation entry point. Defines what activation means, what the session boundary is, and where command authority lives. It is the
primary_file in the core manifest.README.md
The system overview. Describes what the skill system is for, what it does, and what it does not do. Contains no operational rules or lifecycle commands.
SEMANTICS.md
The mental model. Defines session-first thinking, what “active” means, the cooperative composition principle, and the boundary of change. Does not define command lifecycle or manifest validation.
OPERATIONAL_RULES.md
The command lifecycle and validation rulebook. Defines
SKILL CORE UNPACK, SKILL <name> UNPACK, and SKILL <name> LOAD behavior in full, including hard-fail conditions, manifest validation rules, path policy, and runtime limits.Rerunning core unpack
You can issueSKILL CORE UNPACK again at any point during an active chat.
This behavior is intentional. Core unpack is a clean-slate operation by design. It removes the old /mnt/data/GPT.SKILLS/ tree entirely before extracting a fresh copy.
Starting a fresh session
When your work focus changes materially — you finish one task and move on to a different domain — the right move is to open a new Project chat and run a fresh targeted boot-and-load cycle rather than accumulating more skills in the same conversation. The reason is explained directly by theSEMANTICS.md file mounted during core boot:
The system should avoid loading skills “just in case” because excess active context degrades focus.A session built around a small, coherent set of skills produces sharper, more reliable results. Keeping old skills active from a previous task introduces semantic noise. A new chat gives you a clean context, a fresh core boot via
CUSTOM_INSTRUCTIONS.txt, and the opportunity to load only what the current task actually requires.