MCP HubMCP Hub
Retour aux compétences

conduct-empirical-wire-capture

pjt222
Mis à jour Yesterday
3 vues
17
2
17
Voir sur GitHub
Designdesign

À propos

Cette compétence capte les données d'exécution HTTP et de télémétrie des outils CLI via plusieurs canaux tels que les fichiers de transcription ou les proxies, en produisant un format JSONL adapté aux comparaisons. Elle aide les développeurs à confirmer les résultats d'analyse statique, à obtenir les structures de charge utile pour une réimplémentation, ou à clarifier le comportement réseau réel. Les fonctionnalités principales incluent une table d'observabilité associant les cibles à la méthode de capture la plus efficace, ainsi que la prise en charge de la capture par événement et par session.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add pjt222/agent-almanac -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternatif
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/conduct-empirical-wire-capture

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

Conduct Empirical Wire Capture

Set up reproducible wire-capture harness for CLI tool outbound HTTP and telemetry. Match each observability target to cheapest channel that captures it.

Scope and Ethics

Read this before configuring any capture.

  • Wire capture is for your own requests against your own account, on your own machine. Capturing other users' traffic is exfiltration, not research, out of scope.
  • Credentials almost always appear in raw wire output. Redact at capture time (Step 6) — never "capture now, redact later."
  • Capture is observation, not modification. Do not use captured payloads to bypass server-side rate limits, replay another user session, or activate dark-launched capability without authorization.
  • Output of this skill is internal artifact. Public publication of wire findings goes through redact-for-public-disclosure (Phase 5 of parent guide), not this skill.

When Use

  • Static finding (flag, endpoint reference, telemetry-event name) needs runtime confirmation it actually fires.
  • Payload shape needed for client re-implementation, tracing instrumentation, or cross-version diff.
  • Dark-vs-live disambiguation requires watching what binary actually sends, not what bundle suggests it might.
  • Behavior changed silently between versions, want reproducible artifact to compare against future versions.

Do not use this skill for: version baselining (use monitor-binary-version-baselines), flag-state probing (use probe-feature-flag-state), or preparing redacted artifacts for public publication (use redact-for-public-disclosure).

Inputs

  • Required: CLI harness binary you can run locally against your own account.
  • Required: Specific question to answer (e.g., "does endpoint X fire on event Y?", "what is payload shape for telemetry event Z?"). Capture without a question produces log nobody reads.
  • Optional: Static findings from prior phases (marker catalog, candidate flag list, suspected endpoints) that scope capture targets.
  • Optional: Private workspace path for capture artifacts. Default is ./captures/ — must be in .gitignore.

Steps

Step 1: Build Observability Table First

Before configuring any capture, enumerate questions you need to answer and map each to capture channel. One row per target.

targetobservable viablocker
Outbound HTTP to endpoint Xverbose-fetch stderrTUI noise pollutes terminal
Telemetry event Y on user actionhook-driven subprocessrequires harness hook surface
Token-refresh handshakeoutbound HTTP proxycert trust required
Scheduled-task lifecycle eventlong-running session capturewallclock alignment
Local config mutationon-disk state diffnone — cheapest channel

