hermes-skills/ask-g/SKILL.md

name, description, version, author, license, platforms, metadata

name	description	version	author	license	platforms	metadata
ask-g	Persistent peer Hermes agent for delegated work on the grok43 profile (xAI Grok 4.3). `ask g <instructions>` delegates a task with full context via headless one-shot commands. Session persists across all turns in one Hermes session via --resume.	1.0.0	Hermes Agent	MIT	linux	hermes tags related_skills hermes peer delegation parallel review validation grok xai ask-g ask-grok ask-claude ask-deep hermes-agent

ask-g — Peer Hermes Agent for Delegated Work (xAI Grok 4.3 Profile)

Overview

A persistent peer Hermes agent session for delegated work. The peer runs on the grok43 profile (hermes -p grok43) — a separate agent instance with its own workspace, 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.

Each ask g 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.

When to Use

• 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
• Faster/cheaper alternative to Grok 4.5 — good for routine tasks

When NOT to Use

• 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)
• Heavy reasoning or complex coding — use ask-grok (Grok 4.5) instead

Critical Evaluation — You Are the Final Authority

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.

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?

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

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.

4. Involve the user when there's genuine ambiguity. If the peer and you disagree after a round of pushback, surface the disagreement with both positions stated clearly.

5. Watch for overcomplication. Peers, like any agent, can overengineer. If the peer proposes a multi-step protocol for a 1-line bug — ask: "Is there a simpler way?"

Peer Limitations

The peer has no memory of your conversation. The peer runs on the grok43 profile with its own workspace 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 g 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.

Command

ask g <instructions>

First ask (starts the session):

hermes -p grok43 chat -q "<composed prompt>" -Q --max-turns 4000 --yolo

• 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 grok43 chat --resume <session_id> -q "<composed prompt>" -Q --max-turns 4000 --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).

Session Persistence

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.

Prompt Composition

Peer has NO memory of this session beyond what --resume carries. Every ask g includes:

• 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"

HARD RULE: Never paste file content into the prompt. The peer can read any file by absolute path — point at the path instead. Pasting wastes tokens and introduces transcription errors. Only paste inline when the content is under ~5 lines or the peer genuinely can't access the path.

Pre-Send Audit

Before executing ANY ask g command, run this 3-question checklist:

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?

2. Am I pasting file content the peer could read from an absolute path? If yes, replace with a path reference.

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

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
• 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.
• For every verdict, cite the source URL inline. No URL = unverified = do not relay.

Hard rule for the calling agent (you): Every ask g 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."

Turn Budget

Default: --max-turns 4000 per ask-g invocation. Hard cap. Fine for short delegation, plan reviews, and quick peer checks.

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 4000 --yolo instead. The 600 is a safety net, not a budget.

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.

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
• Disagree → push back via --resume

2. Web-reference check for weak conclusions. For any peer claim about tool versions, API behavior, system state, or "best practices" where the peer did NOT cite a source URL or run a live command — demand verification.

3. Internal consistency check. Does the peer's response contradict itself, or contradict a prior turn in this peer session?

Output format for the scan:

[Peer's findings as-is]

## 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]
- **Disagreed silently dropped:** (should be empty — if not, justify)

Spot-check Rule

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.

Common Pitfalls

1. Profile flag required. Use -p grok43 — 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.
3. Do NOT use interactive REPL mode. Running hermes -p grok43 without chat -q (interactive REPL) produces unreadable ANSI redraw noise. Always use headless chat -q "..." -Q instead.
4. Peer is headless. Operator sees my relay, not the peer's chat. Full text in hermes sessions list if needed.
5. Peer self-reports are not verified fact. Spot-check file writes, test passes before confirming to operator.
6. 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/grok43/<path>) if the peer should write to our workspace.
7. Blast radius. Peer has ALL tools (terminal, web, MCP) — can rm, exfil, burn tokens. Bound with prompt-level constraints.
8. Turn budget is hard-capped. --max-turns 4000 enforces it. If the peer hits the turn limit before finishing, it returns what it has — operator decides whether to continue.
9. Long implementations hit the 600s foreground wall-clock limit. 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.
10. Don't silently paraphrase. Relay the peer's actual response. If long, chunk it. Call out unverified claims.
11. Peers can overstate findings. A peer may correctly identify real gaps AND incorrectly flag things that aren't actually broken. Always verify each claim independently.

Verification Checklist

• First ask g <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