From 7741e64d3fc1eab326528a6d31e7d3af8683eb2c Mon Sep 17 00:00:00 2001 From: elvis Date: Wed, 27 May 2026 09:22:20 +0000 Subject: [PATCH] speaker-notes --- speaker-notes.md | 87 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 speaker-notes.md diff --git a/speaker-notes.md b/speaker-notes.md new file mode 100644 index 0000000..b74931d --- /dev/null +++ b/speaker-notes.md @@ -0,0 +1,87 @@ +# Speaker Notes + +## Slide 1 — Title + +"Hey everyone. Quick talk today — AI Skills. The tagline is 'teach your AI once, use forever.' I'll show what that means in about 10 minutes, most of it live demo." + +## Slide 2 — The Problem + +"We all use AI tools daily. And we all have this experience: you explain to the AI how you want something done — code review, PR description, whatever — and next session, it's gone. You start over. + +There's no shared memory. Usually, there's no team standard the AI can follow. Everyone's AI tools behaves differently on the same task. Some people copy-paste prompts around, but that doesn't scale and it drifts. + +The rule of thumb: if you've explained something to the AI more than twice, it should be a skill." + +## Slide 3 — Rules vs Skills + +"Quick distinction. Some of you use rules already — .cursorrules or similar. Rules are always-on. They're loaded into every interaction. Good for style, naming conventions, guardrails. + +Skills are different. They're on-demand. Zero token cost until you actually need them. They encode a specific workflow — how to do a code review, how to split a PR, how to run a deploy checklist. + +Key point at the bottom: skills are just markdown files. They're not locked to one tool. If you use Cursor, Copilot, Claude — doesn't matter. The content is portable." + +## Slide 4 — Making Skills Portable + +"Practical question — what if the team uses different tools? Some of you are on Cursor, some Copilot, some might try Claude Code or Codex. + +The trick: store skills in .agents/skills/ and add a reference in AGENTS.md at the repo root. Cursor, Claude Code, Codex CLI, OpenCode — they all read one or both of those natively. You're covered out of the box. + +For Copilot, you add a line in .github/copilot-instructions.md pointing to the skills directory. Windsurf uses .windsurfrules. JetBrains — reference it in IDE settings. + +One folder in the repo, one AGENTS.md entry, and most tools on the team just work. The skill content itself is plain markdown — nothing tool-specific in it." + +## Slide 5 — How It Works + +"Dead simple structure. That file has a YAML header — name and description — and then markdown instructions for the AI. + +The description field is the trigger — the AI matches what you're asking for against skill descriptions and picks the right one. If your description is vague, it won't fire. If it's specific, it's reliable. The body tells the AI how to execute. + +Because it can live in the repo, it can be version-controlled. It will evolve through PRs like any other code. It's up to us, wether we want it to be a part of repo, or everyone will have a set of his own skills." + +## Slide 6 — Skills Ecosystem + +"You don't have to write everything from scratch. There's already a growing ecosystem. + +skills.sh is a directory — think npm for AI skills. You browse, pick one, run npx skills add, done. + +A few highlights: grill-me — the AI interviews you about your plan until every gap is covered. I actually used this to prepare this presentation. tdd — enforces red-green-refactor, the agent writes a failing test before touching implementation. diagnose — structured debugging loop so the AI doesn't just guess randomly. handoff — when you hit context limits or switch tools, it compacts everything into a document another agent can pick up cold. caveman — slashes token usage by ~75%, useful when you're iterating fast on long sessions. + +Matt Pocock's repo and skills.sh have curated sets focused on professional engineering workflows. Vercel and Microsoft publish skills too. + +Point is: before you write a skill, check if someone already solved it. And when you do write one — maybe publish it back." + +## Slide 7 — Writing a Good Skill + +"I'll do a quick demo shorlty, but let's point out some good practices first. The description field is the most important line — it's how the AI decides whether to use this skill. Be specific. 'Help with code' matches everything and nothing. 'Review PR from Bitbucket, find bugs, suggest fixes' — that triggers reliably. + +Be opinionated about output format. If you don't specify, you get a different shape every time. Severity levels, grouping by file, max sentence count — that's what makes a skill useful versus a generic prompt. + +Keep it under 200 lines. If your skill is 500 lines, it's probably two or more skills jammed together. It's always a good idea to create smaller specific skills and reference them in some conditional block, so again, tokens are spent only when necessary. One workflow per skill. + +And iterate. Your first draft won't be perfect. Run it three times on real work, see where it drifts, tighten those spots. + +Real example from our team: I built a review-pr skill and evolved it through several iterations. Tomas, our tech lead, built his own — over 700 lines, much more robust. Here's the interesting part: when he runs his skill on my PR and then I run mine on top, they catch different things. Often unrelated to the original PR scope. Two skills shaped by different people's priorities surface different bugs. That's the real payoff — it's not just consistency, it's coverage you wouldn't get from one person's perspective alone." + +## Slide 8 — Live Demo + +"Alright, let me show this for real. I'm going to ask the AI to help me create a code review skill from scratch. Watch how it interviews me about what we care about, then generates the SKILL.md. Then I'll run it on an actual diff." + +*[Do the demo]* + +## Slide 9 — Skills Evolve and Compose + +"Two things I want to highlight before we wrap. + +First — skills aren't write-once. They evolve. My review-pr skill went through four-plus iterations. Each time I ran it on a real PR, I noticed where it drifted — maybe it was too verbose, or missed a category. I tightened the instructions. It lives in the repo, so those improvements come as normal PRs. + +Second — composability. Skills can chain. Output of one feeds the next. The diagnose skill finds the root cause, then the tdd skill writes the regression test. Or — like I mentioned — Tomas runs his review skill, I run mine, and they catch different things. You're not limited to one skill per task." + +## Slide 10 — What's Next? + +"So — that's it. Simple concept, immediate payoff. + +My ask: when something annoys you three times — inconsistent reviews, repeating the same explanation, whatever — that's a skill waiting to be written. + +Open a PR to the .agents/skills directory — or just ping me with an idea and we can pair on it. + +Any ideas right now? Workflows you'd want to encode?"