Common channels, cheapest first:

  • On-disk state file mutation — harness writes its state to known path? diff between snapshots is free.
  • Transcript file — harness already writes session transcript? Parse directly. No instrumentation.
  • Verbose-fetch stderr — bundler-provided env var (e.g., bun's BUN_CONFIG_VERBOSE_FETCH=curl) routes every fetch to stderr. Noisy but captures every fetch.
  • Hook-driven subprocess — harness exposes lifecycle hooks (UserPromptSubmit, Stop, etc.)? Spawn short capture subprocess per event.
  • Long-running session capture — one process across session, wallclock-tagged. Use for sequences.
  • Outbound HTTP proxy — clean separation, but requires CA cert trust and breaks when harness pins certificates.

Pick cheapest channel that captures target. 3-target capture that answers one specific question beats 20-target capture that answers none.

Got: Observability table with one row per question, each annotated with channel, known blockers. Targets without viable channel flagged "out of scope this session."

If fail: Every target lands in proxy column? Table too ambitious. Trim to one or two highest-value questions, revisit lower-cost channels for them.

Step 2: Prepare Disposable Workspace

Wire capture pollutes terminals, leaves files in unexpected places, may leak credentials into logs.

mkdir -p captures/$(date -u +%Y-%m-%dT%H-%M-%S)
cd captures/$(date -u +%Y-%m-%dT%H-%M-%S)
echo 'captures/' >> ../../.gitignore
git check-ignore captures/ || echo "WARNING: captures/ not git-ignored"

Confirm capture session not your primary working session — verbose-fetch and TUI rendering interfere with each other.

Got: Timestamped capture directory, git-ignored, separate from working session.

If fail: git check-ignore reports directory as not ignored? Fix .gitignore before running any capture command. Do not proceed with credentials at risk.

Step 3: Hook-Driven Capture for Per-Event Targets

Target is discrete event (tool invocation, prompt submission, session stop)? Use harness hook surface. Spawn short-lived capture subprocess per event; do not sit in-process.

Pattern (synthetic example):

# Hook script, registered with the harness's hook config.
# Invoked once per event; writes one JSONL line; exits.
#!/usr/bin/env bash
set -euo pipefail
TS=$(date -u +%Y-%m-%dT%H:%M:%S.%3NZ)
EVENT="${1:-unknown}"
PAYLOAD=$(jq -c --arg ts "$TS" --arg ev "$EVENT" \
  '{ts:$ts, source:"hook", target:$ev, payload:.}' < /dev/stdin)
echo "$PAYLOAD" >> "$CAPTURE_DIR/events.jsonl"

Why subprocess-per-event:

  • No token state, no session coupling — each invocation independent.
  • Failure of one capture does not contaminate next.
  • Subprocess overhead acceptable because events rare (per-user-action, not per-byte).

Got: One JSONL line per fired event in events.jsonl, each well-formed JSON parseable with jq.

If fail: jq reports parse errors? Payload contains unescaped control chars or binary data — pipe through jq -R (raw input), base64-encode payload field instead.

Step 4: Long-Running Session Capture for Sequential State

Target is sequence (multi-turn handshake, scheduled-task lifecycle, retry/backoff state machine)? One capture process across session, wallclock-tagged.

# Run the harness with verbose-fetch routed to a tee-d log.
BUN_CONFIG_VERBOSE_FETCH=curl harness-cli run-task 2> >(
  while IFS= read -r line; do
    printf '%s\t%s\n' "$(date -u +%Y-%m-%dT%H:%M:%S.%3NZ)" "$line"
  done >> "$CAPTURE_DIR/session.tsv"
)

Wallclock prefix makes ordering unambiguous when multiple captures run concurrently. TSV (tab-separated) is intentional — survives shells that mangle JSON quoting on stderr.

Convert TSV to JSONL after session ends (Step 5), not during.

Got: TSV log with monotonically increasing timestamps, one stderr line per row.

If fail: Timestamps go backwards? Harness is buffering stderr — re-run with stdbuf -oL -eL or bundler equivalent line-buffer flag.

Step 5: Normalize to JSONL

JSONL is artifact format: one JSON object per line, fields timestamp, source, target, payload. Diff-friendly, jq-filterable, stable across editor reloads.

# Parse the TSV from Step 4 into JSONL.
awk -F'\t' '{
  printf "{\"timestamp\":\"%s\",\"source\":\"verbose-fetch\",\"target\":\"%s\",\"payload\":%s}\n",
    $1, "session", $2
}' < session.tsv | jq -c . > session.jsonl

Validate every line parses:

while IFS= read -r line; do
  echo "$line" | jq -e . > /dev/null || echo "BAD LINE: $line"
done < session.jsonl

Typical filter usage:

# Show only requests to a specific endpoint pattern.
jq -c 'select(.payload | tostring | test("/api/v1/example"))' session.jsonl

# Show timing between consecutive captures.
jq -r '.timestamp' session.jsonl | sort | uniq -c

Got: Every line of *.jsonl parses with jq -e .; no BAD LINE warnings.

If fail: Some lines fail validation? Source TSV had embedded tabs in payload — re-run Step 4 with different delimiter or base64-encode second field.

Step 6: Redact at Capture Time

Strip auth headers, session IDs, bearer tokens, PII before writing to disk. events.jsonl and session.jsonl files should not, on first write, contain a single secret.

# Stream the raw capture through a redactor before persisting.
redact() {
  sed -E \
    -e 's/(authorization:[[:space:]]*Bearer[[:space:]]+)[A-Za-z0-9._-]+/\1<REDACTED>/gi' \
    -e 's/(x-api-key:[[:space:]]*)[A-Za-z0-9._-]+/\1<REDACTED>/gi' \
    -e 's/(cookie:[[:space:]]*)[^;]+/\1<REDACTED>/gi' \
    -e 's/("password"[[:space:]]*:[[:space:]]*)"[^"]*"/\1"<REDACTED>"/g' \
    -e 's/("token"[[:space:]]*:[[:space:]]*)"[^"]*"/\1"<REDACTED>"/g'
}

cat raw-capture.txt | redact > session.tsv

After capture, verify nothing slipped through:

# Patterns that must not appear in any *.jsonl file.
grep -Ei 'bearer [A-Za-z0-9]{20,}|sk-[A-Za-z0-9]{20,}|ghp_[A-Za-z0-9]{20,}' captures/ \
  && { echo "LEAK DETECTED"; exit 1; } \
  || echo "redaction clean"

captured-then-redacted artifact always leaks something. Only safe pattern is redacted-as-captured. Discover unredacted token in finalized artifact? Treat entire capture as compromised — delete it, rotate credential, re-run.

