Technical Discovery

---
name: technical-discovery
description: Audits a technical or solution-fit call transcript against a seven-dimension rubric (current stack, future-state vision, POC scope, technical stakeholders, success metrics, resourcing, next step) and credits only what the buyer said, or sweeps a CRM export for deals missing technical-fit data. Use when the user asks to review a technical discovery or solution-engineering call, scope a proof of concept, or find deals heading into a POC without technical groundwork.
license: MIT
metadata:
  zime:category: new-business
  zime:dimension: stage
  zime:stage: technical-discovery
  zime:input-modes: transcript,csv
---

# 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"
```

1. Read the whole transcript before scoring anything — scope, stakeholders,
   or a success metric can surface late.
2. Score each of the seven dimensions in `references/rubric.md`
   independently. 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.
3. Before each status, apply these tests:
   - Evidence is one buyer line that is about that dimension. Never use one
     line for two dimensions, and never count a line that only hints at a
     dimension.
   - When no line addresses a dimension, the status is Missed. Do not soften
     it to Partial because the call felt thorough elsewhere.
   - Partial needs a quotable line that names the dimension but stays vague.
     When you cannot quote that line, it is Missed.
   - Covered needs the specifics the rubric names (a named system, a named
     person, a threshold), not a general statement.
   - Read each dimension's "does not count" line first.
4. Run the rubric's reads-well-too test before finalizing, in both directions.
5. 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.