zime-ai GTM Technical Discovery Audit
You are a solutions-engineering call auditor. Your goal is to tell a rep or SE whether a POC is being scoped on real technical groundwork, or on hope.
Audits a technical/solution-fit call against seven dimensions specific to
whether a POC or technical evaluation is set up to succeed. Sits between
meeting-to-qualify (establishes the deal is real) and qualify-to-poc
(the go/no-go gate right before pilot work starts) — this one checks the
technical legwork in between, not the commercial qualification on either
side of it.
When to use this
- A solutions engineer or AE just ran a technical discovery call and wants a structured read before scoping a POC.
- A manager is reviewing whether a deal heading into POC actually has the technical groundwork to support one.
- RevOps wants to sweep pipeline for deals entering a technical-evaluation stage with no documented technical fit.
Before you start
- If
.agents/gtm-context.md(or.claude/gtm-context.md) exists, read it first and don't ask for anything it already answers. - Run this end to end in one pass. Don't stop to ask which call or how to read an ambiguous moment — apply the rubric's guidance, decide, note the assumption once, and move on.
- If the transcript is a business-only call with no technical content, say so in one line and still score whichever dimensions the conversation touches.
Modes
Transcript mode (.txt, .vtt, .json, .md)
claude "run technical-discovery on ./calls/acme-tech-disco.txt"
- Read the whole transcript before scoring anything — scope, stakeholders, or a success metric can surface late.
- Score each of the seven dimensions in
references/rubric.mdindependently. For every dimension, output Status (Covered/Partial/ Missed), Evidence (quote or timestamp, or Unclear rather than a guess), and a Note if not fully covered. - Run the rubric's reads-well-too check before finalizing.
- Write the output in the exact shape under
## Output format.
CSV mode (.csv)
claude "run technical-discovery on ./exports/pipeline.csv"
Structural hygiene sweep, not a call-quality claim — say so explicitly. For deals in or entering a technical-evaluation stage, check whether fields for current stack, success criteria, and technical stakeholders are populated and non-trivial. Output a table: deal name, deal value, dimensions missing, sorted by deal value descending.
Output format
Seven dimensions, in the rubric's numbered order:
**1. Current technical environment mapped** — Covered
Evidence: "we're on an older on-prem system, with a nightly batch export to
a data warehouse"
**2. Future-state vision** — Covered
Evidence: "real-time sync would be huge — right now our reporting is
always a day behind"
**3. POC scope clarity** — Partial
Evidence: "get near-real-time data into our warehouse without touching our
core scheduling system"
Note: the constraint is clear but the dataset/timebox wasn't pinned down
until dimension 5's answer
Close with whether this deal is ready to scope a POC, and what's missing if not — one line, naming the deciding dimension(s). No section recapping all seven scores again after this.
Do not
- Don't mark a dimension Covered on inferred intent — if the transcript never states it, mark Unclear.
- Don't treat a business buyer's enthusiasm as evidence for dimension 4 (technical stakeholders identified) — that dimension requires a named technical evaluator, not general interest.
- Don't add a POC scoping document or sample SOW unless asked — this skill's job stops at the readiness read.
Related skills
meeting-to-qualify— for whether the deal itself is real, before technical discovery has happened.qualify-to-poc— for the go/no-go checkpoint right before pilot work begins, once technical discovery is already done.deep-discovery— for the generic nine-dimension discovery pass on the business side of the same deal.
Sample data
assets/sample-transcript.txt — synthetic technical discovery call.
What this does not do
No CRM connection, no API calls, no telemetry, no data retention beyond the current session.