Got: LEAK DETECTED check exits 0 (no matches). grep for known credential prefixes returns nothing.

If fail: Leak check finds hit? Do not edit file in place. Delete entire capture directory, extend redactor regex to cover leaked pattern category, re-run from Step 3 or 4.

Step 7: Classify Response Categories Before Recording

HTTP status codes carry different semantic weight in different contexts. Classify before recording so downstream jq filters operate on intent, not raw codes.

Observed statusChannel contextClassification
200 / 201Anysuccess
401 on token-refresh endpointHandshakeexpected handshake step
401 on data endpointAfter authauth failure (real)
404 on lazy-loaded resourceFirst fetchexpected miss
404 on documented endpointAfter feature gategate-induced absence
429Anyrate-limit (back off; do not retry tight)
5xxAnyserver failure (record, do not assume)

Add class field at capture time:

jq -c '. + {class: (
  if (.payload.status == 401 and (.target | test("token|refresh"))) then "handshake"
  elif (.payload.status >= 200 and .payload.status < 300) then "success"
  elif (.payload.status == 401) then "auth-fail"
  elif (.payload.status == 429) then "rate-limit"
  elif (.payload.status >= 500) then "server-fail"
  else "other" end)}' session.jsonl > session.classified.jsonl

A 401 on token-refresh channel is not failure — it is first half of handshake. Misclassifying handshake steps as failures produces false-positive findings that waste reviewer attention.

Got: Every line in *.classified.jsonl has class field with known value.

If fail: Classification produces many other entries? Table above incomplete for this harness — extend with one row per recurring other pattern before continuing analysis.

Step 8: Persist the Capture Manifest

Capture run reproducible only if inputs recorded alongside outputs. Write manifest:

cat > capture-manifest.json <<EOF
{
  "captured_at": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
  "harness_version": "$(harness-cli --version 2>/dev/null || echo unknown)",
  "channel": "verbose-fetch",
  "question": "Does endpoint X fire on event Y?",
  "targets": ["endpoint-X", "event-Y"],
  "files": ["session.jsonl", "session.classified.jsonl"],
  "redaction_check": "passed"
}
EOF

Manifest is what makes capture diff-able against future versions.

Got: capture-manifest.json exists, parses with jq, lists every artifact file in capture directory.

If fail: Harness has no version flag? Record binary sha256sum instead. Unidentified binary produces uncomparable captures.

Checks

  • Observability table built before any capture command was run
  • Capture directory is git-ignored and timestamped
  • Every *.jsonl file parses with jq -e . line-by-line
  • Redaction leak-check returns no matches for known credential prefixes
  • Each captured event has class field with known value
  • capture-manifest.json records harness version (or sha256), channel, question
  • Capture directory contains only targets enumerated in Step 1 (no incidental traffic from other apps)

Pitfalls

  • Capture-first, question-later: Log nobody reads is wasted disk and wasted attention. Build observability table first; capture only what answers specific question.
  • Reaching for mitmproxy first: Outbound proxy is most invasive channel. Requires cert trust, breaks on certificate pinning, pollutes harness environment. Use it only when on-disk, transcript, verbose-fetch, and hook channels all blocked.
  • Capturing in your primary working session: Verbose-fetch stderr bleeds into TUI rendering and can leak fragments of your other work into capture. Always use disposable shell.
  • "We'll redact later": Every captured-then-redacted artifact has leaked a credential at least once. Redact at capture time or do not capture.
  • Treating 4xx as failure uniformly: 401 on token-refresh channel is handshake step, not failure. Classify response categories per channel context (Step 7) before drawing conclusions.
  • Long-running capture for per-event targets: Session-long process to capture three discrete events couples token state across captures, makes one bad event poison next. Use hook-driven subprocesses for events; reserve session capture for sequences.
  • No manifest: JSONL file without capture-manifest.json is not reproducible — cannot diff against next month's binary if you do not know which version produced it.
  • Capturing other users' traffic: Out of scope. Wire capture is for your own account on your own machine. Capture incidentally records another user request? Delete capture, tighten channel.

See Also

  • monitor-binary-version-baselines — Phase 1 of parent methodology; produces version baseline this skill manifest references.
  • probe-feature-flag-state — Phases 2-3; wire capture is one of its evidence prongs, this skill teaches capture half.
  • instrument-distributed-tracing — shares JSONL-over-wallclock philosophy; applied here to single binary instead of service mesh.
  • redact-for-public-disclosure — Phase 5; this skill only covers capture-time redaction for internal use, not publication-bar redaction needed before any capture leaves a private workspace.

Dépôt GitHub

pjt222/agent-almanac
Chemin: i18n/caveman/skills/conduct-empirical-wire-capture
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Compétences associées

executing-plans

Design

Utilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.

Voir la compétence

requesting-code-review

Design

Cette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.

Voir la compétence

connect-mcp-server

Design

Cette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.

Voir la compétence

web-cli-teleport

Design

Cette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.

Voir la compétence