tools-update-cron: sync 2026-08-09 — 37 skill(s) updated
This commit is contained in:
Hermes Agent
+122
-192
@@ -1,242 +1,172 @@
|
||||
---
|
||||
name: ask-grok
|
||||
description: Persistent peer Hermes agent for delegated work on the grok45 profile (xAI Grok 4.5). `ask grok <instructions>` delegates a task with full context via headless one-shot commands. Session persists across all turns in one Hermes session via --resume.
|
||||
version: 1.4.0
|
||||
description: "Delegate tasks to Grok 4.5 or Grok Build on 10.0.0.15."
|
||||
version: 1.0.0
|
||||
author: Hermes Agent
|
||||
license: MIT
|
||||
platforms: [linux]
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [hermes, peer, delegation, parallel, review, validation, grok, xai]
|
||||
related_skills: [ask-grok, ask-claude, ask-deep, ask-hermes, hermes-agent]
|
||||
tags: [grok, xai, delegation, ssh, headless, grok-build]
|
||||
related_skills: [ask-claude, ask-hermes, deep-research]
|
||||
---
|
||||
|
||||
# ask-grok — Peer Hermes Agent for Delegated Work (xAI Grok 4.5 Profile)
|
||||
# ask-grok — Delegate Tasks to Grok on 10.0.0.15
|
||||
|
||||
## Overview
|
||||
Two modes, one skill:
|
||||
|
||||
A persistent peer Hermes agent session for delegated work. The peer runs on the grok45 profile (`hermes -p grok45`) — a separate agent instance with its own workspace, SOUL.md, AGENTS.md, and all tools (terminal, file, web search, MCP). Fresh context, no memory of this session. Used for parallel work, peer review, validation, and delegated tasks.
|
||||
| Mode | Command | Behavior | Session |
|
||||
|------|---------|----------|---------|
|
||||
| Quick ask | ask grok | Inline, fire-and-forget | Stateless |
|
||||
| Project | ask grok build | Background, persistent | Named session (-s) |
|
||||
|
||||
Each `ask grok` is a one-shot headless command that runs, returns a clean response, and exits. Continuity (the peer remembering prior turns) comes from `--resume <session_id>`, not from a live process. No start/stop needed — the session starts on the first ask and ends when the Hermes session ends.
|
||||
## Models
|
||||
|
||||
## When to Use
|
||||
- grok / ask grok → grok-4.5 (flagship, 500K ctx, $2/$6 per M)
|
||||
- grokb / ask grokb → grok-build-0.1 (coding-specific, 256K ctx, $1/$2 per M)
|
||||
|
||||
- Want a second agent to do real work in parallel: read files, run tests, validate, search
|
||||
- Want peer review of my recommendation with full tool access
|
||||
- Multi-turn task: peer can iterate, push back (via --resume)
|
||||
- Want local delegation without leaving the terminal
|
||||
## Infrastructure
|
||||
|
||||
## When NOT to Use
|
||||
- Host: 10.0.0.15 (LXC)
|
||||
- Binary: ~/.grok/bin/grok v0.2.112 (NOT in PATH — use full path)
|
||||
- Auth: XAI_API_KEY env var already set on the LXC
|
||||
- Config: ~/.grok/config.toml — add --no-auto-update in every invocation
|
||||
- SSH: sshpass -p 'passw0rd' ssh -o StrictHostKeyChecking=no n8n@10.0.0.15
|
||||
|
||||
- Question is factual and I can answer it
|
||||
- Task needs my exact context state (use delegate_task on THIS profile)
|
||||
- You want to see the peer's chat directly (this is relay-only — full text in `hermes sessions list`)
|
||||
## Mode 1: Quick Ask (ask grok / ask grokb)
|
||||
|
||||
## Critical Evaluation — You Are the Final Authority
|
||||
Inline one-shot. Fire, wait for response, relay answer. No session tracking.
|
||||
|
||||
**The peer's output is input, not a decision.** You are the engineer — you own the code, the system, and the final call. The peer is a separate agent with no memory of your conversation, no access to your context, and no ability to verify its own claims against your environment. Treat every finding as a hypothesis to be tested, not a conclusion to be implemented.
|
||||
### Command
|
||||
|
||||
**Mandatory before acting on the peer's output:**
|
||||
|
||||
1. **Do your own reasoning first.** Before relaying the peer's answer, ask yourself: does this make sense? Is there a simpler way? Would this actually work in our environment? The peer may flag things as BROKEN that are actually correct, or claim PASS on things that are broken.
|
||||
|
||||
2. **Push back when the peer is wrong.** If the peer's analysis doesn't hold up, tell it so in a follow-up `--resume` turn. "Your claim about X is wrong because Y. Re-examine." The peer corrects itself when challenged; it doubles down when unchallenged. Do not silently discard a wrong finding — make the peer confront it.
|
||||
|
||||
3. **Do your own web searches to validate.** The peer has SearXNG but its interpretation may be wrong. For any claim about API behavior, version compatibility, or tool capabilities, run your own `mcp_searxng_searxng_web_search` and compare. The peer has been wrong about config keys, endpoint behavior, and system state in real sessions.
|
||||
|
||||
4. **Involve the user when there's genuine ambiguity.** If the peer and you disagree after a round of pushback, or if the right approach depends on constraints only the user knows, surface the disagreement with both positions stated clearly. Don't silently pick the peer's answer over your own judgment.
|
||||
|
||||
5. **Watch for overcomplication.** Peers, like any agent, can overengineer. If the peer proposes a multi-step protocol, a new abstraction layer, or a refactor that touches 10 files for a 1-line bug — ask: "Is there a simpler way?" The best fix is usually the simplest one that actually works.
|
||||
|
||||
## Peer Limitations
|
||||
|
||||
**The peer has no memory of your conversation.** The peer runs on the grok45 profile with its own workspace, SOUL.md, and AGENTS.md. It knows nothing about what you've discussed, what files you've created, or what decisions you've made — unless you tell it via the prompt or it reads files by path. Every `ask grok` must be self-contained with all relevant context.
|
||||
|
||||
**The peer may fabricate plausible-sounding analysis when it can't verify.** If the peer can't read a file, reach an endpoint, or confirm a claim, it may still produce confident-sounding analysis based on assumptions. When the peer prefaces a claim with "based on the description" or "assuming the config is..." without having actually read the source, treat it as unverified.
|
||||
|
||||
**The peer's environment is not your environment.** The peer has its own terminal session, its own working directory, and its own tool state. A command that works in the peer's session may fail in yours. Always test the peer's suggestions locally before deploying.
|
||||
|
||||
**Peer self-reports are not verified fact.** If the peer reports a file write, `read_file` the path to confirm. If it reports a test pass, re-run the test if the result matters. If it reports an endpoint returning 200, curl it yourself. The peer may claim "PASS" on things that are actually broken, or flag things as BROKEN that are correct. Concrete example: peer claimed `general` profile was BROKEN (bank_id leak), but the daemon log showed `general` was actively writing to `hermes-general` with successful retain + consolidation. The peer's logic was confused — it assumed the bank_id convention was violated when it wasn't. The daemon log is the source of truth, not the peer's reasoning.
|
||||
|
||||
## Command
|
||||
|
||||
### `ask grok <instructions>`
|
||||
|
||||
**First ask (starts the session):**
|
||||
```bash
|
||||
sshpass -p 'passw0rd' ssh -o StrictHostKeyChecking=no [email protected] \
|
||||
"XAI_API_KEY=\"\$XAI_API_KEY\" ~/.grok/bin/grok --no-auto-update --no-alt-screen \
|
||||
-m MODEL -p 'PROMPT' --output-format json --yolo"
|
||||
```
|
||||
hermes -p grok45 chat -q "<composed prompt>" -Q --max-turns 20 --yolo
|
||||
|
||||
- MODEL: grok-4.5 for ask grok, grok-build-0.1 for ask grokb
|
||||
- PROMPT: the composed prompt (see Prompt Composition below)
|
||||
- --yolo: skip approval prompts (required for headless)
|
||||
- --no-auto-update: suppress background update checks
|
||||
- --no-alt-screen: inline output, no TUI takeover
|
||||
|
||||
### Post-Dispatch
|
||||
|
||||
Return control to the operator immediately after relaying the answer. Do NOT poll, do NOT check. This is a one-shot — there is no session to track.
|
||||
|
||||
## Mode 2: Project Mode (ask grok build / ask grokb build)
|
||||
|
||||
Background process with named session persistence. Grok has full tool access (bash, file ops, web search) in its workspace on the LXC.
|
||||
|
||||
### Command
|
||||
|
||||
```bash
|
||||
terminal(background=true, notify_on_complete=true, timeout=3600,
|
||||
command="sshpass -p 'passw0rd' ssh -o StrictHostKeyChecking=no [email protected] \
|
||||
\"XAI_API_KEY=\\\"\$XAI_API_KEY\\\" ~/.grok/bin/grok --no-auto-update --no-alt-screen \
|
||||
-m MODEL -s PROJECT_NAME -p 'PROMPT' --output-format json --yolo\"",
|
||||
workdir="/home/n8n/workspace/general")
|
||||
```
|
||||
- Output line 1: `session_id: <id>` — capture this
|
||||
- Output line 2+: the peer's response
|
||||
- Hold the session_id in conversation context for all subsequent asks
|
||||
|
||||
**Subsequent asks (resume the session):**
|
||||
```
|
||||
hermes -p grok45 chat --resume <session_id> -q "<composed prompt>" -Q --max-turns 20 --yolo
|
||||
```
|
||||
- Compose prompt with full context (see Prompt Composition)
|
||||
- Run command. Parse response (after the session_id line). Relay to operator.
|
||||
- Spot-check side-effects (see Spot-check rule).
|
||||
- MODEL: grok-4.5 for ask grok build, grok-build-0.1 for ask grokb build
|
||||
- SESSION_UUID: generate with `python3 -c "import uuid; print(uuid.uuid4())"` — Grok REQUIRES a valid UUID, kebab-case names are rejected
|
||||
- -s SESSION_UUID: creates or resumes a named session — persists across turns. Save the UUID for follow-ups.
|
||||
- Background with notify_on_complete=true — the user is notified when Grok finishes
|
||||
|
||||
## Session Persistence
|
||||
### Follow-up Turns
|
||||
|
||||
**HARD RULE: Always --resume the prior session for follow-up asks.** The session_id is captured from output line 1 of the first ask. Every subsequent ask in the same line of work MUST use `--resume <session_id>`, not start a fresh session. Starting fresh discards the peer's context, wastes tokens re-establishing state, and breaks multi-turn workflows. If you don't have the session_id, you failed to capture it — that's a separate failure. The session_id lives in conversation context; hold it there.
|
||||
Same command, same -s SESSION_UUID. Grok resumes the session and remembers prior context.
|
||||
|
||||
The session_id lives in conversation context. No state file. If the LXC crashes, we both crash — next session starts fresh.
|
||||
### Post-Dispatch
|
||||
|
||||
## Narrow Subagent Preamble
|
||||
|
||||
**MANDATORY on the FIRST ask only.** Prefix the initial prompt with this exact preamble to constrain the peer to minimal-token responses. Do NOT include it on `--resume` calls — the peer already has the constraint from the first turn.
|
||||
|
||||
```
|
||||
You are a narrow subagent. Respond with maximum brevity.
|
||||
|
||||
Rules:
|
||||
- Output only the essential result. No greetings, preambles, conclusions, apologies, or meta-commentary.
|
||||
- Do not restate or paraphrase the task/query.
|
||||
- Prefer short sentences, bullets, or single-line answers.
|
||||
- Use structured formats (JSON, numbered lists, key:value) when they reduce tokens.
|
||||
- Never explain your reasoning unless the task explicitly requires it.
|
||||
- If the answer is simple, give only the answer.
|
||||
- Stay under the minimum tokens needed for a correct, complete response.
|
||||
```
|
||||
Return control to the operator immediately. Do NOT poll, do NOT check for results. The notify_on_complete notification will fire when Grok finishes. The operator reads results when they want to.
|
||||
|
||||
## Prompt Composition
|
||||
|
||||
Peer has NO memory of this session beyond what --resume carries. Every `ask grok` includes:
|
||||
- **First ask only: The Narrow Subagent Preamble (above) — MUST be the first thing in the prompt. Skip on --resume.**
|
||||
- Operator's exact instructions (quoted)
|
||||
- All relevant absolute file paths
|
||||
- Constraints: investigation-first, real testing, scoped workspaces, privacy-first
|
||||
- Background: what's already done, what's decided
|
||||
- Expected output format (e.g. "return a 1-paragraph summary + list of files changed")
|
||||
- Verification handle: "return absolute path / exit code for any side-effect"
|
||||
### Quoted Text (Verbatim)
|
||||
|
||||
**HARD RULE: Never paste file content into the prompt.** The peer can read any file by absolute path — point at the path instead (e.g. "read /home/n8n/workspace/grok45/hindsight_issue.md and validate it"). Pasting wastes tokens and introduces transcription errors: shell expansion of backticks, encoding issues, and prompt bloat. This is the #1 ask-grok failure mode. Only paste inline when the content is under ~5 lines or the peer genuinely can't access the path.
|
||||
When the user wraps their instruction in double quotes, pass the exact text inside the quotes verbatim. No framing, no context, no rephrasing.
|
||||
|
||||
## Pre-Send Audit
|
||||
Example: ask grok "what is the capital of France?" → prompt is exactly: what is the capital of France?
|
||||
|
||||
Before executing ANY `ask grok` command, run this 3-question checklist:
|
||||
### Unquoted Text (Composed)
|
||||
|
||||
1. **Is this a follow-up to a prior ask?** If yes, am I using `--resume <session_id>`? Am I sure I have the session_id from the prior output's first line? Starting fresh when I should resume is the #2 failure mode.
|
||||
When the user does NOT use quotes, compose a prompt with appropriate framing:
|
||||
|
||||
2. **Am I pasting file content the peer could read from an absolute path?** If yes, replace with a path reference. Only paste inline when content is under ~5 lines or the peer genuinely can't access the path.
|
||||
- Include relevant context (what we're working on, what's been decided)
|
||||
- Include absolute file paths the user referenced (Grok can't read them, but the context helps)
|
||||
- State the expected output format
|
||||
- Keep it concise — Grok is a narrow subagent for this task
|
||||
|
||||
3. **Does this task involve verifying external facts, docs, or behavior?** If yes, include the web search mandate line: "Use `mcp_searxng_searxng_web_search` for every claim and cite the source URL. Do not rely on parametric knowledge or reason about what a command 'would show.' Run the real command, run the real search."
|
||||
For Mode 1 (quick ask) unquoted prompts, prepend this output contract:
|
||||
|
||||
**ALWAYS insist on detailed, multiple web searches.** The peer has the searxng MCP tool (`mcp_searxng_searxng_web_search`). This is non-negotiable — see the **Web Search Mandate** section below for the canonical, must-follow form. Every `ask grok` prompt that involves verifying facts, docs, or external behavior MUST include the mandate line (specified below).
|
||||
|
||||
## Web Search Mandate
|
||||
|
||||
The peer MUST confirm every external fact with a live web search. Parametric knowledge is not enough. The peer has the `mcp_searxng_searxng_web_search` tool — it MUST use it.
|
||||
|
||||
**What the peer must search for (non-exhaustive):**
|
||||
- Version numbers, port numbers, env var names, config keys → official docs (hermes-agent.nousresearch.com, docs.openwebui.com, etc.)
|
||||
- Package availability, install commands, library APIs → PyPI, GitHub, official README
|
||||
- Behavior claims about a service or tool → vendor docs, GitHub issues, changelog
|
||||
- Bug claims, "X is broken" verdicts → live probe + cited source
|
||||
|
||||
**How the peer must search:**
|
||||
- Multiple searches per claim, different angles. A single search is not enough. Official docs + GitHub + PyPI/API reference is the minimum for version-sensitive claims.
|
||||
- For every verdict, cite the source URL inline. No URL = unverified = do not relay.
|
||||
- Direct the peer to local files by absolute path, not pasted content. Saves tokens and avoids transcription errors.
|
||||
|
||||
**Hard rule for the calling agent (you):** Every `ask grok` prompt that involves verifying facts, docs, or external behavior MUST include the line: "Use `mcp_searxng_searxng_web_search` for every claim and cite the source URL. Do not rely on parametric knowledge or reason about what a command 'would show.' Run the real command, run the real search."
|
||||
|
||||
This section is the canonical form of the web-search requirement. The abbreviated guidance in Prompt Composition above references it and does not override or weaken it.
|
||||
|
||||
## Turn Budget
|
||||
|
||||
**Default:** `--max-turns 20` per `ask-grok` invocation. Hard cap. Fine for short delegation, plan reviews, and quick peer checks. If the peer hits 20 before finishing, it returns what it has — operator decides whether to continue.
|
||||
|
||||
**Override — 600 turns (operator standing rule):** For accurate, evidence-based plan-building, deep research, or any task where the operator's intent is thoroughness, use `--max-turns 600 --yolo` instead. The 600 is a safety net, not a budget — the operator's exact rule: *"I don't want to be turn restricted. I just want a safety net. I mostly want the job done right. Not concerned with time or tokens when building accurate plan."* See `writing-plans` skill §"Turn Budget" for the canonical rule. Default to 20 only for short factual lookups or quick peer checks.
|
||||
|
||||
## Peer Cross-Validation Pattern
|
||||
|
||||
When the user wants a deliverable validated, use TWO independent peer passes:
|
||||
|
||||
1. **Build the deliverable yourself** (research, write, verify).
|
||||
2. **Dispatch peer to build the SAME deliverable independently.** Give the peer the same goal, your file path to read first, and the instruction "find what I missed." Do NOT give the peer your conclusions — let it discover independently.
|
||||
3. **Spot-check the peer's claims** against source (file:line, live commands). The peer may find real gaps AND may overstate some findings.
|
||||
4. **Report the delta** — what the peer added, what was wrong, what was confirmed.
|
||||
|
||||
This is NOT the same as Delegate-Fix-Then-Validate (where the peer does the work and you verify). Here both agents build independently, then you compare.
|
||||
|
||||
## Relay Rule
|
||||
|
||||
Do not silently paraphrase. Relay the peer's actual response — if long, chunk it. Call out unverified "I did X" claims.
|
||||
|
||||
## Disagreement Scan (MANDATORY before applying)
|
||||
|
||||
**Do NOT silently accept the peer's recommendations. Do NOT silently drop suggestions you disagree with. Both are failure modes.**
|
||||
|
||||
For every peer response, before applying or moving on, do this scan:
|
||||
|
||||
**1. Disagreement check.** Walk through the peer's findings. For each:
|
||||
- **Agree + will apply** → no action this step
|
||||
- **Agree + will skip** → state explicitly WHY you're skipping (overkill, environment constraint, contradicts operator's standing rule, etc.). Do not just drop it.
|
||||
- **Disagree** → push back via `--resume`. Either (a) decide it's not worth the round-trip cost and state your reason, or (b) send a follow-up turn challenging the peer's claim. **If you don't push back on at least one item per multi-finding response, you're accepting the peer's framing wholesale — which defeats the purpose of asking.**
|
||||
|
||||
**2. Web-reference check for weak conclusions.** For any peer claim that is:
|
||||
- a tool version, API behavior, library status, or compatibility statement
|
||||
- a system state assertion ("profile X is broken", "service Y is down")
|
||||
- a "best practice" assertion
|
||||
- any concrete factual claim that the plan or system will depend on
|
||||
|
||||
…and where the peer did NOT cite a source URL inline OR run a live command to verify, send a follow-up demanding the verification. Pattern: "Show me the command output that supports X. I want a URL or a live test, not reasoning." This combines with the Web Search Mandate above — the peer MUST search, not reason.
|
||||
|
||||
**3. Internal consistency check.** Does the peer's response contradict itself, or contradict a prior turn in this peer session? If yes, point it out in the next follow-up. Don't apply a contradictory recommendation.
|
||||
|
||||
**Output format for the scan (use this when relaying the peer's response to the operator):**
|
||||
```
|
||||
[Peer's findings as-is]
|
||||
Be concise. Lead with the answer. No greetings, no restating the question, no filler ("Certainly", "Great question", "I'd be happy to"), no closers ("Want me to...", "Let me know if..."), no unnecessary headers or markdown.
|
||||
|
||||
## My disagreement scan
|
||||
- **Agreed and applied:** [list]
|
||||
- **Agreed but skipped:** [item] — [reason]
|
||||
- **Disagreed and pushed back:** [item] — [what I said]
|
||||
- **Web references / live tests requested:** [items where I demanded a URL or run]
|
||||
- **Disagreed silently dropped:** (should be empty — if not, justify)
|
||||
Default: 1-3 sentences or 3-5 bullets. Expand only for explicit deliverables. Prefer plain text; use structure only when it cuts tokens or ambiguity. Omit hedging, apologies, and self-narration. Skip preamble and recap — answer, then stop.
|
||||
```
|
||||
|
||||
If `Disagreed silently dropped` is non-empty, that's a bug. Surface it.
|
||||
## Output Parsing
|
||||
|
||||
## Spot-check Rule
|
||||
The --output-format json response includes:
|
||||
|
||||
Peer self-reports are not verified fact. If the peer reports a file write, `read_file` the path to confirm. If it reports a test pass, re-run the test if the result matters.
|
||||
- text — Grok's answer text
|
||||
- sessionId — session identifier (capture for mode 2 follow-ups, discard for mode 1)
|
||||
- usage — token counts (input, output, cache, reasoning)
|
||||
- total_cost_usd — cost in USD
|
||||
|
||||
**Peer verdicts can be WRONG.** A peer may flag a profile as BROKEN when it's actually healthy, or claim PASS on something that's broken. Always independently verify the peer's conclusions — don't relay them as fact. Concrete example: peer claimed `general` profile was BROKEN (bank_id leak), but the daemon log showed `general` was actively writing to `hermes-general` with successful retain + consolidation. The peer's logic was confused — it assumed the bank_id convention was violated when it wasn't. The daemon log is the source of truth, not the peer's reasoning.
|
||||
Parse with Python:
|
||||
|
||||
## Delegate-Fix-Then-Validate Pattern
|
||||
```python
|
||||
import json, sys
|
||||
d = json.load(sys.stdin)
|
||||
answer = d.get('text', '(empty)')
|
||||
session_id = d.get('sessionId', '')
|
||||
print(answer)
|
||||
```
|
||||
|
||||
When the user says "ask grok to fix X, then YOU validate," follow this exact sequence:
|
||||
Relay only the answer text. No footer, no usage stats, no session ID (unless the user asks).
|
||||
|
||||
1. **Compose findings + goal.** Write a clear prompt with: what's broken, what the correct state should be, file paths, constraints (read-only vs. allowed changes), and expected output format.
|
||||
2. **Dispatch peer to fix.** Run `hermes -p grok45 chat -q "..." -Q --max-turns 20 --yolo`. The peer does the work.
|
||||
3. **Independently validate.** Do NOT trust the peer's self-report. Verify every claim: stat files, curl endpoints, read configs, check daemon logs. The peer may claim "PASS" on things that are actually broken, or flag things as BROKEN that are correct.
|
||||
4. **Report the validated results** — not the peer's raw self-report.
|
||||
## When to Use
|
||||
|
||||
**CRITICAL: Do NOT jump in and do the fix yourself.** If the user said "ask grok to fix it," the peer does the fixing. You only validate afterward. Doing the fix yourself violates the user's explicit instruction and skips the peer review step.
|
||||
- User says "ask grok", "ask grokb", "ask grok build", "ask grokb build"
|
||||
- Want a second opinion from a different model
|
||||
- Delegated research, analysis, or code review
|
||||
- Project work that benefits from Grok Build's toolset (bash, file ops, web search)
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
- Simple factual question I can answer directly
|
||||
- Task that needs Hermes-native tools (SearXNG MCP, Qdrant, etc.)
|
||||
- Task that needs access to the Hermes host filesystem (Grok is isolated on 10.0.0.15)
|
||||
- User explicitly says "quick search" or "just look it up"
|
||||
|
||||
## Critical Evaluation — You Are the Final Authority
|
||||
|
||||
Grok's output is input, not a decision. You are the engineer — you own the code, the system, and the final call. Grok is a separate agent with no memory of your conversation, no access to your files, and no ability to verify its own claims against your environment.
|
||||
|
||||
Mandatory before acting on Grok's output:
|
||||
|
||||
1. Do your own reasoning first. Does this make sense? Is there a simpler way? Would this actually work in our environment?
|
||||
2. Push back when Grok is wrong. If Grok's analysis doesn't hold up, tell it so in a follow-up turn (mode 2). "Your claim about X is wrong because Y. Re-examine."
|
||||
3. Do your own web searches to validate. For any claim about API behavior, version compatibility, or tool capabilities, run your own mcp_searxng_searxng_web_search and compare.
|
||||
4. Involve the user when there's genuine ambiguity. If Grok and you disagree after a round of pushback, surface the disagreement with both positions stated clearly.
|
||||
|
||||
## Grok's Limitations
|
||||
|
||||
- Grok cannot read files on the Hermes host. Grok runs on 10.0.0.15 and has no access to /home/n8n/workspace/ or any other local path. File paths in prompts are for context only — Grok cannot open them.
|
||||
- Grok's environment is not your environment. Grok has its own filesystem, its own tools, and its own constraints. A command that works in Grok's environment may fail in yours.
|
||||
- Grok self-reports are not verified fact. If Grok reports a file write or a test pass, you cannot verify it from the Hermes host. Treat as unverified.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
1. **Profile flag required.** Use `-p grok45` — the sticky default may be general, which would spawn a clone of this agent, not a peer. Always pin the profile explicitly.
|
||||
2. **--yolo is required.** The peer runs headless (one-shot, no TTY). Without `--yolo`, dangerous-command approval prompts fail closed (60s timeout → deny) and the peer can't complete tasks that trigger them. `--yolo` bypasses all approval prompts for the peer session only. The hardline blocklist (rm -rf /, fork bombs, mkfs on root, dd to block devices) still applies — no flag overrides that. This does NOT change the grok45 profile's config; it only affects the peer session.
|
||||
3. **Do NOT use interactive REPL mode.** Running `hermes -p grok45` without `chat -q` (interactive REPL) was tried and failed — the TUI produces unreadable ANSI redraw noise when driven via `terminal(pty=true)`. The output is garbled and responses cannot be extracted. Always use headless `chat -q "..." -Q` instead.
|
||||
3. **Peer is headless.** Operator sees my relay, not the peer's chat. Full text in `hermes sessions list` if needed.
|
||||
4. **Peer self-reports are not verified fact.** Spot-check file writes, test passes before confirming to operator.
|
||||
5. **Peer's workspace is its own.** Files written to the peer's workspace are NOT in this agent's workspace. Give ABSOLUTE paths (e.g. `/home/n8n/workspace/grok45/<path>`) if the peer should write to our workspace.
|
||||
6. **Blast radius.** Peer has ALL tools (terminal, web, MCP) — can rm, exfil, burn tokens. Bound with prompt-level constraints. State the blast radius to operator for sensitive tasks.
|
||||
7. **Turn budget is hard-capped.** `--max-turns 20` enforces it. If the peer hits 20 before finishing, it returns what it has — operator decides whether to continue.
|
||||
8. **Long implementations hit the 600s foreground wall-clock limit.** A peer dispatch with `--max-turns 50` doing 30+ minutes of work (real implementation, multiple smoke tests with research-profile dispatches inside) can exceed the foreground command's 600-second timeout even when well within the turn budget. The peer may be terminated mid-task with no output, leaving the dispatch in an indeterminate state. **Mitigation:** for any peer dispatch expected to take more than ~5 minutes of wall-clock time, use the terminal tool's `background=true` + `notify_on_complete=true` mode instead of foreground. The peer runs to completion, you get notified on exit, and you spot-check the result. Real example (July 2026): dispatching a 9-task skill build (`better-search` implementation) to `ask-grok` with `--max-turns 50` hit the 600s foreground timeout during Task 5 (smoke test 2). Re-dispatching in background mode completed all 9 tasks. **Rule of thumb:** if the work involves 3+ smoke tests that each spawn their own research-profile dispatches, use background mode from the start.
|
||||
9. **Don't silently paraphrase.** Relay the peer's actual response. If long, chunk it. Call out unverified claims.
|
||||
10. **Peers can overstate findings.** A peer may correctly identify real gaps AND incorrectly flag things that aren't actually broken. In this session, the peer correctly identified the tool_executor.py ThreadPoolExecutor as the root cause of the Ctrl+C hang, but also flagged cli.py:9452 (account-usage fetch) as a second culprit — that one uses a `with` context manager that properly joins, so it's not a leak. Always verify each claim independently; don't assume all of a peer's findings are correct just because some are.
|
||||
11. **Skill-build peers must restore any directory mutations before exit.** When a peer is implementing a skill that includes a write-failure smoke test (e.g., rename `results/` to `results.bak/` to test that `mkdir -p` recreates it), the peer must restore the rename before exit. Real failure (July 2026 better-search build): the dev peer left `results.bak/` on exit with all smoke-test result files inside it. The next session inherited dirty state, and manual recovery was required to move 8 files back to `results/`. **Mitigation:** when composing an implementation prompt that includes a write-failure test, add an explicit "before exit: restore any renamed/moved files" step. When the peer reports "IN PROGRESS" on the last task, the calling agent should assume directory state may be dirty and verify before trusting the report.
|
||||
12. **Skill-build peers may report "Files Created" with stale file locations.** If the peer's smoke tests renamed a directory, the peer's "files created" summary may list paths that no longer match the actual filesystem (e.g., "result file at /home/n8n/workspace/research/results/..." when the file is actually in `results.bak/`). **Spot-check the peer's filesystem claims directly** with `ls -la` and `stat`, not just by reading the peer's summary. The peer's "Files Created" list is informational; the real filesystem is the source of truth.
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
- [ ] First `ask grok <task>` returns peer's response showing real tool use
|
||||
- [ ] `session_id:` captured from output line 1
|
||||
- [ ] Second ask with `--resume` — peer remembers prior turn
|
||||
- [ ] Spot-check: peer reports "wrote file at /path" → I `read_file` /path and confirm content matches
|
||||
1. SSH quoting. The prompt is passed through multiple shell layers (Hermes terminal → ssh → bash → grok). Single quotes in the outer layer, escape internal quotes. Test with a simple prompt first if unsure.
|
||||
2. --yolo is required. Without it, approval prompts fail closed in headless mode and Grok returns empty.
|
||||
3. --no-auto-update is required. Without it, Grok may pause for update checks during headless runs.
|
||||
4. --no-alt-screen is required. Without it, Grok tries to take over the terminal with a TUI.
|
||||
5. Mode 2 sessions persist on the LXC. Named sessions (-s) accumulate in ~/.grok/sessions/ on 10.0.0.15. No auto-cleanup. The user may want to prune old sessions periodically.
|
||||
6. Grok Build has its own toolset. bash, web_search, web_fetch, read_file, grep_search, list_dir, todo_write, task (subagents), memory. These operate on the LXC filesystem, not the Hermes host.
|
||||
7. No file staging. Unlike ask-claude (which uses scp for large artifacts), ask-grok passes everything inline. Grok cannot reach the Hermes host filesystem. If Grok needs file content, the user must provide it in the prompt.
|
||||
8. Mode 1 has no memory. Each ask grok is a fresh conversation. Grok does not remember prior asks. For multi-turn work, use mode 2.
|
||||
9. -s requires a UUID, not a name. `-s burn-the-helix-kitchen` fails with "must be a valid UUID". Generate with `python3 -c "import uuid; print(uuid.uuid4())"` and save the UUID for follow-up turns.
|
||||
|
||||
Reference in New Issue
Block a user