local-analysis-offload

name

local-analysis-offload

description

Plan privacy-first local AI/model and deterministic-tool offload for expensive elder-care casework analysis. Use for local LLMs/VLMs such as Qwen, GLM, Gemma-class models, LM Studio/lms with OpenAI-compatible API or LM Studio API, Goose CLI, Ollama, llama.cpp, vLLM, local image analysis, OCR, ffmpeg media prep, Whisper, Parakeet, diarization, transcript enrichment, PDF/table extraction, and batch prompt planning. Defaults to plan-only until the user explicitly approves running jobs.

Local Analysis Offload

Use this skill when a task is expensive, repetitive, privacy-sensitive, or benefits from local deterministic tools and local models before the main agent performs final reasoning.

Examples:

• Transcribe or diarize plan-of-care meeting audio with Parakeet / Whisper.
• Use a local Qwen / GLM / Gemma-class model through LM Studio, Goose, Ollama, llama.cpp, vLLM, or another user-controlled runtime for first-pass transcript tagging.
• Use a local VLM for image or screenshot triage.
• Run OCR/table extraction before SNF document review.
• Create prompt packets for Copilot CLI, Claude CLI, or local model runtimes.

Operating model

Local offload is an acceleration layer, not the final authority.

1. Deterministic tools first — OCR, PDF extraction, audio transcription, media metadata, hashing, and file splitting.
2. Local models second — extraction, cleanup proposals, classification, first-pass tagging, contradiction candidates, speaker consistency checks, image/visual triage.
3. Strong model / human review last — final evidence weighting, exact quote verification, legal/medical/regulatory framing, and anything destined for filing.

Inputs to collect

• Workload type: audio, transcript, PDF, image, OCR, packet review, table extraction, or mixed.
• Private input path(s).
• Private output root.
• Available tools/models, if known.
• Preferred runtime route: LM Studio API, LM Studio OpenAI-compatible API, Goose CLI, Ollama, direct CLI/runtime, Copilot CLI, Claude/Cowork, or human review.
• Whether the user wants plan-only or has explicitly approved a run.
• Maximum concurrency / resource limits.
• Validation standard: spot-check rate, high-value item review, or human-only finalization.

Workflow

Step 1 — Scope the offload

Classify each subtask:

• Extraction: turn audio/PDF/image into text or structured data.
• Segmentation: split long inputs into chunks with preserved citations.
• Attribution: speaker, timestamp, page, source, confidence.
• Classification: casework tags, document types, quality flags.
• Synthesis: candidate findings, contradictions, timelines, open questions.

Step 2 — Select local tools/models

Choose the least risky tool that can do the job:

• Use ffmpeg/ffprobe for media metadata and working-copy conversion.
• Use Parakeet or Whisper-family tools for transcription.
• Use diarization tools for voice clusters, but do not equate clusters to identities without evidence.
• Use PDF utilities (pdftotext, pdfinfo, pdfimages, pdffonts, qpdf) for records before asking a model to interpret pages.
• Use local LLM/VLM runtimes only for bounded tasks with explicit outputs and validation.

Runtime routing guidance

• LM Studio via lms: prefer when the needed model is already downloaded in LM Studio. Use lms for inventory/status tasks and use the LM Studio API only if the local server is already running or the user explicitly approves starting it.
• LM Studio OpenAI-compatible API: useful when an existing script or tool expects OpenAI-style /v1/chat/completions or /v1/models. Treat it as local-only and do not send PHI to remote OpenAI endpoints by accident.
• LM Studio native API: useful when model management, loaded-model status, or richer LM Studio metadata is needed. Keep API probing read-only unless the user authorizes loading/unloading models.
• Goose CLI: useful as a local orchestrator when the user wants Goose to call configured local providers/tools. Prepare prompt/manifests first; do not launch Goose runs against private case folders without explicit approval and a private output root.
• Ollama: useful when the needed model is present in Ollama or the workflow already uses Ollama-compatible model names. Do not pull models or start long generations without approval.
• Direct runtimes: llama.cpp, vLLM, MLX, and similar routes are appropriate for advanced local batches when the user supplies the command/server details.
• ffmpeg/ffprobe: these matter for audio concerns because they can inspect duration/channels/sample rate, normalize working copies, extract audio from video, downmix to mono, resample for ASR, and split long recordings. They do not perform transcription by themselves.

