gilles/claude-code-best-practice
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

added presentation

Browse Source
This commit is contained in:
Shayan Rais
2026-03-05 13:00:11 +05:00
parent 99949d47dd
commit f467c65daa
8 changed files with 909 additions and 192 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/agents/presentation-curator.md
+17 -14
View File
@@ -23,8 +23,8 @@ Apply the requested changes to the presentation while maintaining structural int
### 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 slide format (`data-slide` and `data-level` attributes)
- The journey bar level system (Low/Medium/High/Pro — 4 discrete levels)
- The section structure (Parts 0-6 + Appendix)
- How slide numbering works
@@ -34,7 +34,7 @@ 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%
- **Level changes**: Update `data-level` attributes on section-divider slides (3 transition points in main presentation: Low at slide 10, Medium at slide 18, High at slide 29; Part 6 at slide 34 also uses `high` — the presentation caps at High, not Pro)
- **Styling changes**: Update CSS within the `<style>` block, matching existing patterns
### Step 3: Match Styling (presentation-styling skill)
@@ -48,14 +48,14 @@ Follow the presentation-styling skill to ensure:
After changes, verify:
1. All `data-slide` attributes are sequential (1, 2, 3, ...)
2. All `data-weight` values sum to exactly 100
2. `data-level` transitions exist at section dividers: slide 10 (`low`), 18 (`medium`), 29 (`high`), 34 (`high`) — the main presentation caps at High, not Pro
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
6. Weighted slide titles in `vibe-to-agentic-framework` match actual `<h1>` titles in `presentation/index.html`
6. Level transition slides in `vibe-to-agentic-framework` match actual `<h1>` titles in `presentation/index.html`
7. Agent identifiers are consistent across examples (use `frontend-engineer` / `backend-engineer`; do not introduce aliases like `frontend-eng`)
8. Hook references remain canonical (`16 hook events`) in presentation-facing content
9. Do not manually insert `.weight-badge` markup in slide HTML (badges are JS-injected)
9. Do not manually insert `.level-badge` or `.weight-badge` markup in slide HTML (badges are JS-injected)
10. Settings precedence text must separate user-writable override order from enforced policy (`managed-settings.json`)
11. If slide 32 is touched, ensure skill frontmatter coverage includes `context: fork`
12. Keep the framework skill identity canonical: `presentation/vibe-to-agentic-framework` (do not rename to variants)
@@ -68,17 +68,17 @@ After completing changes to the presentation, you MUST update your own knowledge
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.
- **Level Transition Table**: If any level transitions were added, removed, or changed, update the table to reflect actual `data-level` attributes and their slide numbers. 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.
- **Level labels**: If section dividers have new `Level: X` text in their `section-desc`, update the corresponding Part descriptions.
- **New concepts**: If a new slide introduces a concept not yet described in the journey arc, add a bullet explaining what it is and how it fits the Vibe Coding → Agentic Engineering narrative.
- **Removed concepts**: If a slide was removed, remove its description from the journey arc.
#### 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.
- **Level Transitions table**: Update section slide ranges and level assignments to match the current presentation.
- **Section divider examples**: If section divider format changed, update the example HTML.
#### 5c. Cross-Doc Consistency (when claims change)
@@ -99,14 +99,17 @@ _Findings from previous executions are recorded here. Add new entries as bullet
- Hook-event references drifted across files. Treat `16 hook events` as canonical and sync all docs in the same run.
- Do not use shorthand agent names in examples (`frontend-eng`). Keep identifiers exactly aligned with agent definitions.
- Never hardcode `.weight-badge` in slide HTML; badges are runtime-injected.
- Never hardcode `.weight-badge` or `.level-badge` in slide HTML; badges are runtime-injected by JS.
- Keep the framework skill name stable as `vibe-to-agentic-framework` to avoid broken skill references.
- When updating slide 2 (TodoApp structure) to show before/after comparison, the `.two-col` layout works well with centered h3 headers using inline styles for red/green color coding. Update framework skill's Part 0 description and TodoApp example section to reflect the new before/after structure.
- The journey bar was refactored from a percentage-based system (`data-weight` attributes summing to 100%) to a 4-level system (`data-level` attributes: low/medium/high/pro). The `.journey-track-wrap` wrapper div is required to display the ticks column alongside the bar without being clipped by `overflow: hidden`. The level transitions in the main presentation are at section dividers only (slides 10, 18, 29, 34). The video presentation (`!/video-presentation-transcript/1-video-workflow.html`) uses the same system with its own level transitions at slides 2 (low) and 7 (medium).
- The main presentation caps at **High** level (not Pro). Slide 34 uses `data-level="high"`. The Pro tick on the journey bar remains as a visual scale marker showing the theoretical ceiling, but the fill never reaches it. Do not assign `data-level="pro"` to any slide in the main presentation.
- Journey bar top/bottom labels (`journey-label-top` / `journey-label-bottom`) were removed from both presentation files. The current-level indicator now uses the format `Current = <strong>Level</strong>` rendered via `innerHTML` in the JS `updateJourneyBar` function. The `journey-level-label` CSS class was updated to use lighter, smaller styling (font-weight: 400, font-size: 0.65rem, color: #777) since the label word is now light and only the bold `<strong>` element is accented.
## Critical Requirements
1. **Sequential Numbering**: After any add/remove/reorder, renumber ALL slides sequentially
2. **Weight Integrity**: Weighted slides must sum to exactly 100%
2. **Level Integrity**: The main presentation has `data-level` transitions at slides 10 (low), 18 (medium), 29 (high), 34 (high). It caps at High — `data-level="pro"` is NOT used in the main presentation. The Pro tick mark on the bar is a visual reference marker only.
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)
@@ -115,5 +118,5 @@ _Findings from previous executions are recorded here. Add new entries as bullet
After completing changes, report:
- What slides were changed
- Current total slide count
- Current weight sum (should be 100%)
- Current level transitions (which slides carry `data-level`)
- Any renumbering that occurred
.claude/skills/presentation/presentation-structure/SKILL.md
+31 -26
View File
@@ -13,19 +13,19 @@ Knowledge about how the presentation at `presentation/index.html` is structured.
## Slide Format
Each slide is a div with `data-slide` (sequential number) and optional `data-weight` (journey percentage):
Each slide is a div with `data-slide` (sequential number) and optional `data-level` (journey level at transition points):
```html
<!-- Regular slide -->
<div class="slide" data-slide="12" data-weight="5">
<!-- Regular slide — inherits level from previous data-level slide -->
<div class="slide" data-slide="12">
<h1>Slide Title</h1>
<!-- content -->
</div>
<!-- Section divider slide -->
<div class="slide section-slide" data-slide="10">
<!-- Level transition slide — sets new level for this slide and all following -->
<div class="slide section-slide" data-slide="10" data-level="low">
<h1>Section Name</h1>
<p class="section-desc">Description of this section</p>
<p class="section-desc">Level: Low — description of this section</p>
</div>
<!-- Title slide (centered) -->
@@ -35,26 +35,29 @@ Each slide is a div with `data-slide` (sequential number) and optional `data-wei
</div>
```
## Journey Bar Weight System
## Journey Bar Level 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)
The presentation uses a 4-level system instead of cumulative percentages:
### Weight Distribution by Section
- Levels are set via `data-level` attribute on key transition slides (section dividers)
- All slides after a `data-level` slide inherit that level until the next transition
- The journey bar fills to 25% / 50% / 75% / 100% for Low / Medium / High / Pro respectively
- The bar is hidden on slide 1 (title slide); from slide 2 onward the bar is shown
- Slides before the first `data-level` (slides 2–9) show an empty bar (no level yet set)
- A `.level-badge` is JS-injected on the `<h1>` of slides that carry `data-level` — do NOT hardcode in HTML
| 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% |
### Level Transitions by Section
| Section | Slide Range | data-level | Bar Height |
|---------|-------------|------------|------------|
| Part 0: Introduction | Slides 1-4 | (none) | hidden / empty |
| Part 1: Prerequisites | Slides 5-9 | (none) | empty |
| Part 2: Better Prompting | Slides 10-17 | `low` | 25% |
| Part 3: Project Memory | Slides 18-24 | `medium` | 50% |
| Part 4: Structured Workflows | Slides 25-28 | (inherits medium) | 50% |
| Part 5: Domain Knowledge | Slides 29-33 | `high` | 75% |
| Part 6: Agentic Engineering | Slides 34-46 | `high` | 75% |
| Appendix | Slides 47+ | (inherits high) | 75% |
## Navigation System
@@ -73,12 +76,14 @@ After adding, removing, or reordering slides:
## Section Divider Format
Section dividers use the `section-slide` class and show the current journey percentage:
Section dividers use the `section-slide` class. Level-transition section dividers carry `data-level` and show the level name in the description:
```html
<div class="slide section-slide" data-slide="10">
<div class="slide section-slide" data-slide="10" data-level="low">
<p class="section-number">Part 2</p>
<h1>Better Prompting</h1>
<p class="section-desc">Journey: 0% — effective prompting for real results.</p>
<p class="section-desc">Level: Low — effective prompting for real results.</p>
</div>
```
The JS will inject a `.level-badge` (e.g., "→ Low") into the `<h1>` at runtime when the level transitions — do not add these manually in HTML.
.claude/skills/presentation/vibe-to-agentic-framework/SKILL.md
+60 -58
View File
@@ -5,16 +5,29 @@ description: The conceptual framework behind the presentation — what "Vibe Cod
# 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%).
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).
## 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.
**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 (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.
**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 4-Level Journey System
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).
## The Running Example: TodoApp Monorepo
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):
@@ -73,50 +86,50 @@ The presentation follows a deliberate pedagogical sequence. Each section unlocks
- 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%)
### Part 2: Better Prompting (Slides 10–17, Level: Low)
**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.
- **Good vs Bad Prompts:** Specific, scoped prompts vs vague requests. The simplest possible improvement.
- **Providing Context:** Using `@files` to give Claude the code it needs. Reduces hallucination immediately.
- **Context Window & /compact:** Understanding the finite context window prevents degraded responses in long sessions.
- **Plan Mode:** `/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.
**Why Low level:** 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%)
### Part 3: Project Memory (Slides 18–24, Level: Medium)
**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.
- **CLAUDE.md & /init:** The project's "README for Claude." Establishes architecture, tech stack, and conventions. This is the single most impactful file.
- **What to Include:** Practical guidance on writing effective CLAUDE.md content (keep under 150 lines, focus on what Claude needs to know).
- **Rules:** Path-scoped conventions in `.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 20% total:** Project memory transforms Claude from a stateless tool into a context-aware collaborator. But knowledge alone doesn't create workflows.
**Why Medium level:** 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%)
### Part 4: Structured Workflows (Slides 25–28, Level: Medium)
**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.
- **Task Lists:** Breaking complex work into trackable steps. Prevents scope drift and ensures completeness.
- **Model Selection:** 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.
**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.
### Part 5: Domain Knowledge (Slides 29–33, journey 50% → 65%)
### Part 5: Domain Knowledge (Slides 29–33, Level: High)
**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.
- **What Are Skills:** Skills as packaged domain knowledge that Claude loads when relevant. The concept of progressive disclosure.
- **Creating Skills:** Hands-on: building a `frontend-conventions` skill for the TodoApp that teaches Tailwind tokens, component patterns, and sidebar integration.
- **Skill Frontmatter & Invocation:** 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.
**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.
### 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.
### Part 6: Agentic Engineering (Slides 34–46, Level: High)
**Purpose:** The destination covered in this presentation. Autonomous, specialized agents that coordinate to build features end-to-end.
- **What Are Agents:** The concept of specialized subagents with constrained tools and preloaded skills.
- **Frontend Engineer Agent:** 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:** Parallel agent for the backend — follows FastAPI route patterns, SQLAlchemy models, writes tests matching existing style.
- **Commands & Orchestration:** 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:** Lifecycle automation (pre-commit checks, sound notifications) and external tool integration. The final automation layer.
- **Command → Agent → Skills:** The full architecture diagram. Shows how all pieces connect: commands invoke agents, agents load skills, skills provide knowledge. This is the "High level" 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.
**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 100% Slide (Slide 44)
### The High Level Slide (Slide 44)
The celebration moment. Shows the complete TodoApp configuration:
- CLAUDE.md for project context
- Rules for path-scoped conventions
@@ -133,36 +146,25 @@ The celebration moment. Shows the complete TodoApp configuration:
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).
1. **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).
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.
2. **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.
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%.
3. **Does the level assignment feel right?** Level transitions happen at Part section boundaries. Individual slides within a section inherit the section's level.
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
## Level Transition 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%** |
| 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.