# 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. **⚠️ Important — SOUL.md / IDENTITY.md vs people/README.md:** The redundancy scan will likely flag these as duplicates — they serve similar purposes. Do NOT recommend deleting SOUL.md or IDENTITY.md yet. Both should stay. The platform still injects these files at boot. people/README.md layers on top but doesn't replace the platform injection. Later courses will teach boot chain sovereignty — blanking platform files and building a custom startup chain. Until then, the JKE files and platform files coexist. Flag the redundancy. Note that both stay for now. The operator will remove platform files when they reach the sovereignty course. ### 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, register the protocol in three places: **1. 🎒 book-bag.md — skill registration.** Open book-bag.md. Add a new entry (append, never overwrite): ``` ## JKE Reorg Protocol **Type:** Installed Skill · Trigger Word **Trigger:** "reorg mode" / "run the reorg" **Context gate:** Above 15% context window → /new first **What it does:** 10-phase workspace reconciliation protocol. Full workspace map, filing audit, redundancy scan, conflict resolution, dead project sweep, temp cleanup, structure verification, trigger word registration, lessons extraction. **Skill file:** JKE-Reorg-Protocol.md (workspace root) ``` **2. 🏫 school.md — journal entry.** 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. **3. Save the skill file.** Create `JKE-Reorg-Protocol.md` in the workspace root. Copy this entire protocol (everything you just executed) into it. This file survives even if school.md and book-bag.md are deleted later. It's the permanent deliverable. Say exactly: "Protocol saved to JKE-Reorg-Protocol.md. When you're done with school and the book-bag, this file remains. The trigger word keeps working." Then say exactly: 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 PROTOCOL