AI workspace · living guide

Your tools are separate.
Your context is organized.

A calm map of Codex, ChatGPT, Claude, Kip, skills, memory, Obsidian, Git, cloud work—and The Fight Within You.

Last updated July 23, 2026Public field guide
01
The architecture is now stable

KIP is the source. Handoffs are the bridge. This site is the front door.

Project folders keep the work. GitHub moves committed KIP files between computers. Each AI gets the same compact briefing packet without pretending the tools share one live brain.

The mental model

One durable library, several specialized workers

Durable source

KIP Vault

Summaries, decisions, links, open loops, and compiled knowledge.

01

Codex

Files, implementation, project instructions, skills, local and cloud work.

02

ChatGPT

Browser chats, Projects, uploaded references, and visual exploration.

03

Claude

Separate chats, CLAUDE.md, project work, and machine-local memory.

04

Kip — AI Agent

OpenClaw agent on the PC, using KIP as its durable workspace.

05

This site

A pleasant, searchable reader—never the only copy.

Questions answered

Come back here when the vocabulary gets slippery.

30 answers
01The mapDo ChatGPT, Codex, Claude, and Kip share one brain?No. They are separate rooms that can read the same briefing packet.

Their live chats and automatic memories are separate. Browser ChatGPT, Codex on each computer, Claude, and Kip do not automatically hear every conversation happening elsewhere.

The durable bridge is a compact packet: project instructions, a current handoff, KIP summaries, and the exact source files needed for the task.

The useful mental model: several smart rooms, one reliable briefing packet.
02The mapWhat does a brand-new Codex task know?It starts fresh, then loads applicable instructions, skills, memory, and selected files.

A new task knows its selected folder and loads the relevant instruction hierarchy, available skills, and machine-local memory. It can inspect project files as needed.

It does not inherit the entire previous task and does not automatically read every file in a large project. That is why a short project front door and a current handoff matter.

03The mapShould this system live in Obsidian or on a site?Both: KIP is the editable source; this site is the calm reading view.

KIP holds the Markdown you own: durable summaries, decisions, links, open loops, and compiled knowledge. The site turns selected material into a friendly, searchable guide.

A hosted URL can change. Long-term durability comes from keeping the source files and publishing new versions from them.

04The mapWhere should new coding projects live?Use ~/Projects for new work; leave Fight on the Desktop until a planned migration.

A stable folder such as ~/Projects keeps new code easy to find and keeps the Desktop from becoming the project manager.

Fight is the exception for now. Many project references point to its current Desktop location, so moving it should be a deliberate migration with path verification.

05Skills & instructionsWhat is the difference between global and project AGENTS.md?Global rules follow you everywhere; project rules stay with one project.

The global Codex file at ~/.codex/AGENTS.md now contains only universal preferences: communication, safety, checkpoints, organization, and durable-context routing.

A project AGENTS.md is a literal Markdown file inside the project. Fight animation rules belong in Fight. HelioFlux and Poshmark can have different instructions.

06Skills & instructionsWhy does KIP have AGENTS.md and AGENTS.override.md?KIP serves two systems, so each one now has a clearly owned instruction layer.

KIP's root AGENTS.md belongs to Kip/OpenClaw. Codex uses AGENTS.override.md in the KIP repository, and Claude uses CLAUDE.md.

Detailed OpenClaw procedures live in an instructions/openclaw area so Codex and Claude do not mistake agent-runtime instructions for their own.

07Skills & instructionsWhat is the Claude equivalent of AGENTS.md?Claude Code uses CLAUDE.md and can import shared project instructions.

Claude Code reads ~/.claude/CLAUDE.md for user-level guidance and a project CLAUDE.md or .claude/CLAUDE.md for project guidance.

Claude's automatic project memory is machine-local. It is not the canonical KIP memory and does not automatically synchronize with Codex.

08Skills & instructionsWhere do skills live, and why are the folders hidden?They are ordinary configuration folders; the leading dot hides them in Finder.

User skills mainly live under ~/.codex/skills and ~/.agents/skills. A project can also have .agents/skills. Plugin-supplied skills live in managed plugin cache folders.

In Finder, Command + Shift + . shows or hides dot-folders. Codex's Skills sidebar and the new SKILLS_INDEX.md are the friendlier ways to browse them.

09Skills & instructionsDo installed skills inflate AGENTS.md?No. A skill stays separate and is read when the task calls for it.

A skill is a folder with a SKILL.md entry point and sometimes scripts, references, assets, or templates. Installing it does not paste the whole skill into AGENTS.md.

Keep always-relevant behavior in AGENTS.md, reusable procedures in skills, and changing project facts in project files.

10Skills & instructionsWhat is a plugin compared with a skill?A skill is a procedure; a plugin can bundle skills, tools, apps, and connectors.

Plugin cache folders are managed, versioned installation data. Seeing more than one cached version does not prove you have duplicate active skills.

