sync: auto-sync from GURU-5070 at 2026-06-02 20:40:54

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-02 20:40:54

.grok/README.md

@@ -0,0 +1,109 @@
+# Grok + ClaudeTools coexistence
+
+This directory holds Grok-specific configuration and hooks for when the ClaudeTools harness is driven by the xAI Grok TUI/CLI instead of (or in addition to) Anthropic Claude Code.
+
+## Why it exists
+
+The core value of ClaudeTools (coord API for locks/messages/todos/components, SOPS vault, shared .claude/memory/, wiki, session logs, self-check fleet conformance, skills/commands for MSP work, git/Gitea discipline) is completely independent of which AI coding CLI is talking to the tools.
+
+Grok has first-class compatibility for many Claude Code artifacts:
+- Loads `CLAUDE.md` (and friends) as project rules.
+- Scans `.claude/settings.json` for hooks (configurable).
+- Scans `~/.claude/skills/` etc.
+
+We add this `.grok/` tree so Grok can participate fully in the dynamic parts of the harness (per-prompt coord injection, safety blocks, memory sync, recovery) without forking the bash scripts that are the single source of truth.
+
+## Hooks
+
+`.grok/hooks/claudetools.json` wires:
+- `SessionStart` → `.claude/scripts/sync-memory.sh` (keeps profile memory in sync with the git-tracked repo store)
+- `UserPromptSubmit` → `.claude/scripts/check-messages.sh` (injects unread coord messages + dev-mode active locks; output appears in hook annotations / scrollback)
+- `PreToolUse` (for terminal) → `.claude/hooks/block-backslash-winpath.sh` (the famous "don't write D:\path with backslashes in Git Bash" guard)
+
+The JSON sets `GROK_WORKSPACE_ROOT` and `CLAUDE_PROJECT_DIR` so the existing scripts "just work" under either driver.
+
+After adding/changing hooks:
+- In a Grok session: `/hooks-trust` (first time for the project), then `/hooks` or `Ctrl+L` to inspect/reload.
+
+## Recovery
+
+`.claude/scripts/recover_grok_session.py` (MVP) + updates to `recover.md` let you turn a crashed/unsaved Grok session (the UUID dirs under `~/.grok/sessions/<slug>/`) back into a standard ClaudeTools session log that `/save`, wiki tools, etc. understand.
+
+The Claude recover script remains for Claude Code transcripts. Dispatcher logic can be unified later.
+
+## Vault, Gitea, Coord, everything else
+
+All accessed the same way:
+- Vault: `.claude/scripts/vault.sh` (reads `vault_path` from `.claude/identity.json`)
+- Gitea: normal `git` (remote set during onboarding) + any API calls via tokens from vault/1Password
+- Coord: the same no-auth HTTP calls from the bash scripts and from model instructions in CLAUDE.md
+
+When you run tools from Grok (run_terminal_command etc.), you are in a normal shell context and can invoke the full harness.
+
+## Session IDs
+
+We continue to use `HOSTNAME/claude-main` (or the value in identity + check-messages) as the conventional "primary interactive session" id on this host for the coord API. This has already been used successfully by Grok sessions. It keeps locks and messages unified across driver switches on the same machine.
+
+If you run Claude Code and Grok *concurrently* for different work, consider the implications for lock visibility.
+
+## Slash Commands (Skills)
+
+The ClaudeTools slash commands live in `.claude/commands/*.md` (e.g. `/save`, `/checkpoint`, `/sync`, `/rmm`, `/self-check`, `/remediation-tool`, etc.). These are prompt + workflow definitions that extend the AI with MSP-specific capabilities (session logging, remote execution, wiki, PSA integration, etc.).
+
+**They are fully transferrable to Grok.**
+
+We have created native Grok skills at `.grok/skills/<name>/SKILL.md` for every command:
+- Each has proper frontmatter (`name:`, `description:` with trigger phrases like "Use when the user says /save...").
+- This makes them appear automatically as first-class Grok slash commands (`/save`, `/rmm`, etc.) via Grok's project skill discovery (`.grok/skills/` at repo root is scanned).
+- The body delegates to the authoritative source: "Read `.claude/commands/<name>.md` using the `read_file` tool and follow it, adapting for Grok tools (`run_terminal_command` instead of Bash, `spawn_subagent` for delegation, etc.)."
+- Grok's `description` field drives auto-invocation and the `/name` shorthand, exactly like the original Claude Code custom commands.
+
+This keeps the single source of truth in `.claude/commands/` (and the detailed skills in `.claude/skills/` where applicable, e.g. self-check, remediation-tool). The `.grok/skills/` versions are thin, compatible adapters + discovery enablers.
+
+After changes:
+- In a Grok session, the skills should be picked up on load/restart (use `/skills` to list, or just type `/save` etc.).
+- The launcher/system prompt may still inject the originals for now; the `.grok/` versions take precedence for native Grok behavior.
+- Test with `/skills save` or directly `/save`.
+
+See the individual `SKILL.md` files for examples (they all follow the same "read the .claude source + adapt tools + obey CLAUDE.md" pattern).
+
+## Making Grok Remember Things (Like Claude's Memory)
+
+In Claude Code, you "tell it to remember" via project docs, memory features, or session context that gets saved.
+
+Grok equivalents (hybrid with ClaudeTools):
+
+- **Project Rules (always loaded)**: Edit `CLAUDE.md` (Grok scans it for compatibility, along with AGENTS.md etc.). Instructions here apply to every session in the repo/tree. We added the Windows bash fix details there. Deeper subdir rules override.
+
+- **Grok Native Memory** (if enabled): 
+  - Enable persistently: `[memory] enabled = true` in `~/.grok/config.toml` (we did this).
+  - In chat: Say "remember that [fact]" — it saves to `~/.grok/memory/<workspace-slug>/MEMORY.md` (or global).
+  - Commands: `/memory` (browse/edit), `/flush` (save rich summary), "what do you remember?", "forget X".
+  - Auto-saves session summaries.
+  - We seeded global and workspace memory with the bash mapping note.
+
+- **Skills**: Create `.grok/skills/<topic>/SKILL.md` with `name:` and descriptive `description:`. Becomes `/name` command and auto-triggers on matching prompts. We created `.grok/skills/windows-bash/SKILL.md` specifically for the bash issue (and it appears in the skills list).
+
+- **ClaudeTools Shared Memory (recommended for team/repo)**: The primary persistent knowledge is in `.claude/memory/` (index in MEMORY.md, individual .md files like feedback_*.md), `CLAUDE.md`, wiki/, session-logs/, and the `ensure-git-bash.ps1` + profile. Grok is instructed (via CLAUDE.md and skills) to check these first. The `.claude/scripts/sync-memory.sh` keeps things in sync. Add "remember" style notes by editing/creating files there, then reference in CLAUDE.md or a skill.
+
+- **For this bash fix**: It's now "remembered" at multiple layers:
+  - OS level: Profile + helper script.
+  - Docs: CLAUDE.md, .claude/memory/feedback_windows_bash_mapping.md (indexed), .grok/README.md.
+  - Grok native: .grok/skills/windows-bash/SKILL.md + seeded MEMORY.md entries.
+  - Future sessions (Grok or Claude) will see the fix via context loading rules in CLAUDE.md.
+
+To "tell Grok" in future: Describe the fact, and we (or you via /memory if on) will persist it to the appropriate file/skill. Restart Grok session after edits to rules/memory for full effect (or use /reload if available).
+
+See also: `.claude/CLAUDE.md` (Automatic Context Loading, memory sections), Grok user-guide 12-project-rules.md and 13-memory.md, and the new windows-bash skill.
+
+## Future / polish
+
+- Make the hook JSON more robust across PATH/bash resolution (full exe path or a small finder launcher).
+- Full parity in recover_grok_session.py (chat turns, exact file edits via search_replace equivalents, Ollama prose).
+- Self-check updates to explicitly verify `.grok/hooks/` and `.grok/skills/` presence (or treat as capability).
+- Consider a small generator script or "grokify" command to keep the thin wrappers in sync if command docs change significantly.
+- Optional deeper `.grok/agents/` mirrors if you want Grok-specific subagent personas for the coding agents defined in `.claude/agents/`.
+
+All changes here are additive and keep the single source of truth in `.claude/`.
+
+See also: CLAUDE.md (the behavioral contract, loaded by both drivers), the self-check skill, and `.claude/HOOKS.md`.

