/reset

description: Removes selected init and permissions setup from the project, or only the permissions setup with the permissions argument. Reviews ownership, current content, and Git recoverability; preserves ambiguous user content and backs up selected changes when needed. Requires a concrete deletion selection. Tests are never touched. Monorepo and multi-repo aware.
disable-model-invocation: true
argument-hint: "[permissions]"

Reset — Remove optimus-generated files

Remove selected project artifacts, not the plugin installation itself.

Scope

Parse `$ARGUMENTS` before inventorying: empty → the existing full inventory; `permissions` → only the permissions setup. Any other argument → show usage `/optimus:reset [permissions]` and stop without changes. Keep every later selection, edit, and cleanup within the chosen scope.

The `permissions` scope removes Claude Code configuration from either host; it does not configure Codex permissions. It removes additions, without restoring previously replaced hook contents or git deny rules removed during setup: the ownership record contains no such history.

Safety Rules

• Never touch tests, test directories, or test configuration, even if Optimus created them.
• Stay within `.claude/`, subproject `CLAUDE.md`/`docs/`, workspace-root `CLAUDE.md`, and marked `optimus:pointer` blocks in root `AGENTS.md`. Resolve every target inside the intended root; do not follow symlinks outside it.
• `.claude/settings.json` is merged surgically. Filename, matching permission values, Git tracking, and template-like headings do not prove ownership or current-byte recoverability.
• Preserve `.claude/.optimus-reset-backups/` from this and earlier runs; never include it in the removal inventory.

Step 1 — Detect and inventory

If `git rev-parse --is-inside-work-tree` returns `true`, resolve `git rev-parse --show-toplevel` (including linked worktrees). Otherwise apply `$CLAUDE_PLUGIN_ROOT/skills/init/references/multi-repo-detection.md`. Process each child repo independently; include workspace-root context files only when applicable.

Read `$CLAUDE_PLUGIN_ROOT/skills/init/references/managed-files.md` and any `.claude/.optimus-managed.json`.

**`permissions` scope:** inventory only `.claude/hooks/restrict-paths.sh`, its `hooks.PreToolUse` registrations, and recorded `permissions.allow` / `permissions.deny` additions (including recorded MCP allowances). Include their ownership entries even when the hook or settings additions are already missing. Shared settings and ownership files are entry-edit targets, not whole-file candidates. Preserve unrelated hook commands in shared matcher groups. Unrecorded permission rules stay unless the user identifies the exact entries for review; template equality or current MCP names never establish ownership. Do not inventory init's docs, formatters, pointers, or `.optimus-version`.

**Full scope only:** inventory existing candidates:

• `.claude/CLAUDE.md`, `.claude/.optimus-version`, `.claude/settings.json`, and the ownership record.
• `.claude/docs/{coding-guidelines,testing,styling,architecture,skill-writing-guidelines}.md`.
• `.claude/hooks/format-*`, including retired `format-python.py` and `format-node.js`, and `.claude/hooks/restrict-paths.sh`.
• Legacy `.claude/agents/{code-simplifier,test-guardian}.md`.
• Root `AGENTS.md` only when it contains a well-formed `optimus:pointer` block.
• Monorepo: applicable subproject `CLAUDE.md` and `docs/{coding-guidelines,testing,styling,architecture}.md`.
• Multi-repo: the above per child repo, plus workspace-root `CLAUDE.md` and pointer block.

No in-scope candidates, including stale ownership entries → report nothing to reset and stop, even if init artifacts or unrelated settings remain. Missing provenance means an older or unrelated installation, not permission to delete every candidate.

Step 2 — Classify content and recoverability

Show two independent dimensions for each candidate:

| Content / ownership | Meaning | |---|---| | `UNMODIFIED` | CRLF-normalized current SHA-256 matches a valid recorded file entry's `sha256`. Show whether that baseline is a template or an approved customization (`refresh: "review"`). | | `MODIFIED` | Recorded file differs from its entry's `sha256`. Read it before proposing removal. | | `UNKNOWN` | No usable record; may be legacy Optimus content or independently authored. | | `COMPLEX` | Shared settings.json, AGENTS.md, or ownership record; propose exact entry/block edits. |

For UNKNOWN legacy files, compare against current templates to inform the plan. An existing user file stays UNKNOWN after ordinary init edits; only explicit whole-file adoption/replacement establishes ownership. Verbatim hook equality or coding-guide equality apart from the project heading is useful evidence, but do not promote unknown ownership to recorded ownership. Generated-document headings and identity comments can suggest `LIKELY_GENERATED`; this is an annotation under UNKNOWN, not proof that the prose is unchanged. Retired hooks remain UNKNOWN unless provenance establishes them; their names alone do not authorize deletion.

Check HEAD, index, and working tree separately: use Git status/diffs for each path, and verify whether its current bytes equal a version in HEAD or the index. Report **clean recorded version**, **staged changes**, **unstaged changes**, or **untracked**. A tracked file with new edits is not wholly recoverable through checkout. Git errors mean recovery is unverified. Do not stage, restore, reset, or commit files during this check.

Read shared settings and show every proposed removal. Recorded additions may be removed only if they still exactly match; changed/unrecorded rules and groups stay unless the user explicitly selects those particular entries. Existing MCP names and today's permission template do not establish who added a rule. Retained hook files keep their registrations.

Step 3 — Present a concrete deletion plan

List the chosen scope