technical-discovery · diff
git:20260826.c66266a to git:20261017.d3ef466
14 added, 3 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.
+ 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. Run the rubric's reads-well-too check before finalizing.
- 4. Write the output in the exact shape under `## Output format`.
+ 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.