.grok/hooks/claudetools.json

@@ -0,0 +1,42 @@
+{
+  "description": "ClaudeTools harness hooks for Grok driver. These delegate to the existing .claude/scripts and .claude/hooks bash implementations so that coord message injection, active lock warnings, memory sync, and the backslash-Windows-path safety block continue to work when using Grok instead of (or alongside) Claude Code. The scripts are the source of truth; only thin wrappers here for env + invocation. Uses explicit full paths to Git Bash and python fallback to avoid repeated PATH/WSL/jq resolution or parse errors in the hook runner.",
+  "hooks": {
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "C:\\Program Files\\Git\\bin\\bash.exe -c '\n  export PATH=\"/c/Program Files/Git/bin:/c/Program Files/Git/usr/bin:$PATH\"\n  WS=\"${GROK_WORKSPACE_ROOT:-$PWD}\"\n  export GROK_WORKSPACE_ROOT=\"$WS\"\n  export CLAUDE_PROJECT_DIR=\"$WS\"\n  # Run the existing memory mirror (keeps ~/.claude/projects/.../memory in sync with repo .claude/memory/ for any compat or cross-driver use).\n  /c/Program\\ Files/Git/bin/bash.exe \"$WS/.claude/scripts/sync-memory.sh\" || true\n'",
+            "timeout": 45,
+            "env": {}
+          }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "C:\\Program Files\\Git\\bin\\bash.exe -c '\n  export PATH=\"/c/Program Files/Git/bin:/c/Program Files/Git/usr/bin:$PATH\"\n  WS=\"${GROK_WORKSPACE_ROOT:-$PWD}\"\n  export GROK_WORKSPACE_ROOT=\"$WS\"\n  export CLAUDE_PROJECT_DIR=\"$WS\"\n  # The existing check-messages.sh does the coord curls for unread messages (to personal + alias + broadcasts) and (in dev mode) active locks.\n  # Under Grok its stdout will appear as a hook annotation in scrollback (visible to user). The model is also instructed via CLAUDE.md to perform the session-start protocol.\n  /c/Program\\ Files/Git/bin/bash.exe \"$WS/.claude/scripts/check-messages.sh\" || true\n'",
+            "timeout": 25,
+            "env": {}
+          }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "run_terminal_cmd|bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "C:\\Program Files\\Git\\bin\\bash.exe -c '\n  export PATH=\"/c/Program Files/Git/bin:/c/Program Files/Git/usr/bin:$PATH\"\n  WS=\"${GROK_WORKSPACE_ROOT:-$PWD}\"\n  export GROK_WORKSPACE_ROOT=\"$WS\"\n  export CLAUDE_PROJECT_DIR=\"$WS\"\n  # Normalize Grok hook stdin (toolInput camelCase + hookEventName) into the shape the existing block script expects (.tool_input), then pipe.\n  # Prefer jq; fallback to python (project uses py) to avoid jq-not-found or related parse errors.\n  INPUT=$(cat)\n  NORM=$(printf \"%s\" \"$INPUT\" | jq -c \".tool_input = (.toolInput // .tool_input // {})\" 2>/dev/null || py -c \"import sys,json; d=json.load(sys.stdin); ti = d.get('toolInput') or d.get('tool_input') or {}; d['tool_input'] = ti; print(json.dumps(d))\" 2>/dev/null || printf \"%s\" \"$INPUT\")\n  printf \"%s\" \"$NORM\" | /c/Program\\ Files/Git/bin/bash.exe \"$WS/.claude/hooks/block-backslash-winpath.sh\"\n'",
+            "timeout": 10,
+            "env": {}
+          }
+        ]
+      }
+    ]
+  }
+}

