Domain context scenario builder
Skill alainlebret/claude-agents/higher-ed-teaching-agents/skills/domain-context-scenario-builder
Modular skill and workflow ecosystems for AI coding assistants. Structured, multi-agent pipelines for specialized professional domains.
npx -y skills add alainlebret/claude-agents --skill domain-context-scenario-builderAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.md
3.1 KB, as published. Nobody here has run it
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 → audienceis 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-builderis listed in a workflow'soptional_skills.
Inputs
mission.json— level, domain (if specified incontext), constraintsstatement.mdor 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.