Do not manually clean plugin caches merely because their names look repetitive. The skills index separates managed plugin capabilities from your custom skills.

11Skills & instructionsWhich skills are actually duplicated?The CKM family and a project Playwright copy are consolidation candidates; design symlinks are intentional.

The eleven shared design skills are not duplicate files: they live once under ~/.agents/skills and are intentionally linked into Codex.

The six CKM families have byte-identical support files; only their SKILL.md names and argument hints differ. The .agents versions are the likely canonical source, but they should be tested before removing the Codex compatibility copies.

The global Playwright CLI skill is a superset of the New project copy because it includes the working Codex command wrapper.

Nothing was deleted. The cleanup plan requires a fresh-task test and an approved exact target list.
12Memory & chatsCan checkpoints happen automatically?The tools can offer them at milestones; an explicit request is still the reliable trigger.

The global Codex and Claude files now ask the assistant to offer a checkpoint after a major decision or milestone. That is a helpful behavior rule, not a perfect timer.

Say “Checkpoint this,” “Create a handoff,” or “Save this conversation to KIP” whenever you definitely want one.

13Memory & chatsAre memory/chat-handoffs Git branches or separate chats?Neither. They are readable Markdown summaries—one checkpoint per file.

The folder memory/chat-handoffs lives inside KIP. Each valuable checkpoint or final session becomes one structured Markdown file.

The original private chat URL returns you to the source conversation, while the handoff gives a future tool the minimum context needed to continue.

14Memory & chatsWhat should every durable chat summary contain?Source, decisions, outputs, direction, current state, next actions, and an honesty note.
  • Original private chat URL, platform, date, project, and mode
  • Completeness warning for very long or older conversations
  • Decisions and important reasoning
  • Files, images, prompts, and deliverables
  • Approved and rejected directions
  • Current state, open loops, and next actions
  • What the next chat must know and a paste-ready opening prompt
15Memory & chatsWhat should KIP store?Durable understanding—not every raw chat, temporary file, image, or video.

KIP should keep compact handoffs, project summaries, durable decisions, relationships, reusable concepts, open loops, and source-backed compiled knowledge.

Large production libraries, full transcripts, credentials, and temporary build artifacts stay out. Fight's actual assets remain in the Fight project.

16Obsidian & GitDoes Obsidian need to stay open?No. It is an editor and viewer for the same Markdown files.

Codex and Git can read or update the KIP files while Obsidian is closed. When Obsidian opens again, it reads the updated vault.

Obsidian being open does not cause GitHub synchronization by itself.

17Obsidian & GitDoes GitHub Desktop need to stay open?No. It is a visual interface for Git, not the sync engine itself.

Codex can run the same Git operations directly. GitHub Desktop remains useful when you want to inspect history or click through changes yourself.

18Obsidian & GitWhat do commit, push, pull, and pull request mean?Commit saves locally; push sends up; pull brings down; a pull request asks for review.
CommitCreate a named snapshot on this computer.
PushUpload local commits to GitHub.
PullBring newer GitHub commits into this computer.
Pull requestPropose and review merging one branch into another; useful for teams, optional for ordinary personal sync.
19Obsidian & GitDoes GitHub mean everything is automatically online?Only committed and pushed files reach GitHub.

Uncommitted changes and local-only commits remain on that computer. KIP's GitHub repository is private, so authorized users can reach it online but it is not a public website.

GitHub is durable repository history, not a magical live mirror of every folder.

20Obsidian & GitWhat is the safe routine between two computers?Inspect before pulling; commit and explicitly push after work.
  • Before work, fetch and inspect whether the local copy is clean, ahead, behind, or diverged.
  • Pull only when the update is a clean fast-forward.
  • If both machines changed the repository, reconcile instead of blindly pulling.
  • After work, review and commit a meaningful checkpoint.
  • Push only when explicitly authorized, then safely pull on the other computer before editing.
21Computers & cloudWhat should I ask Codex on the other computer?Ask for a read-only Git safety check first, then allow only a clean fast-forward pull.
  • Locate the PC's actual KIP repository and report its path.
  • Fetch the remote state and report clean, dirty, ahead, behind, or diverged.
  • Do not merge, rebase, stash, reset, discard, switch branches, or push.
  • Pull only when master is clean, has no local-only commits, and GitHub is only ahead.
  • After the pull, verify the AI System, skills index, handoff index, and other-computer update guide.
The full paste-ready prompt lives in KIP's OTHER-COMPUTER-UPDATE-GUIDE.md.
22Obsidian & GitShould KIP use Obsidian Sync or GitHub?Keep GitHub as the single KIP sync system for now.

GitHub already holds the private repository and explicit version history. Obsidian Sync can be reconsidered later if a simpler mobile workflow becomes important.

Do not activate two independent sync engines on the same vault without a tested migration plan.