Use scripts/inventory_local_tools.py for a safe, no-model-run inventory of common local tools and optional read-only local API probes.

Step 3 — Prepare artifacts

Create, in the private output root:

• source_note.md — inputs, hashes, source metadata, chain-of-custody note.
• manifest.json — stages, inputs, outputs, prompts, model/tool choices, status.
• local_tool_inventory.json / .md — optional safe inventory of ffmpeg, goose, lms, ollama, Python, PDF tools, and local API reachability.
• prompts/ — per-chunk prompts.
• logs/ — stdout/stderr or tool logs.
• outputs/ — raw and reviewed outputs.
• validation_checklist.md — spot-check plan and high-risk items.

Step 4 — Plan-only report

Before running anything, report:

• What will run and why.
• Expected output files.
• Privacy boundary and confirmation that output is outside git-tracked case material.
• Known risks and validation steps.
• Exact approval needed to launch.

Step 5 — Run only with explicit approval

If the user asks to run:

• Start with one small chunk or sample.
• Capture logs under the private output root.
• Stop if quality is poor, output is hallucinated, speaker identity drifts, or citations are missing.
• Summarize status using counts/categories, not PHI-heavy content.

Step 6 — Validate and route

After offload:

• Verify high-value outputs against source.
• Mark uncertainty, not-found, and model-generated claims separately.
• Route results to the appropriate skill: audio-transcript-review, snf-records-review, case-context-ledger, admin-interaction-log, hipaa-records-request, snf-appeal-supplement, state-agency-complaint, or legal-referral-intake-packet.

Model guidance

Local models are useful even when they are not as intelligent as the main agent:

• Good: extraction, rough categorization, repeated structure, first-pass tagging, chunk summaries, consistency checks.
• Risky: nuanced appeal strategy, clinical/legal interpretation, final contradiction arguments, exact quote certification, speaker identity from text alone.
• Required mitigation: cite every source location, keep raw outputs, sample-check, and do not promote draft findings into filings without human/strong-model review.

Safe availability checks

Availability checks may be run before a model job because they do not analyze PHI:

python3 ${CLAUDE_PLUGIN_ROOT}/skills/local-analysis-offload/scripts/inventory_local_tools.py \
	--out-dir "<private-output>/local-analysis"

Add --probe-apis only when the user wants to check whether already-running local LM Studio or Ollama endpoints respond. The inventory helper must not start servers, pull models, load models, or run generations.

Output summary format

Return:

• Plan/run status: plan-only, sample run, full run, failed, blocked.
• Inputs: count and type, without PHI-heavy names unless requested.
• Stages: tool/model, purpose, output path, status.
• Validation: sample size, failures, high-risk items.
• Next action: run sample, run full batch, improve transcription/OCR, aggregate, or route downstream.

Guardrails

• Not medical or legal advice. This skill plans and routes compute; it does not interpret care, coverage, or law. Local-model output is draft triage only — never a clinical finding, never a legal conclusion — and must not be promoted into an appeal, complaint, letter, or filing without a human verifying it against the source document or recording.
• Local means local. Confirm every configured runtime is on the user's own machine before dispatching a job. Do not route private case material to a remote endpoint, a hosted API, or a shared inference server unless the user has explicitly authorized that specific destination for that specific material.
• Plan-only by default. Report what would run, where output would go, and what needs verifying. Launch nothing until the user approves.
• Generated prompts and logs may contain PHI. Keep them inside the private case output folder, never in a git-tracked location.