Enforces development within an existing educational content synthesis codebase. Prevents creation of parallel systems and ensures enhancements to the existing lesson player architecture.
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.
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.
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
Before making any changes, understand these key components:
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.
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
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`
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
**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)
Never do any of the following:
Your work is successful when:
**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`
**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`
**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
When you receive requests that might violate these principles:
Leave a review
No reviews yet. Be the first to review this skill!
# Download SKILL.md from killerskills.ai/api/skills/ilearn-how-real-time-educational-synthesis/raw