23Computers & cloudWhat are Local, Worktree, and Cloud in Codex?Local and Worktree run on your computer; Cloud runs in an isolated hosted container.
LocalWork directly in the selected folder on this computer.
WorktreeUse an isolated Git checkout on this computer so tasks do not collide.
CloudCheck out a connected Git repository in an OpenAI-managed container.
Cloud sees the repository branch or commit it checks out—not random uncommitted Desktop files.
24Computers & cloudWhat happens when I use Codex from my phone?You may be controlling a paired computer, or starting a separate cloud task.

With Remote Control, the phone sends prompts to a paired Mac, PC, or remote host. Files, commands, skills, signed-in apps, and tools come from that connected host, which must remain reachable.

With Codex cloud, the task runs remotely against a connected Git repository. These are different workflows.

26Computers & cloudIs KIP really Kip's brain?Yes: KIP is the durable workspace; Kip's live runtime remains separate on the PC.

The KIP repository contains Kip's durable workspace, operating documents, memory, and Obsidian vault.

Kip's live OpenClaw sessions and machine configuration remain on the host computer. Durable context is promoted into KIP deliberately instead of assuming every runtime detail belongs in the vault.

27FightWhat is the Fight cross-tool bridge?One compact front page that Codex, ChatGPT, and Claude can all read.

Fight now has a visible project AGENTS.md, a Claude bridge, a CROSS-TOOL-HANDOFF.md, corrected skill references, and a linked KIP project summary.

The Fight folder remains authoritative for images, prompts, videos, scripts, references, and production state. The tools share the compact packet, not one live brain.

28FightWhich Fight skill is current?cellular-characters is the live master visual and science skill.

It covers the approved matte cel-animation style, character and tissue scenes, healthy cell-cycle sequences, molecular mechanisms, logo style transfer, multi-image video prompting, and scientific QA.

The project handoff files now point to this current skill instead of the missing older skill name.

29FightShould the Fight folder be moved off the Desktop?Not casually. Keep it stable until a complete path-aware migration is approved.

The folder is heavily used and many handoffs, prompts, and tool instructions contain absolute paths to its current location.

A future migration is possible, but it should begin with an inventory of path references, a proposed destination, a backup, and a verification plan.

30The mapHow should credentials be handled in an AI workspace?Keep secrets out of repositories, prompts, handoffs, and published guides.

API keys, tokens, passwords, and other secrets belong in protected runtime settings or a dedicated secrets manager. Store only safe placeholders and setup instructions in Git.

If a secret is ever committed, rotate it. Removing it from the latest file is not enough because older Git history may still contain the value.

Rotate first. History cleanup is a separate, carefully planned task.
Your checkpoint command

Use this before the good context disappears.

Ask after a major decision, a finished creative direction, or any time you hear yourself say, “I don't want to lose this.”

Create a durable checkpoint for my Obsidian memory system.

Original private chat URL: [PASTE URL, OR SAY NOT AVAILABLE]
Platform: [ChatGPT / Codex / Claude / Kip]
Project: [PROJECT NAME]
Checkpoint focus: [MAJOR DECISION OR MILESTONE]

Include: summary; decisions and reasoning; files and deliverables; approved and rejected directions; current state; open loops; next actions; what a future chat must know; and suggested tags.

State clearly if any earlier portion may no longer be available in your active context. Do not pretend the extraction is complete if it is not.
Good-idea ledger

Enthusiasm turned into a system.

“Good idea” now becomes a durable decision with a visible status.

Done01

Small global instructions

Universal Codex and Claude guidance without project-specific clutter.

Done02

Visible skills index

Purpose, location, scope, plugin source, and duplicate-review status.

Done03

One Fight cross-tool packet

Current state, canonical style, rejected directions, outputs, and open loops.

Done04

Checkpoint and handoff system

Mid-session, final, cross-tool, and retrospective capture modes.

Done05

KIP source + Sites reader

Durable Markdown underneath; a calm searchable public presentation on top.

Now06

Credential hygiene

Keep secrets in protected runtime settings and out of repositories, prompts, handoffs, and published pages.

Later07

Fresh-task testing

Open a brand-new Fight task and verify that the new front door works.

Done08

kellylucas.dev integration

Share the reviewed guide publicly and give it a clear front door from the main site.

What happens next

A reliable order for any project.

  1. 01

    Choose the source of truth

    Decide which project folder or vault owns the durable work.

  2. 02

    Add a small instruction layer

    Keep universal rules global and put project-specific guidance beside the work.

  3. 03

    Create the handoff

    Capture current state, decisions, approved direction, open loops, and the next action.

  4. 04

    Sync deliberately

    Inspect first, commit meaningful checkpoints, then push and pull with intention.

  5. 05

    Publish selectively

    Share the useful public layer while keeping private memory, raw assets, and credentials protected.