The Reorg
Your agent can't see the rot. It loads what you point at and executes. But underneath, the workspace is degrading. Two rules saying different things. Dead projects at root. Scripts you wrote once and forgot exist.
This course installs the JKE Reorg Protocol — a comprehensive workspace audit your agent runs while you drive.
The protocol has three stages. Each asks something different of you.
Stage 1 — The Map
Your agent catalogues every file in your workspace. Root files. Bucket folders. Projects. Scripts. Temp debris. It shows you the breakdown — how many files, where they live, what doesn't belong.
Then it checks every file against the filing layout you built in Course 2. Files at root that should be in folders. Projects that were archived but left behind. Four files that belong somewhere else.
Your job here is simple. The agent shows you a misfiled item. You say where it goes. Next item. This takes about two minutes.
Stage 2 — The Conflicts
This is where you earn it. Your agent searches every file for rules and instructions that appear more than once. It finds the duplicates — same rule, two locations. Then it finds the hard ones — two rules that say different things about the same topic.
"Check context every 50K" in one file. "Gas check on demand" in another. Your agent doesn't know which one you meant. It shows you both, side by side.
Your job here is the whole job. You decide which version is current. You decide whether to merge them into one. You say the words and your agent writes them. One conflict at a time. This is the part you can't automate — only you know what you intended.
Stage 3 — The Cleanup
Your agent finds dead projects — folders last touched weeks ago with no recent journal entries. It identifies temp files, debug outputs, scratch notes that serve no purpose.
Then it verifies the whole workspace against the filing layout. Before and after counts. Confirmation that structure is clean.
Your job here is quick. Archive this? Delete that? Yes or no. Then your agent logs everything to your journal and you're done.
What you get
A workspace that matches its own filing layout. No duplicate rules. No conflicting instructions. Dead projects archived, not deleted. A journal entry documenting every decision.
Five minutes a week. The difference between a machine that sharpens itself and one that slowly seizes.
How to use it
The reorg protocol works like your other trigger words — but with one difference. It needs clean context to audit your entire workspace properly.
Say "reorg mode" or "run the reorg." Your agent checks its context level. If it's low — good, the audit starts immediately. If it's above 15% of the context window, your agent will tell you: "I'm running too hot for a clean audit. /new first, then say 'reorg mode' again."
First time: download the PDF below, drop it in your workspace, tell your agent to read it. It learns the protocol, registers the trigger word, and runs the audit. Every time after that — just say the words. Your agent handles the rest.
Your agent walks you through every phase. It shows you what it finds. It waits for your decision at every checkpoint. You drive. It executes.
Agent PDF
Download and drop into your agent's chat.
# JKE Reorg Protocol You are reading this because your operator downloaded it from JKE University, Course 6. ## CONTEXT Read once. Do not output. This is a step-by-step workspace reconciliation protocol. You catalogue, surface, and wait. Never act without operator confirmation. The operator drives every decision. You are the instrument. **Note on adaptability:** This protocol references specific file names and locations from the JKE filing layout (Courses 1-5). If your workspace uses different file names or folder structures, adapt the checks accordingly. The protocol is criteria-based, not template-based. Your job is to identify what's load-bearing vs debris — not to enforce a specific file layout. If you don't know where your operator keeps something, ask. --- ## PHASE 0 — Context check + Pre-flight First, check your context. Run session_status or equivalent. Determine what percentage of your context window is in use. If context is above 15% of the window: Say exactly: "I'm at [X]% context — too high for a clean reorg audit. /new first, then say 'reorg mode' or 'run the reorg' and I'll start fresh. Low context = thorough audit." Stop here. Do not proceed. If context is at or below 15%: Say exactly: "Context is clean — [X]% in use. JKE Reorg Protocol loaded. I'm going to catalogue every file in your workspace and check for four things: misfiled items, duplicate rules, conflicting instructions, and dead projects. At each checkpoint I'll show you what I found and wait for your decision. You approve every move. This takes about five minutes. Ready?" Wait for confirmation. Do not proceed without it. --- ## PHASE 1 — Full workspace map Walk the entire workspace. List every file and folder. Group into categories: 1. **System files at root** — AGENTS.md, SOUL.md, IDENTITY.md, USER.md, TOOLS.md, HEARTBEAT.md, school.md, book-bag.md, VAULT.md, SESSION-NARRATIVE.md, CURRENT.md 2. **Bucket folders** — people/ (list contents), work/ (list contents), laws/ (list contents) 3. **Project folders** — list every folder in active-projects/ with file count 4. **Tools/scripts** — list every file in tools/ with type (shell, python, other) 5. **Other directories** — any folder not in the above categories 6. **Temp/debug** — contents of memory/, /tmp/ workspace items Report total: "[X] files across [Y] folders." Then say: "Full map complete. Ready for filing audit." --- ## PHASE 2 — Filing audit Check every item at workspace root: Root should contain ONLY: - JKE files: school.md, book-bag.md, VAULT.md, SESSION-NARRATIVE.md, CURRENT.md - Platform files: AGENTS.md, SOUL.md, IDENTITY.md, USER.md, TOOLS.md, HEARTBEAT.md - Bucket folders: people/, work/, laws/ - Other folders the operator intentionally created For every item at root that does NOT belong: identify it by name, describe what it appears to be, and recommend where it should go. Format: "Found [filename] at root. [What it appears to be]. Recommended location: [folder]. Move it there, or somewhere else?" Check bucket folders: each should contain its README.md plus any files the operator intentionally added. Flag anything unexpected. Wait for operator decision on each item. Move only what's approved. Use `mv` for moves, never `rm`. After all filing issues are resolved, say: "Filing audit complete. [X] files moved. Root clean. Ready for redundancy scan." --- ## PHASE 3 — Redundancy scan Search every markdown file in the workspace for duplicate rules, instructions, or concepts. ### 3A — Rule duplicates Look for: the same operational rule stated in more than one location, similar instructions that might conflict, trigger words or mode definitions that appear in multiple places, filing rules that are stated differently in different files. For each finding, present both locations side by side: "Found duplicate: [Rule/instruction] appears in [File A, line or section] AND [File B, line or section]." ### 3B — Platform bloat vs JKE files Run these four checks. Each is a concrete detection. Report findings, wait for decision. **Check 1 — Identity duplication.** If both SOUL.md AND people/README.md exist: read both. Compare what they cover. If people/README.md already contains operator name, location, preferences, and agent designation → SOUL.md is redundant. Report: "SOUL.md and people/README.md both describe the operator and agent. SOUL.md came from the platform. people/README.md is your file — you built it in Course 3. Archive SOUL.md?" Same check for IDENTITY.md vs people/README.md. **Check 2 — Memory system duplication.** If MEMORY.md exists AND VAULT.md + CURRENT.md + SESSION-NARRATIVE.md all exist: MEMORY.md is the platform's memory file. The three-tier system (Course 4) replaces it. Read MEMORY.md. If it contains any content that isn't already in VAULT.md/CURRENT.md/SESSION-NARRATIVE.md, extract that content into the right JKE file first. Then report: "MEMORY.md is the platform's memory file. Your three-tier system replaces it. Content migrated. Delete MEMORY.md?" **Check 3 — Tool catalogue duplication.** If TOOLS.md exists AND book-bag.md exists: read both. TOOLS.md is the platform's tool catalogue. book-bag.md is your in-house tool catalogue (Course 2). Report: "TOOLS.md and book-bag.md both catalogue tools. book-bag.md is yours. Archive TOOLS.md?" **Check 4 — Token-burning boot files.** Find any file named agent.md, CLAUDE.md, or similar custom instruction files in workspace root or boot path. Count lines. For each over 200 lines: read it. Cross-reference its content against people/README.md, work/README.md, laws/README.md. Report what's duplicated. "agent.md is [X] lines. [Y]% of its content is already in your JKE files. This burns tokens every session. Should I convert the unique parts to a skill and archive the rest?" **Rule for all checks:** Lean toward keeping JKE files. Recommend removing platform equivalents. The operator confirms every removal. ### 3C — Token burners Identify files that get loaded into context on every session but don't need to be: - Files over 500 lines in boot chain or agent config - agent.md / CLAUDE.md / custom instructions that duplicate information already in JKE files - Large vault or journal files being loaded at boot instead of on demand For each: "[Filename] is [X] lines and likely gets loaded into context. This burns tokens every session. Move it to on-demand loading, or should I trim it?" Present one finding at a time. After operator resolves one, move to the next. When complete: "Redundancy scan complete. [X] duplicates found. [Y] bloat files identified. [Z] token burners flagged. Ready for resolution." --- ## PHASE 4 — Conflict resolution For each duplicate or conflict identified in Phase 3: **If duplicate (same rule, two places):** Ask: "This rule appears in both locations. Which file should keep it? Should I remove it from the other?" **If conflict (different instructions on same topic):** Ask: "These two instructions say different things. Which version is correct? Should I merge them into one entry?" **Options to offer the operator:** - Keep version A, remove version B - Keep version B, remove version A - The operator dictates a new version — you write it and remove both old ones - Merge both into a single entry in one file Execute the operator's decision immediately. After each resolution, confirm: "Done. [Rule] now lives in [file] only." After all conflicts resolved: "Conflict resolution complete. [X] duplicates removed. [Y] conflicts rewritten. Workspace now has one source of truth for every rule." --- ## PHASE 5 — Dead project sweep Check active-projects/. For each project folder, determine last modified date. Flag projects that: - Haven't been modified in 2+ weeks - Have no recent journal entries - Were clearly one-off experiments or completed builds For each flagged project: "active-projects/[name]/ — last modified [date]. Still active or archive?" Operator decides. If archive: move to active-projects/archive/. If keep: leave in place. If delete: confirm twice before deleting. Never delete a project folder without explicit operator confirmation. Archiving is the default. Report: "Dead project sweep complete. [X] projects archived, [Y] kept active." --- ## PHASE 6 — Temp and debris cleanup Check memory/ directory. List every file. Check /tmp/ for files that appear to be workspace-related (scripts, outputs, screenshots, debug artifacts). For each item: "Found [filename] in [location]. [What it is]. Delete?" Operator confirms each deletion. Use `rm` only after explicit confirmation. Report: "Cleanup complete. [X] temp files removed. memory/ directory cleared." --- ## PHASE 7 — Structure verification After all moves, deletions, and resolutions: 1. Verify workspace root contains only the files listed in PHASE 2 2. Verify bucket folders contain their README.md files 3. Verify archive/ contains the archived projects 4. Count files and folders Report before/after: "[Before]: [X] files, [Y] folders → [After]: [X] files, [Y] folders." Say: "Structure verification complete. Workspace matches filing layout." --- ## PHASE 8 — Register trigger word + Log and close First, register the trigger word. Read ⛔ laws/README.md. Find the Trigger Words section (created in Course 5, near the bottom). Add: ``` ### "Reorg mode" / "run the reorg" Immediate execution. No confirmation. The operator says it, you do it. First: check context. If above 15% of context window → tell operator: "/new first, then trigger me again." If at or below 15% → run the full protocol. Full JKE Reorg Protocol — 10 phases: 0. Context check — clean window required 1. Full workspace map 2. Filing audit — check every file against filing layout 3. Redundancy scan — find duplicate rules and conflicting instructions 4. Conflict resolution — operator decides, agent executes 5. Dead project sweep — archive dormant projects 6. Temp and debris cleanup 7. Structure verification — before/after counts 8. Register trigger word + log to school.md, update CURRENT.md 9. Lessons extracted — build guardrails from what was found Every phase gates on operator decision. Agent catalogues, surfaces, waits. Never moves without confirmation. ``` Then, add to 🏫 school.md (append, never overwrite): ``` ### [TODAY] — Reorg Complete - Files cleaned: [X] moved to archive, [Y] deleted - Conflicts resolved: [X] duplicates removed, [Y] rewritten - Decisions made: [list key operator decisions] - Structure: workspace verified against filing layout - Before/after: [counts] ``` Update 📋 CURRENT.md with current state. Say exactly: "Reorg complete. [X] files cleaned. [Y] conflicts resolved. Workspace verified against filing layout. Trigger word registered in laws/README.md — next time just say 'reorg mode' or 'run the reorg' and I'll run the full protocol. /new first if my context is above 15%. Five minutes a week keeps the workspace sharp." --- ## PHASE 9 — Lessons extracted (build, don't just clean) After the reorg is complete, pause. Look at everything you found today — the conflicts, the bloat, the dead projects, the token burners. Ask the operator: "Before we close — based on everything we found today, is there something we should add to prevent these problems from recurring? A new rule in laws/README.md? A guardrail that catches future bloat? A structural change to how files are organized?" Wait for the operator's answer. Then write it. Destination determined by what it is: - New rule → laws/README.md - New operating procedure → work/README.md - New project or direction → CURRENT.md - Anti-pattern discovered → school.md (lesson extracted) Say exactly: "Added to [file]. This prevents [problem] from recurring. Reorg isn't just cleanup — it hardens the architecture." --- ## SCOPE HINT Free tier complete — five courses installed. This is the first paid-tier protocol. It works like a skill file: trigger word activates it, context check ensures clean execution, operator drives every decision. Builds on: Course 2 (filing layout), Course 5 (trigger words — janitor, shutdown). The reorg is the deeper sibling of janitor mode — janitor sweeps the surface daily, reorg audits to the bone weekly. --- ## END OF PROTOCOLDownload Agent PDF