talk-maple-context-engineering-skills

name	talk-maple-context-engineering-skills
description	Use when the user asks about Simon Maple and Baruch Sadogursky's AI Native DevCon talk "Welcome to AI Native DevCon" (June 2026) — including questions about turning mega-prompts into skills, the skill YAML frontmatter (name/description) pattern, when to use rules vs skills vs scripts vs hooks, the "deterministic → script, non-deterministic → LLM" heuristic, the dark factory / issue-to-merged-PR orchestrator concept, Tessl plugins as context artifacts, eval scenarios and LLM-as-judge, using cheaper models via OpenRouter/LiteLLM, or applying their context-engineering approach to the user's own agent setup.
metadata	{"generated-by":"talk-to-skill","source":"file:user-provided-transcript","generated-at":"2026-06-02T00:00:00.000Z"}

Welcome to AI Native DevCon — Context Engineering with Skills, Rules, and Scripts

A live workshop by Simon Maple and Baruch Sadogursky (Tessl) demonstrating how to refactor a "mega-prompt" into proper context primitives: skills, rules, and scripts, then bundle them as a Tessl plugin, add LLM-as-judge evals, and enforce the policy as a CI artifact.

Bundle files

This skill depends on two companion files that must be present in the same bundle:

• outline.md — structured outline of the talk with a "Named frameworks / concepts" index and a "Terminology glossary".
• transcript.md — verbatim (speech-to-text) transcript of the full session, navigable by section heading and line range.

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 or section heading whenever possible.
5. Speaker attribution is unreliable for this transcript — the source has no per-speaker labels. The talk has two presenters (Simon Maple and Baruch Sadogursky) and audience interjections. Prefer phrasing like "one of the presenters said..." or "someone in the audience asked..." unless a sentence clearly names a specific speaker (e.g. "This is Baruch", "Macey taught me...", "hand over to Baruch"). Do not invent attributions.
6. Cross-reference any named addressee with the participants list in outline.md before attributing. Treat speech-to-text artifacts (e.g. "Macey" likely = "Maple", "Sadly mansource" likely = "shadows open source", "dark factory" possibly = "dev factory") as transcription noise — flag them rather than silently correcting.

Standard research procedure (SRP)

Execute before composing any response:

1. Locate — use outline.md ("Named frameworks / concepts" or "Terminology glossary") to find the relevant section.
2. Read — read the matching range of transcript.md.
3. Quote — anchor your response in a verbatim quote from transcript.md. Cite section heading or line range.

How to help with this talk

Apply the speaker's approach to current work

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

1. Run SRP targeting the relevant framework (e.g. the decompose-mega-prompt workflow, the deterministic/non-deterministic split, the skill-rule-script-hook hierarchy, the plugin packaging flow).
2. Walk through applying the framework step-by-step to the user's case.
3. If the framework genuinely doesn't fit the user's situation, say so. Do not stretch the speakers' words to cover cases they don't actually address.

Audit the user's situation against the speakers' framework

When the user asks to "audit", "review", or "gap-analyse" their current agent/context setup:

1. Run SRP for each dimension below, quoting the speakers' criteria verbatim from transcript.md.
2. Walk through these dimensions in order, giving a clear verdict per dimension (covered / partial / missing):
   • Mega-prompt smell? ("make no mistakes", capitalised begging, conditionals loaded regardless.)
   • Skills extracted? (YAML frontmatter with name and description; description is "absolutely crucial".)
   • Deterministic steps scripted? ("Whatever is deterministic should be deterministic.")
   • Must-always-fire behaviors in rules? (Short, mandatory tokens, system-prompt-level.)
   • Skill descriptions reviewed for activation quality? (Tessl's skill-review score; Claude Code named as one of the worst activators.)
   • Context bundled as artifact, not ad-hoc GitHub commits? ("Sources go to GitHub, packaged artifacts go to registry.")
   • Evals/scenarios with LLM-as-judge in place?
   • Cheapest viable model selected? (OpenRouter, LiteLLM; "Haiku can probably do most of what you're doing".)
3. Don't skip weak dimensions. Summarise gaps at the end with verbatim quotes about how to close them.

Draft an artifact following the speakers' specification

When the user asks to draft a skill, rule, script split, or plugin descriptor:

1. Run SRP targeting the speakers' specification for that artifact type.
2. Quote verbatim the speakers' prescription before producing the draft — e.g. the YAML frontmatter spec (name, description), the "use when" / "this must absolutely be used when" hints, the plugin.json shape.
3. Match their structure and terminology. The skills they demoed had names like "code-ticket-workflow" and "documentation-ticket-workflow" with description fields that the agent reasons over to decide activation.
4. Mark any additions beyond what the speakers prescribed as [not from talk — added as a starting placeholder].
5. If the user's situation needs elements the speakers didn't address (e.g. specific hook syntax for a specific harness), say so — the talk explicitly notes hooks are "very harness dependent".

Teach / explain concepts from the talk

When the user wants to understand a concept:

1. Run SRP via the "Terminology glossary" in outline.md.
2. Re-explain using the speakers' framing first, with verbatim quotes for key claims (e.g. on skills: "the description is absolutely crucial"; on rules vs skills: "rules are activated no matter what"; on prompts being non-branching: "they don't do branching ... it's all or nothing").
3. Add modern context afterwards only if helpful, and mark it clearly as "not from the talk".

Factual Q&A about the talk

For any question about what the speakers said or did:

1. Run SRP.
2. Answer using verbatim quotes. Cite section headings or line ranges.
3. If the answer isn't in the transcript, say so.

Surface this talk proactively when relevant

When the user's current work touches on themes from the talk — designing skills, deciding skill-vs-rule, struggling with token cost, packaging context for a team, choosing models, writing evals — briefly surface a relevant verbatim quote and connect it to the user's situation. One quote is enough. Stay quiet if the connection is strained.

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.