.grok/skills/1password/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: 1password
+description: >
+  Integrate 1Password secrets management into workflows. Store API keys/credentials, read secrets into scripts or .env, set up references, rotate, manage service accounts. Use when the user says /1password, "get the secret from 1p", "store this in 1password", "rotate the token", or needs 1Password CLI (op) operations.
+---
+
+# /1password — 1Password Secrets Integration
+
+**Grok skill:** Corresponds to the shared command `.claude/commands/1password.md` and the implementation skill in `.claude/skills/1password/`.
+
+When this skill is used:
+- Read the command documentation `.claude/commands/1password.md`.
+- The actual logic lives in the 1password skill directory (multiple .sh and .md files).
+- Use `run_terminal_command` with the `op` CLI (1Password service account or biometric as appropriate).
+- Prefer vault for most MSP creds; 1Password is the fallback / for certain service accounts.
+- Never hardcode secrets; always use references or the vault wrapper.
+
+The skill handles service-account token setup, item creation, field gets, etc.
+
+See `.claude/skills/1password/SKILL.md` (the real one) and the command for usage patterns, security notes, and integration with the rest of the harness (e.g. for CI/CD or Docker).
+
+This is often used alongside the vault.sh flows.

.grok/skills/autotask/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: autotask
+description: >
+  Query companies, tickets, contacts, and resources in Autotask PSA via the REST API. Use for Autotask lookups, ticket creation, or any Autotask PSA work alongside or instead of Syncro.
+---
+
+**Grok skill.** See full command and implementation at `.claude/commands/autotask.md` (and any associated skill/scripts).
+
+When invoked, read the source command doc and use `run_terminal_command` (or dedicated tooling) to interact with the Autotask API using credentials from the vault. Follow all the same safety and data rules as the syncro command.

.grok/skills/checkpoint/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: checkpoint
+description: >
+  Create detailed git commit with comprehensive commit message. Use when the user says /checkpoint, "make a checkpoint", "commit the work with context", "git checkpoint", or after reaching a stable milestone / completing a feature.
+---
+
+# /checkpoint — Full Git + Context Save
+
+Create a detailed git commit with a comprehensive commit message (includes context from the session).
+
+**Grok adaptation:** This skill wraps the shared ClaudeTools command defined in `.claude/commands/checkpoint.md`. 
+
+When invoked:
+- Read the full authoritative instructions with `read_file .claude/commands/checkpoint.md`.
+- Follow the steps for git analysis, staging (`git add -A`), drafting the message (often via local Ollama for prose), and committing.
+- Adapt tools: `run_terminal_command` for all git and shell steps. Use `spawn_subagent` if delegating analysis.
+- Respect CLAUDE.md rules: Coordinator model (you coordinate, delegate big work), no emojis, ASCII markers, proper session attribution via identity.
+
+Key parts from the command (see full file for complete details):
+
+## Part 1: Git Checkpoint
+1. git status, git diff, recent log.
+2. Stage everything with `git add -A`.
+3. Draft commit message body (use Ollama if available per identity.json endpoints).
+4. Commit with good message that captures the "why" and key changes.
+5. (The command continues with context saving aspects in the full spec.)
+
+After commit, often followed by /sync or part of /scc.
+
+Full workflow, Ollama prompts for the message, and integration with session context are in `.claude/commands/checkpoint.md`.
+
+This pairs with /save (for the narrative log) and /sync.

