Use when you are unsure of the exact kind or relationship name in the active workspace, especially when similar spellings exist or you need to distinguish logical-model taxonomy from deployment taxonomy.
Use this skill to confirm exact names from the active workspace, not to guess from memory or English labels. The source of truth is the current LikeC4 project summary plus the shared specification files.
The goal is not merely to list kinds — it is to answer three questions safely:
Container_Api vs Container_APIread-project-summary to see the current element kinds and relationship kinds.projects/shared/spec-context.c4 or spec-containers.c4; deployment kinds in spec-deployment.c4.| Question | Source of truth | Typical resolution |
|---|---|---|
| Exact container kind? | read-project-summary, spec-containers.c4 | Prefer the declared subtype such as Container_Api |
| Exact infrastructure kind? | read-project-summary, spec-deployment.c4 | Trust the repository spelling, e.g. Infra_Fw |
| Logical vs deployment relationship? | project summary + modeling context | Logical model uses calls/reads/writes/async/uses; deployment uses https/tcp/sql/... |
| Two names look similar? | exact declared identifier | Reject the lookalike and cite the real one |
These examples are useful because they are easy to get wrong:
| Intent | Exact declared name | Lookalike to reject |
|---|---|---|
| API container | Container_Api | Container_API |
| Firewall infrastructure | Infra_Fw | Infra_Firewall |
| VM deployment node | Node_Vm | Node_VM |
| Database container | Container_Database | ad-hoc names like Container_DB |
Use these for normal application behavior:
calls, async, reads, writes, uses
Use these only for deployment-side infrastructure edges:
http, https, tcp, nfs, amqp, sql, redis, smtp, ldap, oidc_saml
If the interaction belongs in the logical model, keep the logical kind and put the protocol in technology, for example technology 'HTTPS' or technology 'HTTP/8080'.
// 1. Confirm the exact kind from the active workspace
api = Container_Api 'REST API' {
technology 'Node.js'
}
// 2. Use logical-model relationship kinds for app behavior
api -[calls]-> externalProvider 'Authenticates user' {
technology 'HTTPS'
}
// 3. Use data-access relationships for stores
api -[reads]-> primaryDatabase 'Fetches records'
api -[writes]-> primaryDatabase 'Stores records'
❌ Guessing from English labels — Container_API, Infra_Firewall, and Node_VM may feel natural but are not the declared identifiers here
❌ Using a generic base kind too early — Container exists, but if a more specific declared subtype fits, use it
❌ Inventing relationship kinds — query, invokes, triggers, and other ad-hoc kinds are invalid unless declared in the spec
❌ Mixing model and deployment taxonomies — https is not a logical-model relationship kind for normal application traffic; calls is not a deployment edge kind
create-elementcreate-relationshipunderstand-project-structure