added vibe-to-agentic framework

This commit is contained in:
Shayan Rais
2026-02-12 21:32:44 +05:00
parent 09518901b1
commit ef233afc7c
7 changed files with 1696 additions and 1007 deletions
+98
View File
@@ -0,0 +1,98 @@
---
name: presentation-curator
description: PROACTIVELY use this agent whenever the user wants to update, modify, or fix the presentation slides, structure, styling, or weights
tools: Read, Write, Edit, Grep, Glob
model: sonnet
color: magenta
skills:
- presentation/vibe-to-agentic-framework
- presentation/presentation-structure
- presentation/presentation-styling
---
# Presentation Curator Agent
You are a specialized agent for modifying the presentation at `presentation/index.html`.
## Your Task
Apply the requested changes to the presentation while maintaining structural integrity.
## Workflow
### Step 1: Understand Current State (presentation-structure skill)
Follow the presentation-structure skill to understand:
- The slide format (`data-slide` and `data-weight` attributes)
- The journey bar system and weight requirements
- The section structure (Parts 0-6 + Appendix)
- How slide numbering works
### Step 2: Apply Changes
Based on the request:
- **Content changes**: Edit slide HTML within existing `<div class="slide">` elements
- **New slides**: Insert new slide divs with correct `data-slide` numbering
- **Reorder**: Move slide divs and renumber all `data-slide` attributes sequentially
- **Weight changes**: Update `data-weight` attributes ensuring they sum to 100%
- **Styling changes**: Update CSS within the `<style>` block, matching existing patterns
### Step 3: Match Styling (presentation-styling skill)
Follow the presentation-styling skill to ensure:
- New content uses the correct CSS classes
- Code blocks use syntax highlighting spans
- Layout components match existing patterns
### Step 4: Verify Integrity
After changes, verify:
1. All `data-slide` attributes are sequential (1, 2, 3, ...)
2. All `data-weight` values sum to exactly 100
3. No duplicate slide numbers exist
4. The `totalSlides` JS variable matches the actual count (it's auto-computed from DOM)
5. Any `goToSlide()` calls in the TOC point to correct slide numbers
### Step 5: Self-Evolution (after every execution)
After completing changes to the presentation, you MUST update your own knowledge to stay in sync. This prevents knowledge drift between the presentation and the skills you rely on.
#### 5a. Update the Framework Skill
Read the actual current state of `presentation/index.html` and update `.claude/skills/presentation/vibe-to-agentic-framework/SKILL.md`:
- **Weight Reference Table**: If any slides were added, removed, renamed, or reweighted, update the table at the bottom of the skill to reflect the actual `data-weight` attributes and `<h1>` titles in the HTML. The table must always match reality.
- **Section ranges**: If slide numbering changed (e.g., Part 3 now spans slides 1925 instead of 1824), update the journey arc section descriptions.
- **Journey percentages**: If section dividers have new journey percentages in their `section-desc`, update the corresponding Part descriptions.
- **New concepts**: If a new weighted slide introduces a concept not yet described in the journey arc, add a bullet explaining what it is, why it has its weight, and how it fits the Vibe Coding → Agentic Engineering narrative.
- **Removed concepts**: If a weighted slide was removed, remove its entry from both the journey arc and the weight table.
#### 5b. Update the Structure Skill
Update `.claude/skills/presentation/presentation-structure/SKILL.md`:
- **Weight Distribution table**: Update section slide ranges and total weights to match the current presentation.
- **Section divider examples**: If section divider format changed, update the example HTML.
#### 5c. Update This Agent (yourself)
If you encountered an edge case, discovered a new pattern, or found that the workflow needed adjustment, append a brief note to the "Learnings" section below. This helps future invocations avoid the same issues.
## Learnings
_Findings from previous executions are recorded here. Add new entries as bullet points._
## Critical Requirements
1. **Sequential Numbering**: After any add/remove/reorder, renumber ALL slides sequentially
2. **Weight Integrity**: Weighted slides must sum to exactly 100%
3. **Preserve Existing Content**: Don't modify slides that aren't part of the requested change
4. **Match Patterns**: Use the same HTML patterns as existing slides (see skills)
## Output Summary
After completing changes, report:
- What slides were changed
- Current total slide count
- Current weight sum (should be 100%)
- Any renumbering that occurred
@@ -0,0 +1,84 @@
---
name: presentation-structure
description: Knowledge about the presentation slide format, weight system, navigation, and section structure
---
# Presentation Structure Skill
Knowledge about how the presentation at `presentation/index.html` is structured.
## File Location
`presentation/index.html` — a single-file HTML presentation with inline CSS and JS.
## Slide Format
Each slide is a div with `data-slide` (sequential number) and optional `data-weight` (journey percentage):
```html
<!-- Regular slide -->
<div class="slide" data-slide="12" data-weight="5">
<h1>Slide Title</h1>
<!-- content -->
</div>
<!-- Section divider slide -->
<div class="slide section-slide" data-slide="10">
<h1>Section Name</h1>
<p class="section-desc">Description of this section</p>
</div>
<!-- Title slide (centered) -->
<div class="slide title-slide" data-slide="1">
<h1>Presentation Title</h1>
<p class="subtitle">Subtitle text</p>
</div>
```
## Journey Bar Weight System
- Slides with `data-weight="N"` contribute N% to the journey progress bar
- All weights across the entire presentation MUST sum to exactly 100
- The journey bar reads weights at page load and pre-computes cumulative sums
- Slides without `data-weight` contribute 0% (informational slides, appendix)
- The bar is hidden on slide 1 (title slide)
### Weight Distribution by Section
| Section | Range | Total Weight |
|---------|-------|-------------|
| Part 0: Introduction | Slides 1-4 | 0% |
| Part 1: Prerequisites | Slides 5-9 | 0% |
| Part 2: Better Prompting | Slides 10-17 | 20% |
| Part 3: Project Memory | Slides 18-24 | 20% |
| Part 4: Structured Workflows | Slides 25-28 | 10% |
| Part 5: Domain Knowledge | Slides 29-33 | 15% |
| Part 6: Agentic Engineering | Slides 34-46 | 35% |
| Appendix | Slides 47+ | 0% |
## Navigation System
- `goToSlide(n)` — used in TOC links, must match actual `data-slide` numbers
- `totalSlides` is auto-computed from DOM (`document.querySelectorAll('[data-slide]').length`)
- Arrow keys, Space, and touch swipe for navigation
- Slide counter shows `current / total` at bottom-left
## Renumbering Rules
After adding, removing, or reordering slides:
1. Renumber ALL `data-slide` attributes sequentially starting from 1
2. Update all `goToSlide()` calls in the TOC/Journey Map slide
3. The JS `totalSlides` auto-computes — no manual update needed
4. Verify no gaps or duplicates exist
## Section Divider Format
Section dividers use the `section-slide` class and show the current journey percentage:
```html
<div class="slide section-slide" data-slide="10">
<p class="section-number">Part 2</p>
<h1>Better Prompting</h1>
<p class="section-desc">Journey: 0% — effective prompting for real results.</p>
</div>
```
@@ -0,0 +1,104 @@
---
name: presentation-styling
description: Knowledge about CSS classes, component patterns, and syntax highlighting in the presentation
---
# Presentation Styling Skill
CSS classes and HTML patterns used in `presentation/index.html`.
## CSS Component Classes
### Layout
- `.two-col` — 2-column grid layout with 24px gap
- `.info-grid` — 2-column grid for info cards
- `.col-card` — Card inside a column (add `.good` for green border, `.bad` for red border)
- `.info-card` — Card in an info grid
### Content Blocks
- `.trigger-box` — Gray box with dark left border (for key concepts, prerequisites)
- `.how-to-trigger` — Green box with green border (for "Try This" actions)
- `.warning-box` — Orange box with warning border (for important warnings)
- `.code-block` — Dark code display block with monospace font
### Lists
- `.use-cases` — Container for icon+text list items
- `.use-case-item` — Individual item with icon and text
- `.feature-list` — Simple bordered list
### Tags & Badges
- `.matcher-tag` — Gray inline pill tag
- `.weight-badge` — Green pill badge (auto-injected by JS for weighted slides)
## Code Block Syntax Highlighting
Inside `.code-block`, use these spans for syntax coloring:
```html
<div class="code-block">
<span class="comment"># This is a comment</span>
<span class="key">field_name</span>: <span class="string">value</span>
<span class="cmd">&gt;</span> command to run
</div>
```
- `.comment` — Green (#6a9955) for comments
- `.key` — Blue (#9cdcfe) for property names/keys
- `.string` — Orange (#ce9178) for string values
- `.cmd` — Yellow (#dcdcaa) for commands/prompts
## Slide Type Patterns
### Content Slide with Two Columns (Good vs Bad)
```html
<div class="slide" data-slide="N" data-weight="5">
<h1>Title <span class="weight-badge">+5%</span></h1>
<div class="two-col">
<div class="col-card bad">
<h4>Before (Vibe Coding)</h4>
<!-- bad example -->
</div>
<div class="col-card good">
<h4>After (Agentic)</h4>
<!-- good example -->
</div>
</div>
</div>
```
### Content Slide with Code Example
```html
<div class="slide" data-slide="N">
<h1>Title</h1>
<div class="trigger-box">
<h4>Key Concept</h4>
<p>Description</p>
</div>
<div class="code-block"><span class="comment"># Example</span>
<span class="key">field</span>: <span class="string">value</span></div>
</div>
```
### Icon List Pattern
```html
<div class="use-cases">
<div class="use-case-item">
<span class="use-case-icon">EMOJI</span>
<div class="use-case-text">
<strong>Title</strong>
<span>Description text</span>
</div>
</div>
</div>
```
## Journey Bar Specific
- `.journey-bar` — Fixed bar below progress bar
- `.journey-bar.hidden` — Hidden on title slide
- Journey bar color transitions from red (0%) to green (100%) via HSL interpolation
- Weight badges are auto-injected by JS into `h1` elements of weighted slides
@@ -0,0 +1,153 @@
---
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
---
# The "Vibe Coding to Agentic Engineering" Framework
This skill teaches the **conceptual model** behind the presentation. Every slide, section, and weight exists to tell a single story: how a developer incrementally moves from unstructured "vibe coding" (0%) to fully agentic engineering (100%).
## Core Concept
**Vibe Coding (0%)** 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 (100%)** 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 Running Example: TodoApp Monorepo
Every technique is demonstrated on a realistic full-stack project:
```
todoapp/
├── backend/ # FastAPI (Python)
│ ├── main.py # App entry + CORS
│ ├── models.py # SQLAlchemy models
│ ├── routes/
│ │ └── todos.py # CRUD endpoints
│ └── tests/
│ └── test_todos.py
├── frontend/ # Next.js (TypeScript)
│ ├── components/
│ │ ├── TodoList.tsx
│ │ └── Sidebar.tsx
│ ├── pages/
│ └── styles/ # Tailwind tokens
└── CLAUDE.md
```
**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 Journey Arc: Why This Order
The presentation follows a deliberate pedagogical sequence. Each section unlocks a new capability layer:
### Part 0: Introduction (Slides 14, no weight)
**Purpose:** Set the stage. Introduce the TodoApp, define vibe coding, and show the destination.
- Title slide establishes the journey metaphor
- Example Project introduces the codebase all examples will reference
- "What is Vibe Coding?" creates the 0% baseline — the pain point
- Journey Map provides a clickable TOC showing the full path ahead
### Part 1: Prerequisites (Slides 59, no weight)
**Purpose:** Get Claude Code installed and running. This is purely logistical — no engineering practices yet.
- Installing, authentication, first session, interface overview
- No weight because knowing how to install a tool doesn't improve code quality
- The "first session" IS vibe coding — this is intentional, so the developer experiences the 0% state firsthand
### Part 2: Better Prompting (Slides 1017, journey 0% → 20%)
**Purpose:** The first real improvement. Better inputs produce better outputs, even without any project configuration.
- **Good vs Bad Prompts (+5%):** Specific, scoped prompts vs vague requests. The simplest possible improvement.
- **Providing Context (+5%):** Using `@files` to give Claude the code it needs. Reduces hallucination immediately.
- **Context Window & /compact (+5%):** Understanding the finite context window prevents degraded responses in long sessions.
- **Plan Mode (+5%):** `/plan` forces thinking before coding. Prevents wasted effort on wrong approaches.
**Why 20% total:** Prompting is foundational but limited. It improves individual interactions but doesn't create lasting project knowledge. Each session starts from zero.
### Part 3: Project Memory (Slides 1824, journey 20% → 40%)
**Purpose:** The leap from session-level to project-level knowledge. Claude now remembers across sessions.
- **CLAUDE.md & /init (+5%):** The project's "README for Claude." Establishes architecture, tech stack, and conventions. This is the single most impactful file.
- **What to Include (+5%):** Practical guidance on writing effective CLAUDE.md content (keep under 150 lines, focus on what Claude needs to know).
- **Rules (+10%):** Path-scoped conventions in `.claude/rules/`. This gets **double weight** because 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 20% total:** Project memory transforms Claude from a stateless tool into a context-aware collaborator. But knowledge alone doesn't create workflows.
### Part 4: Structured Workflows (Slides 2528, journey 40% → 50%)
**Purpose:** Systematic approaches that prevent wasted effort and improve execution quality.
- **Task Lists (+5%):** Breaking complex work into trackable steps. Prevents scope drift and ensures completeness.
- **Model Selection (+5%):** Choosing the right model (Opus for architecture, Sonnet for implementation, Haiku for quick tasks) optimizes cost and quality.
**Why 10% total:** Workflows are important but relatively simple concepts. They're enablers for the more powerful systems that follow.
### Part 5: Domain Knowledge (Slides 2933, journey 50% → 65%)
**Purpose:** Reusable, on-demand expertise. Skills are the bridge between static memory (CLAUDE.md/Rules) and dynamic agents.
- **What Are Skills (+5%):** Skills as packaged domain knowledge that Claude loads when relevant. The concept of progressive disclosure.
- **Creating Skills (+5%):** Hands-on: building a `frontend-conventions` skill for the TodoApp that teaches Tailwind tokens, component patterns, and sidebar integration.
- **Skill Frontmatter & Invocation (+5%):** The technical details: YAML frontmatter, manual vs auto-discovery invocation, the `context: fork` option.
**Why 15% total:** 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.
### Part 6: Agentic Engineering (Slides 3446, journey 65% → 100%)
**Purpose:** The destination. Autonomous, specialized agents that coordinate to build features end-to-end.
- **What Are Agents (+5%):** The concept of specialized subagents with constrained tools and preloaded skills.
- **Frontend Engineer Agent (+5%):** A concrete agent that uses the TodoApp's frontend conventions, adds routes to sidebar, follows design tokens. Before/after comparison shows the transformation.
- **Backend Engineer Agent (+5%):** Parallel agent for the backend — follows FastAPI route patterns, SQLAlchemy models, writes tests matching existing style.
- **Commands & Orchestration (+10%):** Double weight because commands are the **capstone pattern**: Command → Agent → Skills. A single `/add-feature` command coordinates frontend + backend agents, each with their own skills, to deliver a complete feature. This is the architectural pinnacle.
- **Hooks & MCP (+5%):** Lifecycle automation (pre-commit checks, sound notifications) and external tool integration. The final automation layer.
- **Command → Agent → Skills (+5%):** The full architecture diagram. Shows how all pieces connect: commands invoke agents, agents load skills, skills provide knowledge. This is the "100% understanding" slide.
**Why 35% total:** This section is the entire point of the presentation. Everything before it was building toward this. The heavy weighting (especially 10% on Commands) reflects that orchestration is the highest-value capability.
### The 100% Slide (Slide 44)
The celebration moment. Shows the complete TodoApp configuration:
- CLAUDE.md for project context
- Rules for path-scoped conventions
- Skills for domain knowledge
- Agents for consistent execution
- Commands for orchestrated workflows
- Hooks for lifecycle automation
- MCP servers for external tools
### Appendix (Slides 47+, no weight)
**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.
## How to Use This Framework When Editing Slides
When creating or modifying slides, consider:
1. **Where does this concept sit on the journey?** A slide about "better error messages in prompts" belongs in Part 2 (prompting). A slide about "agent memory scopes" belongs in Part 6 (agentic).
2. **What's the before/after?** Every weighted slide should implicitly or explicitly show the contrast: what happens at 0% (vibe coding) vs what happens with this technique. Use the TodoApp to make it concrete.
3. **Does the weight feel right?** Foundational but simple concepts get +5%. Multiplier concepts that affect everything downstream get +10%. The total must stay at 100%.
4. **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.
5. **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.
## Weight Reference Table
| # | Slide Name | Section | Weight |
|---|-----------|---------|--------|
| 12 | Good vs Bad Prompts | Part 2: Better Prompting | +5% |
| 13 | Providing Context | Part 2: Better Prompting | +5% |
| 14 | Context Window & /compact | Part 2: Better Prompting | +5% |
| 15 | /plan — Plan Before Code | Part 2: Better Prompting | +5% |
| 19 | CLAUDE.md & /init | Part 3: Project Memory | +5% |
| 20 | What to Include in CLAUDE.md | Part 3: Project Memory | +5% |
| 22 | Rules (.claude/rules/) | Part 3: Project Memory | +10% |
| 26 | Task Lists | Part 4: Structured Workflows | +5% |
| 27 | /model — Model Selection | Part 4: Structured Workflows | +5% |
| 30 | What Are Skills? | Part 5: Domain Knowledge | +5% |
| 31 | Creating Skills: TodoApp Frontend | Part 5: Domain Knowledge | +5% |
| 32 | Skill Frontmatter & Invocation | Part 5: Domain Knowledge | +5% |
| 35 | What Are Agents? | Part 6: Agentic Engineering | +5% |
| 36 | Frontend Engineer Agent | Part 6: Agentic Engineering | +5% |
| 37 | Backend Engineer Agent | Part 6: Agentic Engineering | +5% |
| 41 | Commands & Orchestration | Part 6: Agentic Engineering | +10% |
| 42 | Hooks & MCP Servers | Part 6: Agentic Engineering | +5% |
| 43 | Command → Agent → Skills | Part 6: Agentic Engineering | +5% |
| | | **Total** | **100%** |
+8
View File
@@ -26,6 +26,14 @@ Skills in `.claude/skills/<name>/SKILL.md` use YAML frontmatter:
- `context`: Set to `fork` to run in isolated subagent context
- `allowed-tools`: Restrict which tools Claude can use
### Presentation System
Any request to update, modify, or fix the presentation (`presentation/index.html`) must be handled by the `presentation-curator` agent (`.claude/agents/presentation-curator.md`). Always delegate presentation work to this agent via the Task tool — never edit the presentation directly.
The agent is **self-evolving**: after every execution, it updates its own skills to stay in sync with the presentation. It has three preloaded skills:
- `vibe-to-agentic-framework`: The conceptual framework ("Vibe Coding → Agentic Engineering"), weight rationale, and journey narrative. Updated after every slide change.
- `presentation-structure`: Slide format, weight system, navigation, section ranges. Updated when slides are added/removed/reordered.
- `presentation-styling`: CSS classes, component patterns, syntax highlighting. Updated when new styling patterns are introduced.
### Hooks System
Cross-platform sound notification system in `.claude/hooks/`:
- `scripts/hooks.py`: Main handler for Claude Code hook events
+1046 -1007
View File
File diff suppressed because it is too large Load Diff
+203
View File
@@ -0,0 +1,203 @@
# Plan: Presentation Refactor — "From Vibe Coding to Agentic Engineering"
## Context
The current presentation is an 82-slide onboarding guide organized as a flat reference manual. The user wants to transform it into a **story-driven journey** that shows developers how each Claude Code best practice incrementally moves them from unstructured "vibe coding" (0%) to fully agentic engineering (100%). The presentation should use a **TodoApp monorepo** (FastAPI + Next.js) as a running example throughout.
## Core Concept: The Journey Progress Bar
Every slide shows a fixed bar at the top: `Vibe Coding ←[bar]→ Agentic Engineering` with a percentage (0%→100%). Weighted slides display a `+N%` badge. The bar color transitions from red (0%) to green (100%).
---
## Phase 1: Add Journey Bar Infrastructure (CSS + JS only)
**File:** `presentation/index.html`
### CSS additions (inside `<style>`)
- `.journey-bar` — fixed bar below the existing progress bar with left label "Vibe Coding", center percentage, right label "Agentic Engineering"
- `.journey-track` / `.journey-fill` — the gradient progress track (red→green via HSL interpolation)
- `.weight-badge` — green pill badge showing `+N%` next to slide titles
- Increase `.slide` top padding from 60px → 100px to accommodate the new bar
### JS additions (inside `<script>`)
- Read `data-weight` attributes from slides at page load to build a `SLIDE_WEIGHTS` map
- Pre-compute `cumulativeWeights[]` array (running sum for each slide)
- `updateJourneyBar(slideNum)` — updates fill width, color (HSL hue 0→120), percentage text, and weight badge
- Call `updateJourneyBar()` inside existing `showSlide()` function
- Hide journey bar on slide 1 (title slide)
### HTML addition
- Insert `<div class="journey-bar">` element after the existing progress bar div
**No existing slides are modified in this phase.**
---
## Phase 2: New Opening Slides + Section Dividers
### New slides to create:
| # | Slide | Content |
|---|-------|---------|
| 1 | **Title** | "Claude Code: From Vibe Coding to Agentic Engineering" |
| 2 | **The Example Project** | TodoApp monorepo structure: `/backend` (FastAPI CRUD), `/frontend` (Next.js + sidebar nav) — shown as a code-block directory tree |
| 3 | **What is Vibe Coding?** | Two-column: "What Happens" (bad — random routes, no patterns) vs "What We Want" (good — follows architecture). Establishes the 0% baseline |
| 4 | **Journey Map** | New TOC showing the 6 parts of the journey with clickable navigation |
### New section dividers (replace old ones):
Each shows current journey % and the Part name:
- **Part 2: Better Prompting** (journey: 0%)
- **Part 3: Project Memory** (journey: 20%)
- **Part 4: Structured Workflows** (journey: 40%)
- **Part 5: Domain Knowledge** (journey: 55%)
- **Part 6: Agentic Engineering** (journey: 70%)
- **Appendix: Reference** (no percentage)
### New agent example slides:
- **Frontend Engineer Agent** (+5%) — before/after showing how without the agent Claude creates random pages, with the agent it uses existing sidebar nav, Tailwind tokens, and API client
- **Backend Engineer Agent** (+5%) — before/after showing how the agent follows existing FastAPI route patterns, SQLAlchemy models, and adds tests
- **The 100% Slide** — celebration slide showing the fully agentic TodoApp
---
## Phase 3: Reorder Slides + Assign Weights
### Weight Distribution (must sum to 100%)
| Journey % | Slide Topic | Weight |
|-----------|-------------|--------|
| 0% → 5% | Good vs Bad Prompts | +5% |
| 5% → 10% | Providing Context (@files) | +5% |
| 10% → 15% | Context Window & /compact | +5% |
| 15% → 20% | /plan mode | +5% |
| 20% → 25% | CLAUDE.md & /init | +5% |
| 25% → 30% | What to Include in CLAUDE.md | +5% |
| 30% → 40% | Rules (.claude/rules/) | +10% |
| 40% → 45% | Task Lists | +5% |
| 45% → 50% | /model Selection | +5% |
| 50% → 55% | What Are Skills | +5% |
| 55% → 60% | Creating Skills (TodoApp) | +5% |
| 60% → 65% | Skill Frontmatter & Invocation | +5% |
| 65% → 70% | What Are Agents | +5% |
| 70% → 75% | Frontend Engineer Agent | +5% |
| 75% → 80% | Backend Engineer Agent | +5% |
| 80% → 90% | Commands & Orchestration | +10% |
| 90% → 95% | Hooks + MCP Servers | +5% |
| 95% → 100% | Full Architecture (Command → Agent → Skills) | +5% |
| **Total** | | **100%** |
> **Decisions:** CLAUDE.md/init = +5% (not +10%). Commit/PR workflows = no weight (moved to appendix). Extra 5% redistributed to "Full Architecture" slide as the final capstone.
### New section structure:
**Part 0: Introduction (slides 1-4, no weight)**
- Title, Example Project, What is Vibe Coding, Journey Map
**Part 1: Prerequisites (slides 5-9, no weight)**
- Installing, Login-Subscription, Login-API Key, First Session (this IS vibe coding), The Interface
**Part 2: Better Prompting (slides 10-17, 0%→20%)**
- Section divider, Your First Prompt, Good vs Bad Prompts (+5%), Providing Context (+5%), Context Window & /compact (+5%), /plan mode (+5%), Plan Mode in Practice, Prompting Best Practices
**Part 3: Project Memory (slides 18-24, 20%→45%)**
- Section divider, CLAUDE.md & /init (+10%), What to Include (+5%), Keep Under 150 Lines, Rules (+10%), /memory & Hierarchy, Memory Best Practices
**Part 4: Structured Workflows (slides 25-28, 40%→50%)**
- Section divider, Task Lists (+5%), /model Selection (+5%), Workflow Best Practices
**Part 5: Domain Knowledge (slides 29-33, 50%→65%)**
- Section divider, What Are Skills (+5%), Creating Skills (+5%), Frontmatter & Invocation (+5%), Skills Summary
**Part 6: Agentic Engineering (slides 34-48, 65%→100%)**
- Section divider, What Are Agents (+5%), Frontend Engineer Agent (+5%), Backend Engineer Agent (+5%), Agent Frontmatter, Agent Tools & Skills, Subagents, Commands & Orchestration (+10%), Hooks + MCP (+5%), Full Architecture: Command → Agent → Skills (+5%), The 100% Slide, Agent Memory, Agents Summary
**Appendix: Reference (slides 49+, no weight)**
All non-weighted command references, workflows, and settings slides:
- How Claude Uses Tools, File Operations, Bash & Search
- /help, Effort Level, /fast, /context & /cost, /clear & /rewind, /resume, /doctor, /config, /permissions, /sandbox, Commands Cheat Sheet
- Commit Workflow, PR Workflow, Workflow Best Practices
- Default Main Agent, settings.json, Spinner Verbs, Status Line, Output Styles, Keybindings, Terminal & Vim, Customization Summary
- Debugging Tips, Golden Rules, Resources, Next Steps, Thank You
### Slide merges (reduce total count):
- CLAUDE.md concept + /init command → single slide
- /memory + memory hierarchy → single slide
- Context Window + /compact → single slide
- /plan + Why Plan First → single slide
- Hooks + Plugins + MCP → combined slide
### Renumbering approach:
After all moves/merges, run a Python script to:
1. Renumber all `data-slide` attributes sequentially (1, 2, 3, ...)
2. Update `totalSlides` in JS
3. Update slide counter text
4. Update `goToSlide()` calls in TOC
---
## Phase 4: Thread TodoApp Examples (Detailed Code Snippets)
Update existing slides with **detailed, realistic code snippets** from the TodoApp:
- **Good vs Bad Prompts**: Show actual FastAPI route code — bad prompt produces random `/notes` endpoint, good prompt targets existing `/api/todos` with validation
- **Providing Context**: Full `@backend/routes/todos.py` reference showing actual route definitions, `@frontend/components/TodoList.tsx` with component code
- **CLAUDE.md**: Full TodoApp CLAUDE.md example (~20 lines) showing project structure, tech stack, conventions, API patterns
- **Rules**: Complete `backend-testing.md` rule scoped to `backend/tests/**` with pytest conventions, fixture patterns, assertion style
- **Skills**: Full `frontend-conventions/SKILL.md` with Tailwind tokens, component patterns, sidebar navigation integration rules
- **Frontend Agent**: Complete `.claude/agents/frontend-engineer.md` frontmatter + instructions showing how it uses existing `/frontend/components/`, adds routes to sidebar layout, follows design tokens
- **Backend Agent**: Complete `.claude/agents/backend-engineer.md` with FastAPI route patterns, SQLAlchemy model conventions, test requirements
- **Commands & Orchestration**: Full TodoApp feature workflow command showing how it coordinates frontend + backend agents
---
## Phase 5: Create `/update-presentation` Command Pipeline
Following the weather orchestration pattern (Command → Agent → Skills):
### Files to create:
| File | Purpose |
|------|---------|
| `.claude/commands/update-presentation.md` | Entry point command — asks user what to change, invokes agent via Task tool |
| `.claude/agents/presentation-updater.md` | Agent with preloaded skills — handles content/structure changes |
| `.claude/skills/presentation-structure/SKILL.md` | Knowledge about slide format, weight system, JS navigation |
| `.claude/skills/presentation-styling/SKILL.md` | Knowledge about CSS classes, component patterns, syntax highlighting |
### Command flow:
```
User runs /update-presentation
→ Command asks what changes are needed (AskUserQuestion)
→ Command invokes presentation-updater agent (Task tool)
→ Agent reads presentation-structure skill (understands format)
→ Agent reads presentation-styling skill (matches conventions)
→ Agent makes changes, renumbers slides, verifies weights = 100%
```
---
## Execution Order
1. **Phase 1** (Infrastructure) — safest, no content changes, testable immediately
2. **Phase 5** (Command pipeline) — new files only, no HTML changes
3. **Phase 2** (New slides) — insert new content, existing slides untouched
4. **Phase 3** (Reorder) — highest risk, full restructure
5. **Phase 4** (TodoApp examples) — update content within finalized structure
Work on a git branch: `presentation-refactor`
## Verification
After completion, validate in browser console:
```javascript
const slides = document.querySelectorAll('[data-slide]');
console.log('Total slides:', slides.length);
let weightSum = 0;
slides.forEach(s => { weightSum += parseInt(s.dataset.weight || 0); });
console.log('Weight sum:', weightSum, weightSum === 100 ? 'OK' : 'ERROR');
let ok = true;
slides.forEach((s, i) => {
if (parseInt(s.dataset.slide) !== i + 1) { ok = false; console.error('Gap at', i+1); }
});
console.log('Sequential numbering:', ok ? 'OK' : 'ERROR');
```