5.5 KiB
name, description
| name | description |
|---|---|
| context | 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), Grok MUST automatically load context using this trigger table before any response or action when keywords match. This gives Grok the same "automatically know the context" ability as Claude for requests like "Go ahead and remove that machine from MSP backups" (detect "mspbackups" + client "glaztech" + machine "SBS", then load wiki/clients/glaztech.md + clients/glaztech/ + B2/mspbackups context + RMM backup status + relevant session logs + memory + use b2 skill for removal).
Automatic Context Loading Trigger Table (Grok equivalent, using GrepAI MCP + tools):
| Trigger | Action (Grok implementation) |
|---|---|
| Client name mentioned (e.g. glaztech, cascades) | Use search_tool + use_tool (grepai__grepai_search "glaztech client wiki mspbackups") FIRST, then read wiki/clients/<slug>.md (GrepAI first), then clients/<name>/session-logs/ for recent detail. Load client backup docs. |
| "mspbackups", MSP backups, backup storage, B2, MSP360 | Use GrepAI MCP for "mspbackups B2 bucket glaztech SBS remove" , then .grok/skills/b2/SKILL.md (Grok mirror), RMM migrations for mspbackups_integration, .claude/agents/backup.md , client backup.md files. Find machine prefix/key and use b2 delete-*-with-confirm. |
| GuruRMM / Dataforth / project keywords (e.g. gururmm, msp-tools) | Use GrepAI first, read wiki/projects/<slug>.md FIRST, then projects/<project>/CONTEXT.md, query coord API status + components via run_terminal_command curl. |
| Server/hostname/IP mentioned (e.g. SBS, glaztech machine) | Use GrepAI "SBS glaztech server hostname", read wiki/systems/<slug>.md FIRST for synthesized knowledge, then RMM agents, client servers/. |
| "continue", "resume", "back to", "finish", "remove that machine" | Use GrepAI for context, read project wiki article + CONTEXT.md, check coord API for locks + unread messages (display any UNREAD COORD MESSAGES verbatim first). |
| Servers, IPs, credentials, deploy questions, "MSP backups" | Check wiki/systems or clients first (GrepAI), then CONTEXT.md / .grok/memory/README.md — answer from it, never ask. Use vault via .grok/skills/1password or scripts. |
| Uncertainty >5% about infra or recent work, or high-level request like remove from backups | ALWAYS: GrepAI search first (e.g. query="mspbackups glaztech SBS remove machine B2 key"), then wiki first, then CONTEXT.md / session-logs / .claude/memory/ before asking the user. Use context skill + deep-explore agent if complex. |
Grok Context Loading Workflow (MANDATORY in this skill and all context-heavy tasks):
- GrepAI-first (critical, via our .grok/config.toml native MCP + .grok/skills/ enforcement): Call
search_toolto discovergrepai__grepai_searchetc., thenuse_toolwith natural language query for the request (e.g. "remove SBS machine from mspbackups glaztech B2"). This finds relevant code, logs, memory, wiki chunks semantically. Only then read full files if needed. - Use .grok/ pointers: .grok/memory/README.md for history, .grok/standards/README.md (g repai-first), .grok/REFERENCE.md , .grok/agents/backup.md .
- ALWAYS check wiki/ first (use GrepAI "wiki/clients/glaztech" or direct after search), clients// , projects/ , .claude/memory/ feedback files for mspbackups lessons.
- Then session-logs/ (GrepAI or grep for keywords like "SBS", "mspbackups", "backup key").
- credentials via vault (1password skill or .claude/scripts/vault.sh via terminal, never hardcode).
- Coord API for live state (locks, todos, components for the project/client).
- Project CONTEXT.md and .grok/agents/ for synthesized knowledge.
- For MSP backups removal specifically: Load glaztech client full context, search B2 account structure for the machine's prefix/key in MSPBackups* or ACG-GLAZTECH bucket, use b2 skill's delete-key / delete-prefix --confirm (gated), update docs (session log in clients/glaztech/session-logs/, wiki if needed, memory feedback if new lesson), claim coord lock if multi-step, publish to coord if applicable. Use RMM if the machine status needs update in backup_provider_registry or agent_backup_status.
- Never ask the user for info already in these sources.
When this skill runs:
- Read
.claude/commands/context.mdfor the exact protocol (GrepAI first before read). - GrepAI MCP first for all lookups as detailed above (example query in prompt: "SBS glaztech mspbackups backup machine").
- Query coord via
run_terminal_commandwith curl... - For actual work (e.g. the removal), delegate to appropriate Grok skill like b2, and use .grok/agents/backup.md or spawn_subagent with deep-explore/coding if code changes needed.
- Log the work with /save or session log append in the correct clients/ or projects/ location per FILE_PLACEMENT_GUIDE (GrepAI for placement rules first).
This is one of the most important for Grok to have the same automatic context ability as Claude for MSP/client/infra tasks. The CLAUDE.md trigger table + GrepAI + .grok/ mirrors give Grok native power here.
See the source command for full checklist and "Never ask for info in:" rules. Update .claude/memory/ or .grok/memory/ with new lessons from the task.