Use when working with `.c4`/`.likec4` files or LikeC4 CLI/config questions where exact DSL/CLI syntax is required, especially for strict command/snippet-first answers, validate/export flags, predicates `*`/`_`/`**`, deployment snippets, dynamic views, or relationship extension matching.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
The command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
File Explorer
17 files
Showing SKILL.md
SKILL.md
Source instructions ยท Read-only preview
name
likec4-dsl
description
Use when working with `.c4`/`.likec4` files or LikeC4 CLI/config questions where exact DSL/CLI syntax is required, especially for strict command/snippet-first answers, validate/export flags, predicates `*`/`_`/`**`, deployment snippets, dynamic views, or relationship extension matching.
LikeC4 DSL Skill
Architecture-as-code tool. Describe systems in .c4/.likec4 files and LikeC4 generates interactive diagrams.
Rules
Projects - it is possible to have multiple likec4 projects in a workspace, project is determined by presence of a config file (.likec4rc, likec4.config.{ts,js,json}). LikeC4 files belong to the project of the nearest config file in the directory hierarchy.
Top-level statements โ only import, specification, model, deployment, views, global are allowed. Blocks can repeat, but at least one per file must be present.
Multi-file merge โ Top-level blocks across files are merged. For example, model { ... } blocks present in multiple files, parsed separately, and then merged into a single model.
Strings โ 'single', "double" โ all support multi-line. Escape quotes with backslash: \' or \".
Markdown โ properties like summary/description/notes can contain Markdown. Use triple quotes ''' or """. Begin a new line after opening quotes and indent Markdown content for better formatting and syntax highlighting.
Comments โ // single line and /* multi-line */ comments supported anywhere.
Identifier โ letters, digits, hyphens, underscores only. No dots (dots are FQN separators). Can't start with a digit. Examples: customer, payment-service, frontendApp, quque-1. Critical:payment-api is valid; payment.api is NOT an identifier (dots separate FQN hierarchy). See references/identifier-validity.md.
FQN โ Fully Qualified Name (FQN) is a dot-separated path to an element, MUST be unique within the project. Examples: customer, saas.backend.payment-service.paymentsApi, infra.eu.zone1.node1.
References โ LikeC4 has lexical scoping with hoisting, nested scope may shadow outer, like in JavaScript. That scope does not carry across files: even with imports/includes in the same project, cross-file references must use full FQNs.
Response Discipline (critical for evals)
If prompt says "minimal", "paste-ready", "strict", "exact", or requires a specific first line, output exactly one final command/snippet/verdict token first (no alternatives, no fallback variants, no extra preamble).
Do not add unrequested title, labels, alternate snippets, or long explanations unless explicitly asked.
Prefer exact requested tokens/phrases in the first line when the prompt requires strict phrasing.
For strict command prompts, avoid ambiguous wording like "equivalent command" unless prompt explicitly asks for alternatives.
If the task is snippet-first or command-first, a prose-only answer is a failure even if the explanation is knowledgeable.
If the prompt asks for named deployment instances, use IDENTIFIER = instanceOf ELEMENT_ID.
Do not substitute anonymous instanceOf ELEMENT_ID lines when naming is required.
If the prompt asks for a full fixture, keep the minimal executable structure: specification, model, deployment, and views.
Relationship-extension matchers
Relationship identity is matched by source + target + kind (+ title when needed).
If typed relationships exist, omitting KIND is wrong for strict disambiguation prompts.
If multiple relationships share source/target/kind, include the title in the matcher.
Do not "simplify" a typed matcher to extend SOURCE -> TARGET ... when the prompt is testing exact relationship identity.
Triage anchor when typed alternatives coexist:
// Existing relationships
api -[async]-> queue "publishes"
api -[sync]-> queue "publishes"
// โ Correct: exact relationship selected
extend api -[async]-> queue "publishes" { metadata { retries "3" } }
// โ ๏ธ Ambiguous: kind omitted, async vs sync both match source/target/title family
extend api -> queue "publishes" { metadata { retries "3" } }
// โ Wrong: selects the other relationship
extend api -[sync]-> queue "publishes" { metadata { retries "3" } }
Workflow
(Required) Find existing or create new project config (section below). Directory with project config defines the scope for all LikeC4 files in that directory and subdirectories. Ask user if you are uncertain about the scope.
(Required) Find existing or create new specification { ... }, this enables what kinds of elements/deployments/relationships/tags you can use. See Specification section below.
Architecture elements and relationships are defined in model { ... } block. See Model section below.
Deployment topology is defined in deployment { ... } block. See Deployment section below.
Views (diagrams) are defined in views { ... } block. See Views section below.
After editing LikeC4 files, validate with the CLI
Generate โ Self-check โ Finalize
For strict command/snippet prompts, keep a compact loop:
Generate only the requested final command/snippet.
Self-check quickly:
exact command family / required flags / repeated --file count
snippet-first or first-line contract satisfied
predicate semantics (*, _, **) stated precisely
scope / FQN correctness
deployment naming requirement satisfied
relationship matcher specificity (kind, title when needed)
dynamic view exactness: return arrows, chain form, single parallel block when requested
Finalize by fixing in place (no extra alternatives unless explicitly requested).
Before final answer, verify the required tokens are literally present when the prompt depends on them (examples: --no-layout, instanceOf, variant sequence, global predicate, -[async]->, parallel {, <-).
Never claim CLI execution happened unless it actually ran.
--json โ structured output (stdout), logging goes to stderr
--no-layout โ skip layout drift checks (faster, only syntax+semantic)
--file <path> โ only report errors from this file (can repeat for multiple files)
<project-dir> โ path to the project directory
There is nolikec4 check command; use likec4 validate.
For evals/gradings/executions, be runner-tolerant (npx/bunx/pnpm dlx), and judge correctness by subcommand + flags + project scope.
If workspace already has likec4 as a dependency, check its version from package.json and ensure it is at least 1.53.0. If pinning is needed, use the active runner (npx/bunx/pnpm dlx) with likec4@1.53.0.
Example output:
{"valid":false,"errors":[{"message":"...","file":"/abs/path.c4","line":5,"range":{"start":{"line":5,"character":2},"end":{"line":5,"character":20}}}],"stats":{"totalFiles":100,// Total number of files in the project"totalErrors":500,// Total number of errors in the project"filteredFiles":1,// Number of files that match the --file filter"filteredErrors":1// Number of errors in the filtered files}}
Broken specification/model in a large project can cascade into lots of errors across all files. Always use --file to focus on the files you edited. If filteredErrors is 0 but totalErrors is high, your files are clean but something else in the project is broken (not your problem). Selfcheck that filteredFiles matches the number of files you passed to --file.
Field semantics (must be explicit in answers):
filteredFiles: count of files actually included by repeated --file filters
filteredErrors: errors in the filtered subset only
totalErrors: errors across the full project model
Example edge case: if you pass 3 files but one is likec4.config.json, filteredFiles may be 2 because config JSON is not a .c4/.likec4 source file for DSL validation.
Export PNG flags (precision)
Canonical output directory flags:
--outdir (long form)
-o (short form)
Do not invent flags like --out-dir. Depending on LikeC4 version, --output may appear as compatibility alias; prefer --outdir/-o for deterministic answers.
Full CLI reference โ references/cli.md
Canonical Snippets for High-Variance Families
Use these as exactness anchors when the prompt is testing syntax, not broad explanation.
predicateGroup reusable predicate
global {
predicateGroup core-services {
include cloud.* where kind is service
exclude * where tag is #deprecated
}
}
views {
view service-overview {
global predicate core-services
}
}
views {
view backend of cloud.backend {
include *
include -> cloud.backend
}
}
Interpretation anchor: in a scoped view, include * means the scoped element plus its direct children as the base include set; neighbors can still appear through scoped relationship visibility.
Deployment-view styling guardrail
For strict repair prompts about deployment views, the safe answer is local style ... {} inside the deployment view.
Need
Prefer
Avoid as the answer
Style one deployment view
deployment view prod { include prod.** style prod._ { color primary } }
deployment view prod { include prod.** with { color primary } }
Reuse styling in a deployment-view fix
local style ... {} rules in that deployment view
global style theme
Mini-reminder: benchmark prompts in this family expect include ... with {} / global style ... to be treated as unsupported deployment-view repair patterns.
LikeC4 Project Configuration
Config file (likec4.config.json, .likec4rc, or likec4.config.{ts,js}) defines a project. Its location sets the project scope (LikeC4 files belong to the project of the nearest config file in the directory hierarchy).
Key options: name (required, unique ID in the workspace), title (display name)
Full reference โ references/configuration.md
Specification
Defines all named vocabularies: element kinds, deployment node kinds, relationship kinds, tags, and custom color tokens. Must appear before those kinds are used in model or deployment blocks.
Key reminders: all definitions are global across files; duplicate kind/tag identifiers cause a validation error; specification changes trigger a full project re-parse โ keep it in a dedicated spec.c4 file.
Full syntax, options per kind, and worked example โ references/specification.md
Model
Hierarchical structure of elements and relationships. Elements have a kind (from specification), a unique identifier within their parent, and optional properties and nested elements.
Key reminders: this/it aliases the current element in nested relationships; cross-file references require full FQN; parent-child direct relationships are forbidden; extend FQN { } merges tags, metadata, and links into an existing element without redefining it.
Full syntax, extend patterns, property table, and worked example โ references/model.md
Style
Style properties control visual appearance: color, shape, border, opacity, size, padding, textSize, icon, iconColor, iconSize, iconPosition, multiple. Relationship style extends this with line, head, and tail arrow shapes.
Full color token table, all shape values, border/opacity/size tokens, icon pack prefixes (aws:, azure:, gcp:, tech:, bootstrap:), and correct usage patterns โ references/style-tokens-colors.md
Deployment
Maps logical model elements to physical infrastructure nodes using instanceOf. Uses deploymentNode kinds from specification. Inherits all logical model relationships automatically; additional deployment-level relationships can be defined inline.
Named vs. anonymous instances, multi-environment fixture, deployment relationships, and selection guidance โ references/deployment.md
Views
Three view types: element views (view id or view id of element), dynamic views (dynamic view id), deployment views (deployment view id). View properties: title, description, metadata, link.
Include/exclude predicates, view-level style rules, groups, autoLayout, extends, navigateTo, and global predicate groups โ references/views.md
Quick Decision Trees
"I need incoming relationship predicates"
Need inbound relation selection?
โโ From any source to target element โ `include -> target`
โโ From explicit wildcard source โ `include * -> target`
โโ Include both directions around X โ `include -> X ->`
include -> X and include * -> X are related but not interchangeable in all contexts; prefer the exact form requested by user/eval.
Scoped Predicate Truth Card (*, _, **)
Selector
One-line truth
Typical use
parent.*
Direct children of parent only
Show immediate structure
parent._
Direct children of parent that have relationships with accumulated result
Keep only connected direct children
parent.**
Recursive descendants of parent that have relationships with accumulated result
Explore connected deep descendants
Hard rule: do not describe * as recursive; do not describe _ as wildcard-all; do not drop relationship-condition semantics for _ / **.
"I need to create a diagram/view or show a flow or sequence"
What kind of diagram?
โโ Interaction flow / sequence โ Dynamic View
โโ Infrastructure / deployment โ Deployment View
โโ From architecture model โ Element View
โ โโ Primary element known โ Scoped view: `view name of element { ... }`
โ โโ Extend existing view โ `view name extends other { ... }`
โโ Other โ `view name { ... }`
"I need to style ..."
Styling?
โโ Style element(s) in a view โ view `style` rule, see `references/views.md`
โโ Style element(s) in some views, but not all
โ โโ views in same file โ local view rule, see `references/views.md`
โ โโ views in different files โ global view rule, see `references/views.md`
โโ Style element globally โ property inside element definition, see Model section
โโ Style all elements of a kind โ property inside kind specification, see Specification section
โโ Style by tag โ view rule, see `references/views.md`
โโ Style relationship(s) in a view โ view rule, see `references/views.md`
โโ Style relationship globally โ property inside relationship definition, see Model section
โโ Style all relationships of a kind โ property inside kind specification, see Specification section
โโ Reuse same styles across views โ see `references/views.md`
"I need to organize across files"
Multi-file project?
โโ Import elements โ import { backend } from './shared.c4'
โโ Cross-file lookup โ short names do not inherit lexical/container scope across files; use full FQN
โโ Extend element โ extend cloud.backend { service newSvc "New" }
โโ Extend relationship โ extend cloud -> amazon { metadata { ... } }
โโ Metadata merge โ Duplicate keys become arrays
โโ Organize views โ views "Use Cases" { ... } (folder label)
โโ All blocks are mergeable across files
