added vibe-to-agentic framework
This commit is contained in:
@@ -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 19–25 instead of 18–24), 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">></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 1–4, 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 5–9, 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 10–17, 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 18–24, 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 25–28, 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 29–33, 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 34–46, 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%** |
|
||||
@@ -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
File diff suppressed because it is too large
Load Diff
@@ -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');
|
||||
```
|
||||
Reference in New Issue
Block a user