consult-zai

Dual-AI Consultation: z.ai GLM 5.2 vs Code-Searcher

You orchestrate consultation between z.ai's GLM 5.2 model and Claude's code-searcher to provide comprehensive analysis with comparison.

When to Use This Skill

High value queries:

• Complex code analysis requiring multiple perspectives
• Debugging difficult issues
• Architecture/design questions
• Code review requests
• Finding specific implementations across a codebase

Lower value (single AI may suffice):

• Simple syntax questions
• Basic file lookups
• Straightforward documentation queries

Workflow

When the user asks a code question:

1. Build Enhanced Prompt

Problem-restate pre-flight (non-blocking). Before building the prompt, emit ONE line restating the code question you are about to dispatch (and, only if genuinely ambiguous, the alternative reading), then proceed:

Reading this as: «one-line restatement» (alt: «other reading», if any) — proceeding to consult; interrupt now to correct the framing.

Emit-and-proceed — do not ask-and-wait (the orchestrator can't reliably detect its own misframing). One line, and it guards the whole dispatch against a wrong-framing run.

Wrap the user's question with structured output requirements:

[USER_QUESTION]

=== Analysis Guidelines ===

**Structure your response with:**
1. **Summary:** 2-3 sentence overview
2. **Key Findings:** bullet points of discoveries
3. **Evidence:** file paths with line numbers (format: `file:line` or `file:start-end`)
4. **Confidence:** High/Medium/Low with reasoning
5. **Limitations:** what couldn't be determined

**Line Number Requirements:**
- ALWAYS include specific line numbers when referencing code
- Use format: `path/to/file.ext:42` or `path/to/file.ext:42-58`
- For multiple references: list each on a SEPARATE line with its own file path
  (avoid comma-separated multi-citation like `file.ts:45, 67, 98`)
- Include brief code snippets for key findings

**Examples of good citations:**
- "The authentication check at `src/auth/validate.ts:127-134`"
- "Configuration loaded from `config/settings.json:15`"
- "Error handling in `lib/errors.ts:45`, `lib/errors.ts:67-72`, and `lib/errors.ts:98`"

**Citations Index (required):** end your response with a fenced block, one line per
Key Finding (repeat each block entry's `file:line` inline in the finding as usual):
```citations
<finding #> — path/to/file.ext:LINE[-END]
```

Severity / no-manufacture block — ORCHESTRATOR-GATED. Append the block below to both agents' prompts identically ONLY when the query is a defect hunt / code review (bug, security audit, "what's wrong with…", "review this"). OMIT it for explanatory / "how does X work" questions, where "found nothing" is not meaningful. The orchestrator — which knows the query type — makes this include/omit decision once, BEFORE writing the prompt files; do not leave it to each agent to self-classify. When included, append exactly these two bullets (the text only — no leading marker):

- Tag each finding with a **Severity** — Critical (wrong/broken on expected inputs) · Warning (fails on unusual but valid inputs) · Info (noteworthy, not actionable). Severity is *impact*, orthogonal to the Confidence field (*certainty*).
- **Finding nothing is a valid, valuable result.** If the code is correct, say so plainly with one verifying note — do NOT manufacture issues to look thorough.

2. Invoke Both Analyses in Parallel

Setup (run first). $CLAUDE_PROJECT_DIR is not always exported into the Bash tool shell, so resolve it with a $PWD fallback and ensure the tmp dir exists. Substitute the resolved literal path for $PROJECT_DIR, and a freshly generated RUN_ID (seconds-resolution + 4-char nonce, e.g. run-2026-07-04-143052-a7f3), into every command below. The RUN_ID in temp filenames prevents collisions between two concurrent invocations sharing $PROJECT_DIR/tmp.

PROJECT_DIR="${CLAUDE_PROJECT_DIR:-$PWD}"
# Validate BEFORE creating tmp — `mkdir -p` would otherwise make the check pass even
# for a bad path (it creates the dir, then `[ -d ]` always succeeds).
[ -d "$PROJECT_DIR" ] || { echo "ERROR: PROJECT_DIR '$PROJECT_DIR' is not a directory" >&2; exit 1; }
mkdir -p "$PROJECT_DIR/tmp"

# Pre-flight (fail fast, not after a 20-min hang). jq is a HARD dependency — the §2a
# parse recipe needs it — so abort now rather than warn-and-continue into opaque failures.
command -v jq >/dev/null 2>&1 || { echo "ERROR: 'jq' not found — required for output parsing; aborting" >&2; exit 1; }
# zai is a soft dependency (a shell function wrapping the claude CLI against z.ai's
# endpoint, loaded from ~/.zshrc or ~/.bashrc — hence the interactive-shell probes).
# Capture WHICH interactive shell resolves it; the dispatch below substitutes
# $INTERACTIVE_SHELL so a .bashrc-only setup on macOS still works. If neither shell
# resolves zai, skip its dispatch and label the run degraded (see §2 dispatch + §4).
ZAI_AVAIL=1; INTERACTIVE_SHELL=zsh
if   zsh  -i -c 'type zai' >/dev/null 2>&1; then ZAI_AVAIL=0; INTERACTIVE_SHELL=zsh
elif bash -i -c 'type zai' >/dev/null 2>&1; then ZAI_AVAIL=0; INTERACTIVE_SHELL=bash
else echo "WARNING: 'zai' not found in zsh or bash interactive shells — z.ai will be skipped"
fi
echo "ZAI_AVAIL=$ZAI_AVAIL"                   # MUST echo: shell vars don't persist across Bash tool calls
echo "INTERACTIVE_SHELL=$INTERACTIVE_SHELL"   # substitute into the Step-2 dispatch below

# Sweep stale orphans (>60 min) from crashed prior runs (best-effort, age-based —
# can theoretically delete a live run's files if it paused >60 min; acceptable).
find "$PROJECT_DIR/tmp" -maxdepth 1 -name 'zai-prompt-*.txt'  -mmin +60 -delete 2>/dev/null
find "$PROJECT_DIR/tmp" -maxdepth 1 -name 'zai-output-*.json' -mmin +60 -delete 2>/dev/null
find "$PROJECT_DIR/tmp" -maxdepth 1 -name 'zai-stderr-*.log'  -mmin +60 -delete 2>/dev/null

# Resolve the timeout binary used to wrap the Step-2 z.ai dispatch so a hung CLI is
# bounded rather than running unbounded — the harness may auto-background the dispatch,
# letting it escape the Bash tool's own timeout. Homebrew coreutils installs GNU
# timeout as `gtimeout`; plain `timeout` exists only when the gnubin PATH is on. If
# neither exists, TIMEOUT_CMD stays empty → dispatch UNWRAPPED (best-effort;
# `brew install coreutils` restores the hard guard).
TIMEOUT_CMD=""
if   command -v timeout  >/dev/null 2>&1; then TIMEOUT_CMD="timeout"
elif command -v gtimeout >/dev/null 2>&1; then TIMEOUT_CMD="gtimeout"
fi
echo "TIMEOUT_CMD=$TIMEOUT_CMD"   # substitute into the Step-2 dispatch (when empty: omit the wrap)

Two-phase dispatch (required). Tool calls in one message run concurrently, so emitting the z.ai prompt-file Write and the z.ai dispatch together races the dispatch ahead of the file existing (the cat pipes an empty/missing file). Use two messages: message 1 writes the z.ai prompt file (Step 1 below); message 2 issues the z.ai dispatch (Step 2) and the Code-Searcher Agent call in parallel.

Gen-dispatch timeout watchdog (GEN_TIMEOUT=1200). The z.ai dispatch is wrapped in $TIMEOUT_CMD -k 10 1200 (resolved in Setup) — SIGTERM at 1200s (20 min), SIGKILL 10s later (-k 10, reaps orphaned Node/MCP children). This bounds a hung z.ai CLI that could otherwise run unbounded (the harness may auto-background the dispatch, so the Bash tool's own timeout is not a reliable cap). When TIMEOUT_CMD is empty: omit the $TIMEOUT_CMD -k 10 1200 prefix and dispatch unwrapped — set the Bash tool's own timeout parameter to 1300000 ms as a best-effort cap, and brew install coreutils to restore the hard guard. On a timed-out dispatch (exit 124 = SIGTERM, 137 = SIGKILL): the output file is empty/truncated, so the §2a [ -z … ] parse guard drops the agent — treat z.ai as failed per §4 (present Code-Searcher's response and note the timeout; do NOT retry). Code-Searcher (Agent tool) is not wrapped — it bounds itself.

• For z.ai GLM 5.2:

  Step 1: Write the enhanced prompt to a temp file using the Write tool:

  Write to $PROJECT_DIR/tmp/zai-prompt-RUN_ID.txt with the ENHANCED_PROMPT content
  

  Step 2: Execute z.ai (skip if Setup echoed ZAI_AVAIL=1 — no working zai; present only the Code-Searcher response and label the report a degraded single-AI run: no cross-comparison, and note a direct Read or lighter path would have been cheaper). Pipe the prompt via stdin and capture output/stderr to files ($INTERACTIVE_SHELL = the zsh|bash literal resolved in Setup):

  cat "$PROJECT_DIR/tmp/zai-prompt-RUN_ID.txt" | \
    $TIMEOUT_CMD -k 10 1200 $INTERACTIVE_SHELL -i -c "zai --bare --print --output-format json --model 'glm-5.2[1m]' --allowedTools 'Read,Grep,Glob' --disallowedTools 'Bash,Edit,Write,NotebookEdit,WebFetch,WebSearch,Task,KillShell,BashOutput' --add-dir '$PROJECT_DIR'" \
    > "$PROJECT_DIR/tmp/zai-output-RUN_ID.json" \
    2> "$PROJECT_DIR/tmp/zai-stderr-RUN_ID.log"
  

  Why this exact form (each piece prevents a failure seen in practice):

  • --bare is required — zai exports ANTHROPIC_AUTH_TOKEN; without --bare the parent session's OAuth token shadows it → 401 against the z.ai endpoint.
  • --model 'glm-5.2[1m]' is required — guarantees GLM 5.2 regardless of which tier default resolution would pick (guards against the glm-5-turbo subagent default).
  • Read-only enforcement = --allowedTools 'Read,Grep,Glob' plus the load-bearing --disallowedTools 'Bash,Edit,Write,NotebookEdit,WebFetch,WebSearch,Task,KillShell,BashOutput' — --allowedTools only auto-approves and does NOT deny unlisted tools, so a global ~/.claude/settings.json allow-list would otherwise re-permit write-capable Bash on the --bare path (verified 2026-07-18); consultation is analysis, never modification. Freeze the reviewed tree while agents run: you, the orchestrator, must not edit, `git ch

Content truncated.