Uninit workos
Compound your context with Claude across sessions, in plain markdown.
npx -y skills add dylanmoo/workos-plugin --skill uninit-workosAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Reverse what /init-workos did, removing only the scaffold files it created and leaving every other document and folder untouched. Use whenever the user says 'uninit workos,' 'undo init-workos,' 'remove the workos scaffold,' 'tear down workos,' 'reset this back,' 'revert init-workos,' or asks to clean up the CLAUDE.md / MEMORY.md / ARCHIVE.md scaffolding without losing their existing content. Identifies scaffold files by a sentinel marker (`workos-init-scaffold v1`) that init-workos writes at the top of every file it creates. Files without the sentinel — including any document the user wrote — are never deleted or modified. When a scaffold file has been edited since init, shows the user what changed and asks before removing.
SKILL.md
7.2 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it
Uninit WorkOS
The reverse of /init-workos. Walks the workspace, removes only the scaffold files that /init-workos created, and leaves every other file and folder untouched.
What this skill does
Three things, and only three things:
- Finds every scaffold file by grepping for the sentinel
workos-init-scaffold v1that/init-workoswrites at the top of each file it creates. - Classifies each scaffold file as clean (unchanged from the original template) or edited (the user added content after init).
- Removes clean scaffold files automatically; asks the user file-by-file what to do with edited ones.
Anything without the sentinel — pre-existing documents, files the user wrote later, files created by /create-project — is never touched.
The sentinel
/init-workos writes this exact line at the top of every file it creates (after YAML frontmatter when present):
<!-- workos-init-scaffold v1 — created by /init-workos on YYYY-MM-DD. Remove via /uninit-workos. -->
This skill matches the substring workos-init-scaffold v1. Anything containing that token is a scaffold file. Anything not containing it is user content and stays.
If the user removed the sentinel manually, the file looks like user content to this skill — it will be left alone. That's intentional: when in doubt, preserve.
Step 1: Confirm the workspace root
Use the current working directory as the workspace root. State the path back to the user and confirm before scanning.
Step 2: Find all scaffold files
Recursively grep the workspace for files containing workos-init-scaffold v1. Limit to depth 3 (root → domain → project, or root → domain → group → project) to match what /init-workos could have created. Filenames to inspect:
CLAUDE.mdMEMORY.mdARCHIVE.md
Skip the same exclusion lists as init-workos: .git, .github, .obsidian, .claude, .vscode, .idea, node_modules, dist, build, target, __pycache__, .venv, venv, plugins, skills.
If zero scaffold files are found, stop and tell the user: "No /init-workos scaffold detected here. Nothing to undo."
Step 3: Classify each scaffold file
For each file with the sentinel, classify it:
- Clean — the file matches the original init-workos template exactly (modulo the date in the sentinel). Safe to delete with no questions.
- Edited — the file contains content beyond what init-workos wrote. The user added something after init.
A rough heuristic for "clean":
- Body length within 10% of the canonical template length for that file type
- No headings or bullet items outside the canonical template
- Placeholder lines (
*(nothing active yet)*,*(none yet)*,*(empty)*) still present
If you can't confidently classify, default to Edited (safer — forces a user decision rather than silent deletion).
Step 4: Show the user the plan
Present the findings as a single block:
Found 9 scaffold files from /init-workos:
Clean — safe to remove (5):
./CLAUDE.md
./ARCHIVE.md
./personal/CLAUDE.md
./personal/MEMORY.md
./clients/CLAUDE.md
Edited — needs your decision (4):
./MEMORY.md (added: "Active Projects" entries, 12 lines)
./clients/MEMORY.md (added: 2 entries under Key Decisions)
./clients/acme-corp/CLAUDE.md (added: Workflow steps)
./clients/acme-corp/MEMORY.md (added: Contacts section content)
Proceed? Three options:
(a) Remove all clean files; ask file-by-file about edited ones
(b) Remove only the clean files; leave edited ones alone
(c) Cancel
Step 5: Handle clean files
For each file in the clean list, delete it. Report the count when done.
No folder cleanup — /init-workos doesn't create folders (only files), so there's nothing to remove on the folder side. If the user wants to delete now-empty folders, that's a separate explicit ask.
Step 6: Handle edited files (one at a time)
For each edited file, show:
- The file path
- A brief diff: which sections / lines are additions beyond the template
Then ask: "What do you want to do with this file?"
- Delete it — remove the whole file, including the user's additions. (Confirm once more before doing this.)
- Keep it, strip the scaffold — remove the sentinel line and any unmodified template sections, preserving the user's additions. Useful when the user wants to keep what they wrote but stop using WorkOS.
- Leave it alone — no changes. The file stays exactly as-is, sentinel and all.
When stripping, be conservative: only remove sections that are unchanged from the template. If a section has been edited even slightly, keep it.
Step 7: Confirm and report
Show the user a summary:
Removed:
./CLAUDE.md
./ARCHIVE.md
./personal/CLAUDE.md
./personal/MEMORY.md
./clients/CLAUDE.md
./clients/acme-corp/MEMORY.md (kept user content; stripped scaffold sections)
Left alone:
./MEMORY.md (user chose: leave alone)
./clients/MEMORY.md (user chose: leave alone)
./clients/acme-corp/CLAUDE.md (user chose: leave alone)
No other files or folders were touched.
End with one line: "Workspace is back to its pre-init state for the files you removed. You can re-run /init-workos any time."
Optional: backup before removing
If the user wants a safety net, offer once at the start: "Want me to copy the scaffold files into .workos-uninit-backup/ before removing them, in case you change your mind?"
If yes, mirror the directory structure inside .workos-uninit-backup/<timestamp>/ and copy each file before deletion. If no, proceed without backup.
What this skill does NOT do
- Doesn't delete files without the sentinel. Anything the user wrote, anything
/create-projectcreated, anything pre-existing — all left alone. - Doesn't delete folders.
/init-workosdoesn't create folders, so there's nothing to remove on the folder side. Empty subfolders the user wants to clean up are a separate manual step. - Doesn't touch
raw/orresources/contents./init-workosnever wrote there. - Doesn't uninstall the WorkOS plugin or any other skills. Those are managed at the Claude Desktop level, not by this skill.
- Doesn't ask the user to identify scaffold files manually. The sentinel is authoritative; if a file doesn't have it, it's not a scaffold file.
- Doesn't reverse anything besides
/init-workos. It's not a general workspace teardown — it's specifically the inverse of init.
Gives 0 of the 12 instructions most project setup skills give in ~1.6k tokens
Counted across 999 of the 1,637 authors here whose files we hold, read 2026-08-06
- ask one question at a timein 29 of 999, across 28 files
- detect the package manager from lockfilesin 28 of 999, across 9 files
- present findings to the userin 25 of 999, across 4 files
- explore current repo statein 24 of 999, across 3 files
- update the agent skills block in place if it existsin 24 of 999, across 3 files
- install husky lint-staged and prettierin 23 of 999, across 4 files
- create the lintstagedrc filein 22 of 999, across 3 files
- commit all changed filesin 22 of 999, across 3 files
- run lint-staged to verify it worksin 22 of 999, across 3 files
- initialize huskyin 21 of 999, across 2 files
- create the husky pre-commit filein 21 of 999, across 2 files
- create a prettierrc file if missingin 21 of 999, across 2 files
Said here and by no other author read
- find scaffold files containing the sentinel
- classify each scaffold file as clean or edited
- delete clean scaffold files
- show the user a summary plan before acting
- ask the user before handling each edited file
- confirm the workspace root before scanning
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.