← Back to Overview

Orchestrator & Phase Pipeline

The 7-phase execution model of the skill — from bootstrap to transparency report

01

The 7 Phases Overview

The orchestrator controls the entire generation process through seven sequential phases. Each phase has clearly defined inputs, outputs, and abort conditions. No phase may be skipped — the skill enforces the order.

🏗️ Phase 0 Bootstrap
🔍 Phase 1 Analysis
📋 Phase 2 Curriculum
🎨 Phase 3 Foundation
🔨 Phase 4 Build
Phase 5 Polish
🗺️ Phase 6 Depth Map

Design decision: Phases 0–3 run strictly sequentially. Phase 4 contains parallel sub-pipelines per audience. Phases 5–6 are post-processing steps that operate on the complete output of all pipelines.

02

Phases 0–2: Preparation

The preparation phases run strictly sequentially. Each phase must complete fully before the next begins. By the end of Phase 2, the complete curriculum for all audiences is ready.

Phase 0 — Bootstrap
Source Identification
The skill automatically detects whether the input is a local path, a GitHub URL, or the current working directory. For GitHub, a git clone is executed.
HARD BLOCK: Decision Gate
Two questions must be answered before Phase 1 starts: (1) audience selection, (2) integration mode. There are no defaults — the skill blocks until both are answered.
Blocking
Phase 1 — Analysis

Deep codebase understanding: the skill reads all relevant files, traces data flows, and identifies the "main characters" of the software — core modules, API endpoints, configuration files, and their relationships.

// What Phase 1 captures: Languages & Frameworks → TypeScript, React, Express, ... Architecture Patterns → Monolith, Microservices, Event-Driven, ... Data Flows → API → Service → Repository → DB Main Characters → Core modules, entry points, configuration Dependencies → package.json, requirements.txt, go.mod, ...
Phase 2 — Curriculum

A separate curriculum is created for each audience. Every module receives a Helpfulness Score (HS) that determines whether a drill-down page is built.

// Helpfulness Score Formula HS(topic, audience) = w1 * relevance(topic, audience.role) + w2 * complexity(topic) + w3 * dependency_count(topic) + w4 * source_depth(topic) // Weights (audience-dependent): Decision-Maker: w1=0.5, w2=0.1, w3=0.1, w4=0.3 End User: w1=0.4, w2=0.2, w3=0.2, w4=0.2 Developer: w1=0.2, w2=0.3, w3=0.3, w4=0.2 // Threshold: HS ≥ 7 → drill-down page is built // Threshold: HS ≥ 5 → topic stays in curriculum, no dedicated page // Threshold: HS < 5 → topic is skipped

Helpfulness Score (HS): Each topic is scored individually for each audience. The formula weighs four factors: relevance to the role, topic complexity, number of dependencies, and source code depth. Developer topics weigh complexity and dependencies more heavily; decision-maker topics weigh relevance and source depth more. A score of 7 or above triggers the creation of a dedicated drill-down page.

03

Phase 3: The Design System

The CSS/JS foundation is created once and then embedded into every HTML file. The self-contained principle: every file is fully standalone — no external stylesheets, no bundlers, no build step.

🎨
CSS Variables
Color palette, typography, spacing, radii, shadows — all centrally defined in :root. Changes in one place propagate globally.
:root{}
📱
Responsive
Three breakpoints: Desktop (>768px), Tablet (480–768px), Mobile (<480px). Scroll-snap for modules, flexible grids for cards.
@media
Animations
Intersection-Observer-based fade-in animations, staggered children, smooth hover transitions. All GPU-accelerated via transform.
IntersectionObserver
// Foundation Components (Phase 3 Output) CSS Variables --color-* // 18 color variables --font-* // 3 font stacks (Display, Body, Mono) --text-* // 10 size steps --space-* // 12 spacing values --radius-* // 4 border radii --shadow-* // 3 shadows --ease-*, --duration-* // Timing Component Classes .module, .module-hero // Sections .card, .cards-grid // Card layouts .viz-box, .viz-flow // Visualizations .quiz, .quiz-option // Interactive quizzes .timeline, .file-tree // Code displays .nav-deep, .breadcrumb // Navigation .deep-dive-link // Drill-down links .sibling-nav // Sibling navigation JavaScript IntersectionObserver // Scroll animations Quiz Engine // Interactive tests Tooltip System // Term explanations Progress Bar // Scroll progress

Self-Contained Principle: Phase 3 produces a complete CSS/JS foundation with 18 color variables, 3 font stacks, 10 size steps, 12 spacing values, and all component classes (modules, cards, visualizations, quizzes, navigation). Plus four JavaScript systems: scroll animations, quiz engine, tooltips, and progress bar. This entire package is copied into the <style> and <script> block of every single HTML file.

Order constraint: Phase 3 must complete before any HTML generation. The orchestrator checks this explicitly — if the foundation does not exist, Phase 4 will not start.

04

Phase 4: Audience Pipelines

The key innovation of the skill: each audience gets its own independent pipeline. Pipelines can run in parallel (in practice often sequential, as LLM context is limited). Within a pipeline, levels are built one at a time.

Pipeline Overview: Audiences × Depth Levels

📊 Decision-Maker
L0
L1
max L1
👤 End User
L0
L1
L2
max L2
🔧 Developer
L0
L1
L2
L3
max L3
// Pipeline Execution Model for each audience in selected_audiences: for level in 0..audience.max_level: for theme in curriculum[audience][level]: if theme.hs_score ≥ threshold[level]: build_page(theme, audience, level, "de") build_page(theme, audience, level, "en") // Within a level: themes + languages can be parallelized // Next level only after all pages of current level are done // Pipeline independent of other pipelines // Important: Pipelines are INDEPENDENT of each other // The Developer pipeline can build L2 // while the Decision-Maker pipeline is still on L0.

Pipeline logic: Each audience progresses through its levels sequentially (L0 must be complete before L1 begins). Within a level, themes and language versions can be built in parallel. Pipelines of different audiences are fully independent — the Developer pipeline can already be at L2 while the Decision-Maker pipeline is still generating L0.

✏️ Quick Check

Can the Developer pipeline build L2 while the Decision-Maker pipeline is still on L0?

Yes — pipelines are independent of each other
No — all pipelines must be on the same level
Only if the Decision-Maker pipeline has fewer topics
In Detail Phase Control in Detail → Internal state machine, error handling, and abort conditions of the pipeline
05

Phases 5–6: Finishing

The final two phases operate on the complete output of all pipelines. Phase 5 ensures consistency, Phase 6 produces the transparency report.

Phase 5: Polish
• Insert audience-switch links on all L0 pages • Verify all cross-level links (L0→L1→L2→...) • Check breadcrumbs for consistency • Validate all relative paths (../l1/, ../l2/) • Cross-check language versions (DE ↔ EN)
🗺️
Phase 6: Depth Map
What was built: List of all generated HTML files What was skipped: Topics with HS below threshold Why: HS scores and stop reasons per topic Statistics: Files per audience, levels, languages • Output: tiefenkarte.html
// Depth Map Output Structure depth_map: audiences: - name: "Developer" max_level: 3 pages_built: 14 pages_skipped: 3 themes: - name: "Orchestrator" hs_score: 9.2 levels_built: [L0, L1, L2] stop_reason: "max_level_reached" - name: "Error Handling" hs_score: 4.1 levels_built: [] stop_reason: "hs_below_threshold"

Depth Map: The transparency report lists for each audience which topics were built at which levels, which were skipped, and why. Each topic includes its HS score and the specific stop reason (e.g., "threshold not met" or "maximum depth reached").