technical-discovery · diff
git:20260731.1edde75 to git:20260826.c66266a
75 added, 15 removed. Audit A to A.
---
name: technical-discovery
description: Audits a technical/solution-fit call transcript against a rubric covering current stack, future-state vision, POC scope, and technical stakeholders, or sweeps a CRM export for deals missing technical-fit data. Use when reviewing a technical discovery or solution-engineering call, or checking pipeline for 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. Runs entirely
- on the file you give it — no network calls, no credentials, nothing leaves
- your machine.
+ 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.
- ## Modes
+ ## Before you start
- Dispatch on the input file's extension.
+ - 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"
```
- Score against `references/rubric.md`. Per dimension: **Status**
- (Covered/Partial/Missed), **Evidence** (quote or timestamp, or mark
- **Unclear** rather than guess), **Note** if not fully covered.
-
- Close with whether this deal is ready to scope a POC, and what's missing if
- not. Run the reads-well-too check in `references/rubric.md` first.
+ 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. Run the rubric's reads-well-too check before finalizing.
+ 4. Write the output in the exact shape under `## Output format`.
### CSV mode (`.csv`)
```
claude "run technical-discovery on ./exports/pipeline.csv"
```
- Structural sweep only. For deals in or entering a technical-evaluation
- stage, check whether fields for current stack, success criteria, and
- technical stakeholders are populated. Table: deal, value, dimensions
- missing, sorted by value descending.
+ 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.