iLearn How Real-Time Educational Synthesis

This skill ensures development work stays within the boundaries of an existing real-time educational content synthesis engine, preventing common antipatterns like creating parallel systems or standalone test pages.

Overview

The iLearn How codebase is a complete educational content synthesis system built around a 2,618-line `index.html` main interface with integrated curriculum data, variant generation, lesson player, and audio systems. This skill enforces architectural discipline by preventing the creation of new standalone pages and ensuring all work enhances the existing system.

Core Principles

Follow these principles strictly when working with this codebase:

1. **Never create new HTML pages** - No `working-version.html`, `test-*.html`, `diagnostic.html`, or any other HTML files

2. **Work within existing structure** - The 2,618-line `index.html` is the main interface and must be enhanced, not replaced

3. **No parallel systems** - Never create alternative implementations of existing functionality

4. **Real functionality only** - Implement actual working features, never placeholders or mockups

5. **Use existing architecture** - Leverage the established curriculum, variant, and player systems

Existing Architecture

Before making any changes, understand these key components:

Core Files

System Integration

All systems are designed to work together within the single `index.html` interface. The lesson player consumes curriculum data, generates variants, and integrates audio playback.

Step-by-Step Instructions

When Asked to Add Features

1. **Locate the relevant section** in `index.html` where the feature should be integrated

2. **Review existing patterns** - Look at how similar features are implemented

3. **Enhance in place** - Add functionality within the existing structure

4. **Test within the main interface** - Use the existing UI for validation

5. **Verify integration** - Ensure new code works with curriculum, variants, and audio systems

When Asked to Fix Bugs

1. **Identify the specific file** where the bug exists (likely `index.html` or one of the JS modules)

2. **Read the surrounding code** to understand the context

3. **Fix the bug in place** - Never extract code into new files

4. **Test using the existing interface** - Validate the fix within `index.html`

When Asked to Test or Demonstrate

1. **Use the existing `index.html`** as the testing interface

2. **Load real curriculum data** from the `data/` directory

3. **Demonstrate within the lesson player** using actual variant generation

4. **Show audio integration** working with ElevenLabs functionality

5. **Never create diagnostic or test pages** - all testing happens in the main interface

When Tempted to Create New Files

**STOP. Ask these questions:**

1. Can this be added to `index.html`? (Answer: Almost always yes)

2. Can this enhance an existing JS module? (Answer: Usually yes)

3. Is this truly a new shared utility? (Answer: Rarely - check existing modules first)

4. Am I trying to work around the existing architecture? (If yes, don't create the file)

Forbidden Actions

Never do any of the following:

Success Criteria

Your work is successful when:

Example Scenarios

Scenario: "Add a progress tracker"

**Wrong approach:** Create `progress-tracker.html` to test the feature

**Correct approach:** Add progress tracking UI and logic to the existing `index.html`, integrate with `complete-lesson-player.js`

Scenario: "Fix lesson loading bug"

**Wrong approach:** Create `debug-lesson-loader.html` to diagnose

**Correct approach:** Debug within `index.html`, fix the issue in `complete-curriculum.js` or `complete-lesson-player.js`

Scenario: "Test variant generation"

**Wrong approach:** Create `test-variants.html` to demonstrate

**Correct approach:** Use the existing `index.html` interface, load curriculum data, and show variants within the lesson player

Enforcement Reminders

When you receive requests that might violate these principles:

Important Notes