.grok/skills/context/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: context
+description: >
+  The user is referencing previous work. Search wiki, session logs, credentials, and coord for context before asking the user. Use when the user says /context, "continue the previous work", "resume", "what did we do on X", "look up the context for this client/project".
+---
+
+# /context — Previous Work Lookup
+
+**Grok skill:** This maps to the shared command in `.claude/commands/context.md`.
+
+Per the harness (and CLAUDE.md "Automatic Context Loading" and "Context Recovery" sections):
+
+- ALWAYS check wiki/ first (clients/, projects/, systems/, patterns/).
+- Then session-logs/ (root, projects/*, clients/*).
+- credentials.md (or vault).
+- Coord API status, locks, messages, components.
+- Project CONTEXT.md files.
+
+When this skill runs:
+- Read `.claude/commands/context.md` for the exact protocol.
+- Use tools: `read_file` for wiki and log files (GrepAI via MCP or the dedicated grep tool is excellent for semantic search across session logs).
+- Query coord via `run_terminal_command` with curl to http://172.16.3.30:8001/api/coord/...
+- Never ask the user for info that is already in these sources.
+
+This is one of the most important commands for maintaining continuity across sessions and machines. The CLAUDE.md has a detailed trigger table.
+
+See the source command for the full checklist and "Never ask for info in:" rules.

.grok/skills/create-spec/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: create-spec
+description: >
+  Create an app spec for autonomous coding (project). Use when starting a new project, "/create-spec", "write a spec for <feature>", or preparing for AutoCoder / implementation planning.
+---
+
+**Grok skill.** Authoritative content in `.claude/commands/create-spec.md`.
+
+Read the source when activated. It generates structured specifications (usually in specs/ or docs/specifications/) that downstream agents (implement, shape-spec, etc.) can consume. Use file tools to write the output spec.

.grok/skills/feature-request/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: feature-request
+description: >
+  GuruRMM Feature Request — Comprehensive Analysis & Specification. Use when Howard (or a teammate) submits a GuruRMM feature request. Classifies it and messages Mike. Triggers on "feature request", "/feature-request", or specific RMM roadmap items.
+---
+
+# /feature-request — GuruRMM Feature Request Analysis
+
+This is the command for structured feature request handling in the GuruRMM project.
+
+**See source:** `.claude/commands/feature-request.md` for the full workflow (classification, shape-spec generation, coord messaging to the right person, links to docs/roadmap).
+
+For Grok:
+- Read the command doc.
+- It likely uses the shape-spec skill, coord messages (POST to /api/coord/messages), and analysis of the RMM codebase (via grep or deep-explore if available).
+- Use `spawn_subagent` for parts of the analysis if complex.
+- The output often produces plan.md / shape.md etc. in a specs/ folder or directly messages via the coord system.
+
+This command bridges user requests to the active development process on the gururmm submodule.

.grok/skills/forum-post/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: forum-post
+description: >
+  Post a technical article to community.azcomputerguru.com (Flarum forum). Drafts from context, shows preview, inserts via paramiko SSH to Flarum DB. Use for "/forum-post" or sharing a solution writeup.
+---
+
+See `.claude/commands/forum-post.md` for the workflow (analysis of session logs or docs, draft generation, preview, then the actual DB insert via SSH + SQL).
+
+Grok: read the command + use terminal for the SSH parts (or the 1password/vault for creds). Be careful with the forum DB writes.

.grok/skills/gc-feature-request/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: gc-feature-request
+description: >
+  GuruConnect Feature Request — Analysis & Specification. Similar to feature-request but for the GuruConnect project. Use for GC-specific roadmap items.
+---
+
+See `.claude/commands/gc-feature-request.md`. Follows a similar classification + spec production flow as /feature-request but scoped to guruconnect components (server, agent, dashboard).

.grok/skills/import/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: import
+description: >
+  Import any folder of data into the ClaudeTools structure. Analyzes files, classifies content, proposes placement, sanitizes credentials, organizes into clients/, projects/, wiki/, etc. Use for "/import <path>" or onboarding new data dumps.
+---
+
+Full logic in `.claude/commands/import.md`. Uses analysis (often with grepai or reading many files), then write operations to the right locations, and updates to indexes/CATALOG_*.md.

.grok/skills/inject-standards/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: inject-standards
+description: >
+  Loads one or more standards files from `.claude/standards/` and displays their full content for the current task. Use when standards (api, client, git, powershell, security, etc.) need to be followed.
+---
+
+See `.claude/commands/inject-standards.md`. Simple loader that cats the relevant standards/*.md files into context.

.grok/skills/mailbox/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: mailbox
+description: >
+  Read and send mail for an Arizona Computer Guru mailbox via Microsoft Graph (shared Claude-MSP-Access app). Defaults to the mailbox of the running user (from identity.json). Use for "/mailbox", "check my email", "send a message as <user>@azcomputerguru.com".
+---
+
+See `.claude/commands/mailbox.md` and the remediation-tool skill (they share Graph access patterns). Use vault/1p for the app credentials. Gated for writes.

.grok/skills/mode/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: mode
+description: >
+  Manually set the work mode (remediation, client, infra, dev, general), or let it auto-detect. Mode controls terminal color, operational posture, and hook behavior (e.g. lock checking in dev mode). Use when the user says /mode, "set mode to infra", "work in client mode for <client>", "switch to remediation".
+---
+
+# /mode — Work Mode Control
+
+Controls the current work mode for this session.
+
+**Grok implementation:** See `.claude/commands/mode.md` for the full command logic and auto-detection rules.
+
+Key modes (from CLAUDE.md):
+- remediation: M365 / breach / tenant sweep focus, Graph API, full audit.
+- client: Careful with data, session logs go under clients/<name>/, name the client.
+- infra: Confirm before destructive ops, backup-first, server/SSH/firewall/DNS.
+- dev: Delegate freely (Coding/Explore/Review agents), less confirmation for code work.
+- general: Lightweight default.
+
+**Actions when mode changes:**
+- Announce `[MODE -> <new>]`
+- Tell user to run `/color <color>` if applicable.
+- **MANDATORY:** Write the new mode to `.claude/current-mode` (use relative path or forward slashes on Windows/Git Bash; the block-backslash hook protects this).
+  Example: `echo dev > .claude/current-mode`
+
+The UserPromptSubmit hook (both Claude and our .grok/hooks) reads this file to decide whether to show active locks etc.
+
+When this skill is active:
+- Read `.claude/commands/mode.md` and the Work Mode section of CLAUDE.md.
+- Use `run_terminal_command` (with proper bash) to write the file.
+- Update any in-memory state.
+
+Auto-detect on first user message using keywords (client names, "365", "remediation tool", server names, "for <client>", code/Rust keywords, etc.). First match wins.
+
+See also `.claude/current-mode` (gitignored machine-local file).

.grok/skills/recover/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: recover
+description: >
+  Reconstruct a session log from a crashed or unsaved session transcript (Claude Code or Grok format). Use when the user says /recover, "recover the session", "reconstruct the log from the crash", "/recover latest", or provides a UUID.
+---
+
+# /recover — Session Recovery
+
+Reconstruct a ClaudeTools session log from a driver transcript when the session ended before /save could run.
+
+**Grok support:** We have added native support.
+
+- For Claude Code transcripts: uses `.claude/scripts/recover_session.py`
+- For Grok sessions: uses the new `.claude/scripts/recover_grok_session.py` (discovers `~/.grok/sessions/<slug>/<uuid>/`, extracts terminal logs, etc.)
+
+See the updated `.claude/commands/recover.md` for usage, flows, and the Grok-specific section.
+
+When this skill is invoked:
+- Read `.claude/commands/recover.md` for the current dispatcher logic and examples.
+- Use `run_terminal_command` to invoke the appropriate python script with --list / --latest / --uuid / --print / --auto.
+- The output should be reviewed before writing (the scripts support --print for review).
+- Adapt any sub-agent usage in the recovery process to Grok's `spawn_subagent`.
+
+This is critical for continuity after crashes. The recovered log can then be committed via /checkpoint or /scc.
+
+Full details on what gets extracted (verbatim commands/outputs vs. prose) and placement of the resulting .md are in the command doc and the two recover_*.py scripts.

.grok/skills/remediation-tool/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: remediation-tool
+description: >
+  M365 tenant investigation and remediation using the ComputerGuru tiered MSP app suite (Security Investigator, Exchange Operator, User Manager, Tenant Admin, Defender Add-on). Gated writes. Use when the user says "remediation tool", "365 remediation", "check <user> mailbox", "breach check", "tenant sweep", "inbox rules for <user>", or any M365 Graph/Exchange admin task.
+---
+
+# /remediation-tool — M365 Investigation & Remediation
+
+**Grok skill for the shared command.** Full details, safety gates, and the 5-app suite description are in `.claude/commands/remediation-tool.md` and the implementation in `.claude/skills/remediation-tool/`.
+
+**Important posture (from CLAUDE.md and the skill):**
+- Read-only by default.
+- All write/remediation actions are **gated** behind explicit `--confirm` or user approval.
+- Use the skill's structured flows for tenant sweeps, password spray detection, inbox rule enumeration, mailbox searches, etc.
+- NOT for CIPP — this is the direct Graph API app suite (Claude-MSP-Access or equivalent).
+
+When invoked:
+- Read the command doc `.claude/commands/remediation-tool.md`.
+- Read the full skill `.claude/skills/remediation-tool/SKILL.md` (it has the detailed model).
+- Use tools to run the underlying Python/Graph scripts (via `run_terminal_command` after activating the right env/venv if needed).
+- For any credential or token work, go through the vault or 1password skill.
+- Follow all compliance/audit logging requirements in the skill.
+
+This is heavily used in remediation mode. The skill itself is already a proper SKILL.md, so this Grok wrapper mainly ensures `/remediation-tool` shorthand works and points to the source.
+
+See the remediation-tool skill directory for the actual implementation scripts and rules.

.grok/skills/rmm/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: rmm
+description: >
+  Run commands, investigate agents, and execute remote scripts via the GuruRMM agent fleet. Use when the user says /rmm, "list agents", "run on the server", "rmm shell <host>", "poll the command", "check rmm agents", or any GuruRMM remote execution task.
+---
+
+# /rmm — GuruRMM remote command execution
+
+Interact with the GuruRMM agent fleet: list agents, run remote commands (PowerShell, shell, Python), poll for output, and cancel in-flight tasks.
+
+**Grok adaptation:** This is the project skill for the shared ClaudeTools /rmm command. Full details, subcommands, and implementation notes are in the source `.claude/commands/rmm.md`.
+
+When activated:
+- Read `.claude/commands/rmm.md` (and any referenced rmm skill or script) using `read_file`.
+- Default posture: **read before write**. Look up the agent by hostname first.
+- Use the `run_terminal_command` tool (or MCP if available) for any local parts, but the actual remote dispatch goes through the RMM mechanisms (the command likely uses the rmm CLI or API calls via scripts).
+- Adapt any "Claude" specific delegation to `spawn_subagent` where useful.
+- Follow CLAUDE.md: be careful with infra actions, confirm before destructive remote ops.
+
+## Common subcommands (from source)
+- /rmm agents [<client>]
+- /rmm agent <hostname|uuid>
+- /rmm run <hostname|uuid>
+- /rmm shell <host> <cmd>
+- /rmm ps <host> <cmd>
+- /rmm status / output / cancel / history
+
+See the full `.claude/commands/rmm.md` for exact syntax, safety rules, and integration with the live RMM server at 172.16.3.30:3001.
+
+This skill is often used in infra and client modes.

.grok/skills/save/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: save
+description: >
+  Save a comprehensive session log to the appropriate `session-logs/` directory, then sync the repo.
+  Use when the user invokes /save, says "save the session", "log this work", "save session log", "checkpoint the context", or similar. Triggers after significant work, at end of day, before switching machines.
+---
+
+# /save — Comprehensive Session Log + Sync
+
+Save a comprehensive session log to the appropriate `session-logs/` directory, then sync the repo.
+
+`/save` and `/sync` share `bash .claude/scripts/sync.sh` as the canonical driver for git operations. The only difference: `/save` writes a session log first, then calls sync. `/sync` calls sync directly (no log).
+
+**Grok note (coexistence):** This is the native Grok skill wrapper for the shared ClaudeTools command. The complete detailed specification, required sections, location rules, and phase-by-phase instructions live in the authoritative source `.claude/commands/save.md`. When this skill is activated:
+
+1. Use the `read_file` tool to load `.claude/commands/save.md` (and related like whoami-block.sh output).
+2. Follow its instructions precisely.
+3. Adapt for Grok's tool set:
+   - Shell commands → `run_terminal_command`
+   - Sub-agents / delegation → `spawn_subagent` (with appropriate subagent_type like "general-purpose")
+   - File reads → `read_file`
+   - Edits → `search_replace`
+4. Still obey the top-level CLAUDE.md contract for this repo: Coordinator posture (delegate heavy work), no emojis, use [OK]/[ERROR] ASCII markers, session start protocol (identity, mode, coord messages/locks), etc.
+5. For narrative sections marked "(Ollama)", you can use local models per identity or direct reasoning; keep factual.
+
+## Quick Reference (from source)
+
+### Location rules
+- Single project: `projects/<project>/session-logs/YYYY-MM-DD-session.md`
+- Client: `clients/<slug>/session-logs/YYYY-MM-DD-session.md`
+- General/multi: `session-logs/YYYY-MM-DD-session.md`
+
+### Required sections (order)
+1. **User** block — run `bash .claude/scripts/whoami-block.sh` and paste verbatim.
+2. **Session Summary**
+3. **Key Decisions**
+4. **Problems Encountered**
+5. **Configuration Changes**
+6. **Credentials & Secrets** (unredacted if new)
+7. **Infrastructure & Servers**
+8. **Commands & Outputs**
+9. **Pending / Incomplete Tasks**
+10. **Reference Information**
+
+Append updates to existing same-day file with `## Update: HH:MM ...` header.
+
+After writing the log, perform the sync (git add, commit if needed, push).
+
+See the full `.claude/commands/save.md` and `.claude/commands/README.md` (and related skills like checkpoint, scc) for complete flows, error handling, and examples.
+
+When in doubt, include MORE detail — these logs are searched by future sessions and wiki-compile.

.grok/skills/scc/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: scc
+description: >
+  Quick command to save session log, stage everything, and push to Gitea in one shot. Use when the user says /scc, "save commit push", "scc it", "quick save and sync".
+---
+
+# /scc - Save, Commit, and Push
+
+Quick one-shot: save session log + git add -A + commit + push to Gitea.
+
+**Grok wrapper:** See the detailed steps in the source `.claude/commands/scc.md`.
+
+Workflow (adapt for Grok tools):
+1. Save session log using the /save logic (determine scope, write narrative sections, use whoami-block, etc.). Read `.claude/commands/save.md` and `.claude/commands/scc.md`.
+2. `run_terminal_command` with `git add -A`.
+3. Commit with conventional message (the source suggests a specific "scc: ..." format; update Co-Authored-By if relevant or omit for Grok).
+4. Push.
+
+This is a convenience composition of /save + git operations + push. After the save log is written, it forces a commit of everything.
+
+Full details, exact commit message template, and handling for the vault repo or other repos are in `.claude/commands/scc.md`.
+
+Often the fastest way to checkpoint and share work at the end of a session.

.grok/skills/self-check/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: self-check
+description: >
+  Self-diagnose this ClaudeTools machine's harness wiring (tools, identity, hooks, skills, commands, scripts, capability tier, connectivity) against the fleet baseline, and optionally publish the census to coord. Use when the user says /self-check, "self check", "harness check", "doctor", "is everything wired", "fleet conformance".
+---
+
+# /self-check — ClaudeTools Harness Self-Diagnosis
+
+This is the Grok-native skill entrypoint. It already has a matching implementation in `.claude/skills/self-check/SKILL.md` (the full model) and the runner script.
+
+**For Grok users:** Invoking /self-check should delegate to or mirror the self-check skill.
+
+- The command thin-runner lives at `.claude/commands/self-check.md`.
+- The real engine and baseline are in `.claude/skills/self-check/`.
+
+Recommended:
+1. Read `.claude/skills/self-check/SKILL.md` for the complete description, how to run the probe script, interpreting grades (RED/AMBER/GREEN), publishing, fanout, aggregate, etc.
+2. Use `run_terminal_command` to execute:
+   `SELFCHECK_TS="$(date -u +%Y-%m-%dT%H:%M:%SZ)" bash .claude/skills/self-check/scripts/self-check.sh report`
+   (or --json, --publish, etc.)
+
+The self-check is driver-agnostic — it validates the files, scripts, hooks wiring, identity, tools, and the .claude/ + .grok/ harness pieces (including the new Grok hooks and skills we added for coexistence).
+
+See the source skill for full details on modes, the baseline manifest, and how it helps keep the fleet consistent across machines (some running Claude Code, some Grok).
+
+Also update the census component on coord for this host.

.grok/skills/shape-spec/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: shape-spec
+description: >
+  Pre-implementation planning command for a GuruRMM (or similar) feature. Produces a structured spec folder (plan.md, shape.md, references.md, standards.md) that persists across sessions. Use for "/shape-spec", complex feature planning, or before coding a non-trivial RMM/GuruConnect change.
+---
+
+**Grok skill.** See `.claude/commands/shape-spec.md` for the full process (it often invokes analysis of the codebase + roadmap + existing specs).
+
+When used, read the command, explore the relevant project (using grepai or tools), then produce the spec artifacts in the conventional specs/<slug>/ location. This eliminates re-explaining context on resume.

.grok/skills/sync/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: sync
+description: >
+  Sync the ClaudeTools and vault repos with Gitea. Use when the user says /sync, "sync now", "push the changes", "sync repos", after offline work, before switching machines, or to check queue status.
+---
+
+# /sync — Cross-Machine Context Sync
+
+Synchronize queued contexts across machines (and the vault repo).
+
+**Grok note:** Native Grok skill for the shared command. Authoritative details in `.claude/commands/sync.md`.
+
+When this skill activates:
+- First, check for uncommitted session-logs (as described in the source).
+- If uncommitted logs exist, warn the user and recommend /save first.
+- Then run the sync logic (typically `bash .claude/scripts/sync.sh`).
+- Use `run_terminal_command` for the git / sync operations.
+- Follow any pre/post steps in the command doc.
+
+## Key logic (see full source)
+- Phase 0: Check `git status --porcelain` for uncommitted session-logs/*.md . If present, emit warning and suggest /save.
+- Then delegate to the sync script for staging, committing with conventional messages, pushing to Gitea, and handling the vault repo sync.
+
+The command also covers offline mode, queue handling, and conflict resolution.
+
+Read `.claude/commands/sync.md` (and related sync.sh) for the complete implementation and safeguards.
+
+This is often used after /save or as part of /scc.

.grok/skills/syncro-emergency-billing/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: syncro-emergency-billing
+description: >
+  Rules for applying emergency or after-hours labor premiums in Syncro tickets. Companion to /syncro.
+---
+
+See `.claude/commands/syncro-emergency-billing.md`. Specific policy + calculation rules when billing time outside normal hours.

.grok/skills/syncro/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: syncro
+description: >
+  Create, update, close, comment on, and bill tickets in Syncro PSA. Use for any Syncro ticket work, "create ticket", "update ticket #123", "close the Syncro ticket", "bill this time", "syncro-emergency-billing".
+---
+
+# /syncro — Syncro PSA Integration
+
+**Grok skill for the shared command.** Details in `.claude/commands/syncro.md` (and the emergency billing variant).
+
+When used:
+- Read the command file for exact subcommands, authentication (via vault or 1p), and the Python/JS scripts that talk to the Syncro API.
+- Typical flow: query companies/tickets, create with proper priority/assignment, add notes with time entries, transition status, generate invoices.
+- There is special handling for after-hours/emergency premiums (see syncro-emergency-billing.md).
+- Use `run_terminal_command` to invoke the syncro command-line or scripts.
+- Be careful with billing data — follow the rules in the docs.
+
+This is heavily used in client mode. The command and its skill implementation contain the API client logic and templates.
+
+See also autotask.md for the other PSA.

.grok/skills/wiki-compile/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: wiki-compile
+description: >
+  Seed new wiki articles or refresh existing ones from session logs, client documents, and live Syncro PSA data. Use when the user says /wiki-compile, "update the wiki for <client>", "compile wiki", "refresh the project article".
+---
+
+# /wiki-compile — Wiki Article Generation
+
+**Grok skill wrapper.** Full command in `.claude/commands/wiki-compile.md`.
+
+When activated, read the source command and the underlying scripts/logic. It analyzes session-logs, pulls from Syncro (or Autotask), and produces or updates articles under `wiki/clients/`, `wiki/projects/`, `wiki/systems/`.
+
+Use `run_terminal_command` for the actual compilation script(s).
+Follow the output location and linting rules in the command doc.
+
+See also `/wiki-lint`.
+
+The wiki is a primary context source per CLAUDE.md "Automatic Context Loading".

.grok/skills/wiki-lint/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: wiki-lint
+description: >
+  Health-check the wiki for missing articles, stale content, broken backlinks, and cross-reference gaps. Use with /wiki-lint or after wiki-compile runs.
+---
+
+**Grok skill.** Details in `.claude/commands/wiki-lint.md`.
+
+Runs checks against the wiki/ tree (stale IPs, orphaned pages, bad links to clients/projects/systems). Use `read_file` + grep tools (or the grepai MCP) heavily. Report findings and suggest fixes (often via wiki-compile or manual edits).

.grok/skills/windows-bash/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: windows-bash
+description: >
+  On Windows (especially in PowerShell-based AI tool sessions like this Grok TUI), ensure the `bash` command resolves to Git for Windows / MSYS bash (required by the ClaudeTools harness) instead of the WSL stub. Use when you see WSL errors, when running vault.sh/sync.sh/hooks, when "bash --version" shows non-MSYS, or on any "bash" invocation for .claude/scripts or hooks. Triggers on "bash issue", "map bash", "Git Bash", "WSL stub", "ensure-git-bash".
+---
+
+# Windows Bash Mapping Skill (Grok Native)
+
+**Core rule for this repo on Windows:** The ClaudeTools harness (`.claude/scripts/*.sh`, hooks, `vault.sh`, `sync.sh`, etc.) **requires** the Git for Windows/MSYS `bash` (version like "5.2.37(1)-release (x86_64-pc-msys)", supports `/d/claudetools` paths, etc.).
+
+Plain `bash` in PowerShell often resolves to the useless WSL stub in `WindowsApps\`.
+
+## The Fix (run this early)
+
+```powershell
+$gitBin = "C:\Program Files\Git\bin"
+$gitUsrBin = "C:\Program Files\Git\usr\bin"
+if ((Test-Path $gitBin) -and ((Get-Command bash -ErrorAction SilentlyContinue).Source -notlike '*Git*bin*bash.exe')) {
+    $env:Path = "$gitBin;$gitUsrBin;" + ($env:Path -replace [regex]::Escape("$gitBin;"), '' -replace [regex]::Escape("$gitUsrBin;"), '')
+}
+```
+
+After this:
+- `Get-Command bash` → `C:\Program Files\Git\bin\bash.exe`
+- `bash --version` shows the correct MSYS one.
+- You can use plain `bash .claude/scripts/vault.sh list` etc.
+
+## Project Helper Script
+
+Source the reusable one (always safe/idempotent):
+
+```powershell
+. .claude/scripts/ensure-git-bash.ps1
+```
+
+See the script for the exact code and comments. It is also referenced from the user's PowerShell profile so new sessions auto-fix.
+
+## In This Session / Tool Context
+- If a command needs bash, start by sourcing the helper or running the snippet above.
+- For one-off critical calls (e.g. vault), you can also use the full explicit path: `"C:\Program Files\Git\bin\bash.exe" .claude/scripts/vault.sh get-field ...`
+- Git Bash terminals (launched directly) already have the right `bash`.
+
+## Related Gotchas (from CLAUDE.md)
+- For writing `.claude/current-mode` etc.: use relative paths or forward slashes only (`/d/claudetools/...`). The `block-backslash-winpath.sh` hook protects this.
+- SSH: always `C:\Windows\System32\OpenSSH\ssh.exe` (system), **never** Git for Windows SSH.
+- See `.claude/memory/feedback_windows_bash_mapping.md` and the Windows section in the root `CLAUDE.md` for the full documented fix.
+
+This skill ensures you (Grok) remember and apply the mapping automatically on Windows sessions in this repo. The knowledge is also in the shared ClaudeTools memory system (`.claude/memory/`) and `CLAUDE.md` so it works for both Claude Code and Grok drivers.