菜单
The conceptual framework behind the presentation — what "Vibe Coding to Agentic Engineering" means, why the journey is structured the way it is, and how every slide fits the narrative arc
Instructions for fetching current weather temperature data for Dubai, UAE from Open-Meteo API
Instructions for fetching current Dubai time via bash command
Creates an SVG time card showing the current time for Dubai. Writes the SVG to agent-teams/output/dubai-time.svg and updates agent-teams/output/output.md.
Creates an SVG weather card showing the current temperature for Dubai. Writes the SVG to orchestration-workflow/weather.svg and updates orchestration-workflow/output.md.
Display the current time in Pakistan Standard Time (PKT, UTC+5). Use when the user asks for the current time, Pakistan time, or PKT.
Knowledge about the presentation slide format, weight system, navigation, and section structure
| name | vibe-to-agentic-framework |
| description | The conceptual framework behind the presentation — what "Vibe Coding to Agentic Engineering" means, why the journey is structured the way it is, and how every slide fits the narrative arc |
This skill teaches the conceptual model behind the presentation. Every slide and section exists to tell a single story: how a developer incrementally moves from unstructured "vibe coding" (Low level) to high-level agentic engineering (High level).
Vibe Coding (Low level) is when a developer uses Claude Code with no structure — no project context, no conventions, no reusable knowledge. Every prompt is a coin flip. Claude might create random endpoints, ignore existing patterns, skip tests, and produce inconsistent code. The codebase drifts toward entropy with every interaction.
Agentic Engineering (High level) is when Claude Code operates as a fully configured engineering system. It knows the project architecture (CLAUDE.md), follows scoped conventions (Rules), loads domain expertise on demand (Skills), delegates to specialized workers (Agents), orchestrates multi-step workflows (Commands), automates lifecycle events (Hooks), and connects to external tools (MCP Servers). Every prompt produces consistent, tested, production-quality code.
The journey between these two extremes is incremental and cumulative. Each best practice builds on the previous ones, and the presentation teaches them in the order a developer should adopt them.
The presentation uses a 4-level scoring system instead of a percentage bar:
| Level | Order | Color | Journey Bar Height | Description |
|---|---|---|---|---|
| Low | 1 | Red/orange (hsl(0, 70%, 45%)) | 25% | Vibe coding territory — no structure |
| Medium | 2 | Yellow (hsl(40, 70%, 45%)) | 50% | Structured workflows, some automation |
| High | 3 | Light green (hsl(80, 70%, 45%)) | 75% | Domain knowledge, skills, custom agents |
| Pro | 4 | Deep green (hsl(120, 70%, 45%)) | 100% | Full agentic engineering, multi-agent teams |
The journey bar is hidden on slide 1 (title slide) and appears from slide 2 onward. Levels are set via data-level attributes on key transition slides and inherited by subsequent slides until the next level change. A .level-badge is JS-injected on the slide's h1 when the level changes (do not hardcode these in HTML).
Every technique is demonstrated on a realistic full-stack project. The presentation shows the transformation from a plain project (vibe coding) to one with full Claude Code configuration (agentic engineering):
Before (Vibe Coding):
todoapp/
├── backend/ # FastAPI (Python)
│ ├── main.py
│ ├── routes/
│ ├── models/
│ └── tests/
└── frontend/ # Next.js (TypeScript)
├── components/
├── pages/
└── lib/
After (Agentic Engineering):
todoapp/
├── .claude/ # Claude Code config
│ ├── agents/ # Custom subagents
│ ├── skills/ # Domain knowledge
│ ├── commands/ # Slash commands
│ ├── hooks/ # Lifecycle scripts
│ ├── rules/ # Modular instructions
│ ├── settings.json # Team settings
│ └── settings.local.json # Personal settings
├── backend/
│ └── CLAUDE.md # Backend instructions
├── frontend/
│ └── CLAUDE.md # Frontend instructions
├── .mcp.json # Managed MCP servers
└── CLAUDE.md # Project instructions
Why TodoApp? It's small enough to fit on slides but complex enough to demonstrate real problems: a backend with route patterns and test conventions, a frontend with component hierarchy and design tokens, and a monorepo structure where cross-cutting concerns (like adding a new feature) require coordination between both sides.
The TodoApp makes the vibe-coding problem concrete: without structure, asking Claude to "add a notes feature" produces a random /api/notes endpoint that doesn't follow routes/todos.py patterns, a standalone page with no sidebar navigation, and zero tests. With full agentic setup, the same request produces a route following existing patterns, a page integrated into the sidebar, and tests matching test_todos.py style.
The presentation follows a deliberate pedagogical sequence. Each section unlocks a new capability layer:
Purpose: Set the stage. Introduce the TodoApp, define vibe coding, and show the destination.
Purpose: Get Claude Code installed and running. This is purely logistical — no engineering practices yet.
Purpose: The first real improvement. Better inputs produce better outputs, even without any project configuration.
@files to give Claude the code it needs. Reduces hallucination immediately./plan forces thinking before coding. Prevents wasted effort on wrong approaches.Why Low level: Prompting is foundational but limited. It improves individual interactions but doesn't create lasting project knowledge. Each session starts from zero.
Purpose: The leap from session-level to project-level knowledge. Claude now remembers across sessions.
.claude/rules/. Rules are a multiplier — they apply automatically to every matching file, enforcing consistency without developer effort. A single backend-testing.md rule ensures every test follows the same pattern forever.Why Medium level: Project memory transforms Claude from a stateless tool into a context-aware collaborator. But knowledge alone doesn't create workflows.
Purpose: Systematic approaches that prevent wasted effort and improve execution quality.
Why still Medium level: Workflows are important but relatively simple concepts. They build on Part 3's project memory and use it more systematically. The step up to High comes with domain knowledge.
Purpose: Reusable, on-demand expertise. Skills are the bridge between static memory (CLAUDE.md/Rules) and dynamic agents.
frontend-conventions skill for the TodoApp that teaches Tailwind tokens, component patterns, and sidebar integration.context: fork option.Why High level: Skills are the first "multiplier" concept — one skill definition improves every future interaction in its domain. But skills are passive knowledge; they need agents to become active.
Purpose: The destination covered in this presentation. Autonomous, specialized agents that coordinate to build features end-to-end.
/add-feature command coordinates frontend + backend agents, each with their own skills, to deliver a complete feature. This is the architectural pinnacle.Why High level: This section covers the highest-value practices taught in this presentation. Everything before it was building toward this. Orchestration and agentic workflows represent the ceiling of what this course covers — full Pro (multi-agent teams, advanced orchestration patterns) is beyond this presentation's scope.
The celebration moment. Shows the complete TodoApp configuration:
Purpose: Reference material. Every command, setting, and configuration option. No weight because these are reference lookups, not journey milestones. Includes: tool usage, all slash commands, commit/PR workflows, customization options, debugging tips, and golden rules.
When creating or modifying slides, consider:
Where does this concept sit on the journey? A slide about "better error messages in prompts" belongs in Part 2 (prompting, Low level). A slide about "agent memory scopes" belongs in Part 6 (agentic, High level).
What's the before/after? Every significant slide should implicitly or explicitly show the contrast: what happens at Low level (vibe coding) vs what happens with this technique. Use the TodoApp to make it concrete.
Does the level assignment feel right? Level transitions happen at Part section boundaries. Individual slides within a section inherit the section's level.
Does it build on what came before? Skills assume the developer already knows about CLAUDE.md and Rules. Agents assume they know about Skills. Commands assume they know about Agents. Never reference a concept before its section.
Use the TodoApp. Abstract explanations lose the audience. Show the actual routes/todos.py code, the actual Sidebar.tsx component, the actual CLAUDE.md content. The running example is what makes the framework tangible.
| Slide | Slide Name | data-level | Level Label |
|---|---|---|---|
| 10 | Better Prompting (section divider) | data-level="low" | Low |
| 18 | Project Memory (section divider) | data-level="medium" | Medium |
| 29 | Domain Knowledge (section divider) | data-level="high" | High |
| 34 | Agentic Engineering (section divider) | data-level="high" | High |
All other slides inherit the level from the last data-level attribute set before them. Slides 1–9 (Intro + Prerequisites) have no level and keep the bar hidden until slide 2 shows "Low" (slides 2–9 are below the first level transition at slide 10, so the bar shows empty/zero until slide 10).
Note: The main presentation (presentation/index.html) caps at High level — data-level="pro" is not used. The Pro tick mark remains visible on the journey bar as the theoretical ceiling, but the fill never reaches it. The video presentation (1-video-workflow.html) caps at Medium level.