poc-pilot-pipeline-check

POC/Pilot Pipeline Check

You are a pipeline-hygiene auditor. Sweep every deal sitting in a POC or pilot stage and flag which of them can never convert because nobody wrote down what winning looks like. This is a pipeline-wide structural sweep across every live POC at once, not a single-call audit — pilot-to-conversion audits the individual check-in conversation that converts one pilot; use this skill instead when the question is "which of our open POCs are already dead and don't know it yet."

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.
• Default to running end to end without stopping to ask which stage labels to match or how to handle a missing column — apply the defaults below, decide, and note the assumption once.
• If the in-scope filter returns zero rows (no POC/pilot-stage deals in the export), say so plainly and stop — don't force a check onto rows that don't exist.

When to use this

• RevOps wants a pipeline-wide read on POC/pilot health before a forecast call.
• A manager is triaging a rep's pipeline and wants to know which POCs have no defined exit before spending more time on them.
• Nobody has looked at the POC/pilot stage in a while and deals may be sitting there open-ended.

Input

A .csv deal/pipeline export. There is no transcript mode — this skill only reads structured pipeline data, never a call.

Connector mode is optional and secondary: if a tool in the conversation can list opportunities/deals directly, use it and treat the returned rows exactly like CSV rows. Otherwise, work from the CSV file.

How to run it

claude "run poc-pilot-pipeline-check on ./exports/pipeline.csv"

1. Detect columns. Match headers case-insensitively, ignoring _/-/space differences. Accepted synonyms are listed in references/rubric.md. If a column a check needs is absent, that check reports Unknown (column missing) once, up front — never infer a missing column's value from another column.
2. Filter to stage. Keep rows whose stage fuzzy-matches POC/pilot (e.g. POC, Pilot, POC/Pilot, Proof of Concept). Report how many rows were in scope out of the export's total.
3. Run every check in references/rubric.md against each in-scope row. Each check returns Flagged, Clean, or Unknown.
4. Cite evidence. Every flagged deal cites the column name and the actual cell value that triggered the flag, e.g. champion = (empty) or poc_end_date = 2026-01-14. A flag with no cited cell does not ship.
5. Reads-well-too check. Confirm the two genuinely healthy deals in assets/sample-pipeline-poc-pilot-pipeline-check.csv come back Clean. A rubric that flags everything is useless.

Output

One markdown table, flagged deals first, most flags first:

| Deal | Flags | Evidence | Suggested action |

Then two closing lines:

• N of M deals in <stage> flagged
• The single most common flag across them

Nothing else — no scores, no letter grades, no percentages invented from nothing.

Sample data

assets/sample-pipeline-poc-pilot-pipeline-check.csv — synthetic pipeline export, run the skill against it first.

Do not

• Don't blend the flags into one health score or letter grade — the output is a flag list with evidence, not a rating.
• Don't infer a missing column's value from another column; report it Unknown and move on.
• Don't read or infer anything from a call transcript — this skill only reads structured pipeline data.

Related skills

• pilot-to-conversion audits one pilot's check-in conversation; this skill sweeps the whole pipeline stage instead.
• poc-success audits the exit review once a POC is claimed done; this skill catches POCs that are still open and stalling.

What this does not do

No CRM connection, no API calls, no telemetry, no data retention beyond the current session. It reads the file (or connector rows) you point it at and nothing else.