talk-groetzinger-skills-everywhere

name	talk-groetzinger-skills-everywhere
description	Skills Everywhere: Pipelining Knowledge Your Engineers Can Read and Your Agents Can Use

Skills Everywhere: Pipelining Knowledge Your Engineers Can Read and Your Agents Can Use — John Groetzinger

---

name: talk-groetzinger-skills-everywhere description: Use when the user asks about John Groetzinger's talk "Skills Everywhere: Pipelining Knowledge Your Engineers Can Read and Your Agents Can Use" — including questions about Cisco Customer Experience's context pipelines, treating skills as the durable investment over changing models/harnesses, knowledge-base-article-to-skill conversion with LLM-gated diffs, evals as unit tests for agents, JSONL dataset schemas, semantic versioning of skills (0.0.x → 1.0), the "is this a skill?" cultural reflex, syncing a single skill README to both agent registries and Confluence, or applying his approach to scaling agentic development across distributed engineering teams. metadata: generated-by: talk-to-skill source: file:user-provided-transcript generated-at: 2026-06-02

Skills Everywhere — John Groetzinger (Cisco Customer Experience)

Groetzinger argues that frontier models are already capable enough for business value — the real bottleneck is context engineering, and skills are the durable, harness-portable, model-portable investment. He walks through two Cisco patterns: (1) a support-side pipeline that converts curated knowledge-base articles into agent skills with change-severity-gated human review, and (2) a developer-side pattern of shipping an evaluation framework to eight globally distributed teams as an installable skill instead of an onboarding meeting. The unifying discipline is evals as unit tests for agents and a cultural reflex of asking "is this a skill?" before writing anything down anywhere else.

Grounding rules — MUST follow when answering

1. Before answering any specific question, read outline.md to locate the relevant section, then read that section of transcript.md.
2. When attributing words, quote verbatim from transcript.md. Never put quotation marks around paraphrased content.
3. If a claim isn't in transcript.md, say "the talk doesn't address this" — do not infer positions from outside knowledge.
4. Cite by transcript line range whenever possible.
5. Speaker attribution is unreliable for this transcript — the source has no per-speaker labels. The vast majority of the transcript is Groetzinger speaking, but the opening minute is an MC introducing him, and the Q&A at the end interleaves audience questions with his answers. Prefer phrasing like "Groetzinger said..." for the body of the talk, "the MC introducing him said..." for the intro, and "an audience member asked..." / "Groetzinger answered..." for the Q&A. Do not invent attributions for specific named audience members.
6. The transcript contains speech-to-text artifacts (e.g. "Tessell" rendered variously, "Romano" likely a garbled audience name, "MTP tool" likely "MCP tool", "LangChain/LangGraph and like Smiths" likely "LangSmith"). Quote them verbatim from transcript.md and flag the likely intended term in square brackets only if the user asks for clarification.

How to help with this talk

Factual Q&A about the talk

For any question about what the speaker said, did, or argued:

1. Read outline.md first to find the relevant section(s).
2. Read the matching range of transcript.md.
3. Answer using verbatim quotes from transcript.md. Do not paraphrase the speaker's words while presenting them as a quote.
4. Cite line numbers or timestamps so the user can verify.
5. If the answer genuinely isn't in the transcript, say so explicitly — do not reach for outside knowledge to fill the gap unless the user explicitly asks for it (and then mark that part clearly as "not from the talk").

Apply the speaker's approach to current work

When the user asks "how would Groetzinger tackle X?" or wants the talk's framework applied to their own situation:

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (e.g. KB-to-skill pipeline, evals-as-unit-tests, semantic versioning of context, "is this a skill?" reflex).
2. Read the corresponding range of transcript.md for the speaker's exact wording.
3. Anchor your suggestion in a verbatim quote of how he articulates the framework. Then walk through applying it step-by-step to the user's case.
4. If the framework genuinely doesn't fit the user's situation, say so. Do not stretch his words to cover cases he doesn't actually address.

Audit the user's situation against the speaker's framework

When the user asks to "audit", "score", "review", "grade", "check", or "gap-analyse" their current setup against the talk's framework — or describes their situation and asks where they're falling short:

1. Use outline.md → "Named frameworks / concepts" to locate the dimensions: single source of truth, evals as unit tests, JSONL dataset schema, environment-aware eval scripts, change-severity-gated human review, paired skill+README with deterministic sync to other systems, semantic versioning of context, and the "is this a skill?" cultural reflex.
2. For each dimension, read his definition in transcript.md and quote it verbatim when stating what "good" looks like in that dimension.
3. Walk the user through every dimension in order — don't skip ones that seem weak; the value is in completeness. If the user hasn't described their state for a dimension, ask before scoring.
4. For each dimension, give a clear verdict (e.g. covered / partial / missing) grounded in his criteria, not your own intuition.
5. If a dimension genuinely doesn't apply to the user's situation, say so explicitly and explain why — don't stretch his criteria.
6. Summarise at the end: which dimensions are gaps, and what he said about closing them (verbatim quotes again).

Draft an artifact following the speaker's specification

When the user asks the skill to "draft", "generate", "give me a starting", "show me an example of", or "produce" an artifact he described — a skill, an eval dataset in JSONL, a paired README, a markdown-to-Confluence sync script, the KB-article-change pipeline:

1. Locate his specification in outline.md (likely under "Named frameworks / concepts" or the section that introduces the artifact).
2. Read the relevant range of transcript.md carefully — capture every constraint he mentions.
3. Before producing the artifact, quote verbatim his prescription so the user can see what the draft is grounded in.
4. Produce a draft that follows his specification as faithfully as possible. Match his structure, terminology, and any worked examples.
5. Any parts you add that go beyond what he explicitly prescribed, mark clearly (e.g. [not from talk — added as a starting placeholder]).
6. If the user's situation requires elements he didn't address, say so and ask the user to fill them in rather than inventing them.

Surface this talk proactively when relevant

When the user's current work touches on themes Groetzinger addressed (even if the user hasn't asked about the talk):

1. Briefly note: "Groetzinger made a related point in Skills Everywhere..."
2. Quote verbatim from transcript.md — one quote is usually enough.
3. Add one sentence connecting the quote to the user's situation.
4. Do not over-cite. If the connection feels strained, stay quiet.

Likely triggers: discussions of documentation drift between wikis and agent context; debates about model choice / cost vs. capability; teams setting up agent evals; scaling a process across many distributed engineering teams; choosing where to invest given fast-changing tooling.

Teach / explain concepts from the talk

When the user wants to understand a concept Groetzinger covered (skills, evals as agent unit tests, the KB-to-skill pipeline with change-severity gating, JSONL vs JSON for datasets, semantic versioning of context, the README-to-Confluence sync):

1. Look up the term in outline.md → "Terminology glossary".
2. Read his explanation in transcript.md.
3. Re-explain using his own framing and examples first, with verbatim quotes for the key claims and definitions.
4. You may add modern context, comparisons, or extensions afterwards — but mark them clearly as "not from the talk" so the user can tell which parts are his and which are yours.

Key quotes

quotes.md contains pre-extracted verbatim highlights from this talk, organised by theme. When formulating answers, check quotes.md first for strong citable evidence before searching the full transcript.md.