talk-maple-continuous-ai-github-workflows

name	talk-maple-continuous-ai-github-workflows
description	Use when the user asks about the "Welcome to AI Native DevCon" opening talk (introduced by Simon Maple, content delivered by a GitHub Next presenter) — including questions about Continuous AI (CAI) as a third pillar alongside CI/CD, GitHub Agentic Workflows, the repository-as-software-factory model, Repolaris and automated open source maintenance, the safety architecture for running coding agents in CI (sandbox, read-only, narrow safe outputs, threat detection), agent zoo vs single-workflow strategies, Pelle's agent factory, factory/flow thinking for repos, or applying these patterns to the user's own repositories.
metadata	{"generated-by":"talk-to-skill","source":"user-provided-transcript","generated-at":"2026-06-02T00:00:00.000Z"}

Welcome to AI Native DevCon — Continuous AI and GitHub Agentic Workflows

The talk opens AI Native DevCon and argues that the industry's near-exclusive focus on individual developer productivity (Copilot-style) has neglected a second polarity: continuity, automation, and team collaboration in the SDLC. The speaker proposes Continuous AI (CAI) as a third pillar next to CI/CD, demonstrates GitHub's open-source implementation (GitHub Agentic Workflows), and shows how reframing a repository as an automated software factory — with safety architecture, quality gates, and flow thinking — turned dormant open source projects back into forward velocity (the Repolaris case study).

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 metadata names Simon Maple as the speaker, but the transcript content is clearly delivered by someone on GitHub Next ("I work at a wonderful place called GitHub Next"), references "Pelle on my team", and discusses repositories the speaker personally maintains. Simon Maple is at Tessl per the bio, not GitHub Next. Prefer phrasing like "the speaker said..." or "the presenter from GitHub Next argued..." rather than asserting "Simon Maple said X". If the user explicitly asserts Simon Maple is the speaker, note the discrepancy once and then defer to their framing.
6. Cross-reference any named addressee with names mentioned in the transcript before attributing (e.g. Pelle, May/Maze from Hud) — do not invent attributions.

How to help with this talk

Apply the speaker's approach to current work

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

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (Continuous AI, repository-as-factory, agent zoo vs single workflow, safety architecture, flow/quality-gate thinking).
2. Read the corresponding range of transcript.md for the speaker's exact wording.
3. Anchor your suggestion in a verbatim quote of how the speaker 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 the speaker's words to cover cases they don't actually address.

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

When the user asks to "audit", "review", "check", or "gap-analyse" their agentic automation setup against the talk's safety architecture — or describes their setup and asks where they're falling short:

1. Use outline.md → "Named frameworks / concepts" → Safety architecture for agentic automation to locate the dimensions.
2. For each dimension, read the speaker's definition in transcript.md and quote it verbatim when stating what "good" looks like:
   • Execution in sandbox / container
   • Agent runs read-only
   • No direct access to secrets
   • Narrow safe outputs (e.g. one issue, one PR)
   • Threat detection between plan and apply stages
   • Human oversight guaranteed through issue/PR review (no auto-merge)
   • Shared package caches off (avoid package-cache poisoning)
   • Outgoing network firewalled and controlled
3. Walk the user through every dimension in order. If the user hasn't described their state for a dimension, ask before scoring.
4. For each dimension, give a clear verdict (covered / partial / missing) grounded in the speaker's criteria.
5. If a dimension genuinely doesn't apply, say so explicitly. Don't stretch the speaker's criteria.
6. Summarise at the end: which dimensions are gaps, and quote what the speaker said about closing them.

A second auditable framework: the factory flow checklist — input source, quality gates, safe output channel, human gate, cadence/triggers. Use the same procedure if the user asks about their automation pipeline rather than the security architecture specifically.

Draft an artifact following the speaker's specification

When the user asks the skill to "draft", "give me a starting", or "produce" a GitHub Agentic Workflow file:

1. Locate the speaker's specification in outline.md → "Anatomy of an agentic workflow file" and the corresponding transcript range.
2. Capture every constraint the speaker mentions: front matter + markdown body, triggers (e.g. weekly cron, on: issue opened/reopened), safe output specification (e.g. "allowed to create one issue"), tools list, prompting in natural language with "deliberately ambiguous, generally useful ambiguity", actions familiar from GitHub Actions, runs on the GitHub information fabric/data model.
3. Before producing the artifact, quote verbatim the speaker's prescription so the user can see what the draft is grounded in.
4. Produce a draft that follows the speaker's specification as faithfully as possible. The speaker does not show a complete YAML in the transcript — only describes the shape. Mark any concrete syntax you add as [not from talk — inferred from GitHub Actions conventions].
5. Any parts beyond what the speaker explicitly prescribed, mark clearly. The user must be able to tell which parts are the speaker's design and which are yours.
6. If the user's situation requires elements the speaker didn't address (specific tool names, exact YAML keys), say so and ask the user to fill them in rather than inventing them.

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 so the user can verify.
5. If the answer genuinely isn't in the transcript, say so explicitly.

Surface this talk proactively when relevant

When the user's current work touches on themes the speaker addressed (continuous AI/automation, agentic workflows in CI, open source maintainer burnout, repository automation, safety vs productivity tradeoffs, factory/flow thinking for engineering teams):

1. Briefly note: "The AI Native DevCon opening talk made a related point..."
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.

Teach / explain concepts from the talk

When the user wants to understand a concept the speaker covered (Continuous AI, safe outputs, agent zoo, Repolaris, repository-as-factory, n+1 sub-factory, quality gates in agentic flow):

1. Look up the term in outline.md → "Terminology glossary".
2. Read the speaker's explanation in transcript.md.
3. Re-explain using the speaker's own framing and examples first, with verbatim quotes for the key claims and definitions.
4. You may add modern context afterwards — but mark it clearly as "not from the talk".

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.