# Domain Context Scenario Builder

> Transforms generic computing content into credible domain scenarios such as aeronautics, banking, cybersecurity, embedded systems, drones, telecom, energy, or healthcare. Use when the material must be contextualized for a profession, sector, or reskilling audience.

- Skill: `alainlebret/domain-context-scenario-builder` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add alainlebret/domain-context-scenario-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alainlebret/domain-context-scenario-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: alainlebret (https://skillmd.com/u/alainlebret)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alainlebret/domain-context-scenario-builder

---


# Domain Context Scenario Builder

## Goal

Replace the generic framing of a computing exercise (« écrire un programme qui trie une liste ») with a credible, engaging domain scenario that gives students a realistic professional context without adding technical complexity beyond what the pedagogical objectives require.

## When to use

- When `mission.json → audience` is a reskilling or professional audience who expects industry relevance.
- When a generic exam question needs to be dressed in a sector-specific narrative.
- When `domain-context-scenario-builder` is listed in a workflow's `optional_skills`.

## Inputs

- `mission.json` — level, domain (if specified in `context`), constraints
- `statement.md` or draft statement — the generic version to be contextualised

## Output contract

| File | Description |
|---|---|
| `statement.md` (updated) | Revised statement with domain scenario embedded. Core technical requirements unchanged. |
| `scenario-rationale.md` | Explanation of domain choices: why this sector, which real-world constraints are reflected, what was simplified and why |

## Supported domains

| Domain | Typical system | Example scenario |
|---|---|---|
| Aeronautics / drones | Embedded flight computer, telemetry | Log parser for UAV telemetry streams |
| Banking / fintech | Transaction processor, reconciliation | Multi-threaded ledger with atomic transfers |
| Cybersecurity | IDS, packet inspector | Log anomaly detector using sliding window |
| Embedded / IoT | Sensor hub, CAN bus | Real-time sensor aggregator with timeout handling |
| Telecom | SIP proxy, billing engine | CDR parser with rate limiting |
| Healthcare | Medical device firmware, EHR sync | Patient data anonymisation pipeline |
| Energy | SCADA, smart grid | Demand-response scheduler with constraints |

## Rules

- The domain framing must not increase the cognitive load of the exercise. If the scenario introduces vocabulary students must learn first, simplify it.
- Technical requirements (input/output format, language, tools) remain exactly as defined in `mission.json`.
- State explicitly what is realistic and what is simplified. Do not mislead students into thinking the scenario is production-grade.
- Use fictional but plausible entity names (companies, systems, datasets) — never real company names or real systems.
- The scenario must be consistent with the academic level: an L2 student should not need industry knowledge to understand the context.

## Anti-patterns

- Scenarios that require understanding domain-specific regulations (GDPR, DO-178C) when those are not in the learning objectives.
- Scenarios that imply a specific implementation architecture that conflicts with the reference solution.
- Names or situations that could be culturally insensitive or politically charged.