Extract visual formatting/styling from a SCREENSHOT of a web application and output it as machine-readable JSON — colors & typography, spacing & sizing, and component styles (buttons, inputs, cards, badges) — structured so a developer can rebuild the UI in code. Use this whenever the user gives a screenshot, image, or mockup of a web app / dashboard / website and wants the formatting, styling, design tokens, CSS values, color palette, fonts, spacing, or "how it looks" pulled out into JSON (or asks to reverse-engineer / clone / reproduce a UI's look from a picture). Trigger even if they just say "get the styling out of this screenshot" or "what colors and fonts is this using" — as long as the input is an image and they want structured formatting data back. Does NOT cover layout/DOM structure extraction, nor reading styles from live HTML/CSS (this is for images).
Build a clickable web-app prototype by combining a Domain Story (which supplies the STRUCTURE — screens, flows, entities, roles, state machines) with a screenshot / mockup (which supplies the VISUAL STYLE — colors, typography, spacing, component looks). Orchestrates the domain-story-interpreter and webapp-style-extractor skills, then assembles a navigable, interactive prototype that behaves like the story and looks like the screenshot. Use whenever the user gives a domain story (or an actor→activity→work-object diagram) AND a screenshot / UI image and wants a working, clickable, or navigable prototype / app / mockup styled to match the screenshot — e.g. "build a prototype from this domain story in the style of this screenshot", "make a clickable app from my domain story that looks like this UI", "turn this domain story into a working prototype matching this design". Trigger even if only one input is named, as long as the goal is a styled clickable prototype from a domain story — then ask for the other.
Act as a respectful, open Devil's Advocate who critiques a Domain Story (a Domain Storytelling diagram in the Hofer & Schwentner pictographic language). Work through its building blocks — actors, activities/verbs, work objects, sequence, groups/lanes — to surface CRUD-or-UI verbs posing as domain language, collapsed or missing actors, missing external systems, states dressed up as work objects, and out-of-order steps, then stress-test the whole as ONE concrete scenario (no hidden branches; consistent granularity and as-is/to-be scope). Use whenever someone shares or describes a domain story or a numbered actor→activity→work-object diagram and wants it challenged, reviewed, or "poked for holes" — even if they never say "Domain Storytelling." It may stand alone or be checked for fidelity to a related artifact the user provides: an EventStorming board, a brainstorm photo, a Wardley or Capability map, a Business Model Canvas, or a Visual Glossary whose terms the story must reuse. Grounded in Hofer & Schwentner.
Prepare a Domain Storytelling session by generating sample ("seed" or strawman) domain stories as text — numbered sentences in the actor → activity → work object grammar. Optionally derives them from a Wardley Map and/or a Capability Map: when the prompt doesn't already name a focus, the skill lists the map's components or capabilities and asks the user to pick up to three to center the stories on (the map itself is optional; a one-line domain description also works). Use whenever someone wants to seed, draft, generate, author, or prepare sample domain stories, kick off / warm up / prep a Domain Storytelling or event-storming-style workshop, turn a Wardley Map or Capability Map into a worked example scenario, or produce a numbered actor-action-work-object story to put in front of a room — even if they don't say "Domain Storytelling." This is the complement of interpreting a domain story: here you PRODUCE the story rather than read one.
Author AsyncAPI 3.1.0 event-driven API specifications in YAML following a consistent, componentized house style (the same style as the bundled Task Management example). Use this skill whenever the user wants to create, write, draft, design, scaffold, or extend an AsyncAPI specification, model an event-driven / message-driven / pub-sub / streaming API, describe Kafka, MQTT, AMQP, WebSocket, or other broker topics, channels, messages, or events, or produce an asyncapi.yaml file — even if they don't say "AsyncAPI 3.1.0" explicitly. Also use it when adding channels, operations, messages, or schemas to an existing spec so the additions match the house conventions, and when the user asks to validate or lint an AsyncAPI document. Produces a single YAML file that validates against the AsyncAPI 3.1.0 spec and passes Spectral linting.
Author OpenAPI 3.1.0 API specifications in YAML following a consistent, componentized house style (the same style as the bundled Catalog Management example). Use this skill whenever the user wants to create, write, draft, design, scaffold, or extend an OpenAPI / Swagger specification, design a REST API contract, turn a feature or data model into API endpoints, or produce an api.yaml / openapi.yaml file — even if they don't say "OpenAPI 3.1.0" explicitly. Also use it when adding endpoints or schemas to an existing spec so the additions match the house conventions, and when the user asks to validate or lint a spec. Produces a single YAML file that passes Spectral linting.
Interpret an EventStorming board (Alberto Brandolini's notation) from a photo or screenshot and turn it into a buildable brief: bounded contexts as modules, a domain model with aggregate state machines, commands/policies/flows, actors, external systems, and open hotspots. Use this whenever the user shares or describes an EventStorming result -- a board of colored stickies where orange = domain events (past tense), blue = commands, large yellow = aggregates, small yellow = actors, green = read models, lilac/pink = policies or external systems, red = hotspots -- usually on a left-to-right timeline clustered into bounded contexts. Also trigger when they ask to interpret, read, analyze, or build an app / data model / services from such a board, even if they never say 'EventStorming' or name the flavour, or for any orange-events-on-a-timeline sticky board, a Miro/Mural/whiteboard DDD session photo, or a request to extract domain events, aggregates, or bounded contexts.
Create (render) a Core Domain Chart as an SVG in the Nick Tune / DDD Crew style, synthesizing a Capability Map (current positions) and a Devil's Advocate critique (recommended moves) into one picture: each capability plotted on business differentiation × model complexity, with an arrow from its Capability-Map position (grey dashed circle) to its critic-derived target (bold black circle). Use whenever someone wants to build, draw, generate, render, or produce a Core Domain Chart, plot (sub)domains or capabilities as core/supporting/generic, or visualize where capabilities should move and why — e.g. "make a core domain chart from this capability map and critique," "chart these subdomains," "show the target positions with arrows," even if they don't name the technique. Pairs with the core-domain-chart-critic (which supplies the critique). Produces a single .svg matching the bundled gold-standard example. Grounded in Millett & Tune, Patterns, Principles, and Practices of DDD.