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/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.