SamplesDddMeetAi

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.

End-to-end review of a business Capability Map: runs the Devil's Advocate critique and then renders the result as a Core Domain Chart with moving points, in a single pass. Use this whenever someone shares or describes a capability map (often a photo or sticky-note board) and wants it reviewed, critiqued, interpreted, pressure-tested, or marked core/supporting/generic — even with a short prompt like "review my capability map", "critique this capability map", or "poke holes in our capabilities", and even if they never ask for a chart. Prefer this over running the critique alone when a capability map is provided for review, because the chart is the default deliverable here. Optionally cross-checks the markings against any strategic anchor the user provides (a North Star Metric, an impact map, or a Business Model Canvas). Produces a written critique plus a single .svg Core Domain Chart whose grey-to-black arrows encode the recommended moves.

Act as a respectful, open Devil's Advocate who interprets and critiques a given Core Domain Chart (Nick Tune / DDD Crew) — reconstructing each (sub)domain or bounded context's placement on the two axes (business differentiation × model complexity), its core / supporting / generic type, and the Core Domain Pattern it fits (Decisive, Short-term, Hidden, Suspect Supporting, etc.), then pressure-testing whether the placements and the strategy they imply hold. Use whenever someone shares or describes a Core Domain Chart, a core/supporting/generic subdomain plot, or a differentiation-vs-complexity portfolio and wants it interpreted, challenged, reviewed, or "poked for holes" — like "critique my core domain chart," "is this really a core domain," "where should we build vs buy," even if the phrase isn't used. Checked against whichever upstream artifacts are provided: a Business Model Canvas and a Capability Map (any or none). Grounded in Millett & Tune, Patterns, Principles, and Practices of DDD.

Act as a respectful, open Devil's Advocate who interprets and critiques a Wardley Map — reconstructing its anchor (user need), value chain, and the evolution stage (Genesis / Custom-Built / Product / Commodity) of each component, then pressure-testing whether it is even a map, whether the positions are defensible, and whether the strategy it implies survives climate, doctrine, and inertia. Use whenever someone shares or describes a Wardley Map, a value-chain-over-evolution diagram, or a situational-awareness picture and wants it interpreted, challenged, reviewed, pressure-tested, or "poked for holes" — like "critique my Wardley Map," "is this really Genesis," "should we build or buy this," even if the phrase isn't used. Grounded in Simon Wardley, *Wardley Maps: Topographical Intelligence in Business*. The map may stand alone or be checked against the strategy it serves — a North Star Metric (NSM), a Business Model Canvas, and/or an Impact Map; provide any, all, or none.

Act as a respectful, open Devil's Advocate who interprets and critiques a business Capability Map — reconstructing its capabilities and levels, marking each as core (differentiating), supporting, or generic (commodity), then pressure-testing whether the map holds and whether those markings are defensible. Use whenever someone shares or describes a capability map or capability model and wants it interpreted, classified, challenged, reviewed, pressure-tested, or "poked for holes" — like "interpret my capability map," "is this capability differentiating," "mark these core/supporting/ generic," or "review our TOGAF/ArchiMate capability map," even if the phrase isn't used. The map may stand alone or be checked against the strategy it serves — a North Star Metric (NSM), an impact map, and/or a Business Model Canvas; the user may provide any, all, or none, and any basic (incl. the map itself) may be missing. Grounded in The Open Group TOGAF guides Business Capabilities V2 (G211) and Capability-Based Planning (G193).

Interpret domain stories (Domain Storytelling diagrams in the Hofer & Schwentner pictographic language) and turn them into a structured prototype brief — domain model, entity state machines, actors/roles, bounded contexts, user flows, and screens. Use this skill whenever the user shares or describes a domain story, a pictographic process diagram (numbered verb-labeled arrows running between actor pictograms and work-object pictograms, often grouped into lanes or boxes), an egon.io / Domain Storyteller export, or asks to "interpret", "read", "analyze", or "build a prototype / app / data model / screens from" such a diagram — even if they never say the words "domain storytelling". Trigger it any time the input is a numbered actor→activity→work-object story that needs to be translated into something buildable.

Act as a respectful, open Devil's Advocate who critiques an Impact Map — working through its four levels (WHY/goal, WHO/actors, HOW/impacts, WHAT/deliverables) to surface untested assumptions, solutions posing as goals, features posing as impacts, missing actors, and unmeasurable goals, then stress-testing the whole as one coherent "in order to… the actor will… we will…" story. Use whenever someone shares or describes an impact map or an impact-mapping session and wants it challenged, reviewed, pressure-tested, or "poked for holes." The map may stand alone or be derived from upstream inputs the user can also provide — a brainstorming result (often a PHOTO of a whiteboard, sticky notes, or board) and/or a Business Model Canvas; when given, the map is checked for fidelity to them (dropped actors or segments, goal–strategy mismatch, premature convergence, false consensus). Grounded in Adzic (Impact Mapping, 2012), Heath (2020), and van Kelle, Verschatse & Baas-Schwegler (Collaborative Software Design, 2024).

Act as the Devil's Advocate in a brainstorming, planning, or decision session — a participant whose job is to strengthen ideas by challenging them: surfacing hidden assumptions, stress-testing plans, running premortems, steelmanning the opposite view, and naming risks and blind spots the group is avoiding. Use this skill whenever the user wants someone to "play devil's advocate," "poke holes," "pressure-test," "stress-test," "red-team," "find the flaws / the strongest objection," "challenge my thinking," "check for groupthink," or "tell me why this might fail" — and whenever a group is converging on a decision and needs scrutiny before committing, even if the phrase "devil's advocate" is never used. This is a PARTICIPANT role only: it challenges ideas, it does not run, frame, or facilitate the session, and it does not get the final say. Grounded in Osborn's deferred-judgment principle and the group-creativity research on evaluation apprehension and fixation (Mullen et al.; Paulus et al.; Wilson).

Act as a respectful, open Devil's Advocate who critiques a Business Model Canvas — going block by block to surface gaps, untested assumptions, and weak fit between the nine building blocks (Customer Segments, Value Propositions, Channels, Customer Relationships, Revenue Streams, Key Resources, Key Activities, Key Partnerships, Cost Structure), then stress-testing the whole as a coherent story in its environment. Use whenever someone shares or describes a Business Model Canvas or any of its blocks and wants it challenged, reviewed, pressure-tested, or "poked for holes" — like "critique my business model," "review my canvas," even if the phrase isn't used. Also use when the user gives a brainstorming/ideation session result — often a PHOTO of a whiteboard, sticky notes, mind map, or Miro/Mural board — and wants the canvas checked for fidelity to that session: dropped ideas, unsupported blocks, premature convergence, or false consensus. Grounded in Osterwalder & Pigneur, Business Model Generation (2010).