| name | lookup-element-kinds |
| description | 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. |
Verify LikeC4 Element Kinds and Relationship Types
Overview
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:
- What is the exact spelling?
- Is it a logical-model kind or a deployment kind?
- How do I verify it before writing model code?
When to Use
- Choosing between similar spellings such as
Container_Api vs Container_API
- Verifying whether a relationship kind belongs to the logical model or deployment
- Looking up nearby valid kinds for a node, zone, infrastructure element, or container
- Checking the active workspace before creating or editing elements/relationships
Verification Workflow
- Read the active project summary — use
read-project-summary to see the current element kinds and relationship kinds.
- Check the relevant shared spec — container/system kinds in
projects/shared/spec-context.c4 or spec-containers.c4; deployment kinds in spec-deployment.c4.
- Resolve close spellings by exact match — trust the declared identifier, not the most readable English expansion.
- Classify the interaction — logical model vs deployment. This decides which relationship taxonomy is even legal.
- Only then write the model code — if still uncertain, stop and verify again instead of inventing a kind.
Quick Reference
| 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 |
Common Exact Checks in This Workspace
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 |
Logical Model vs Deployment Taxonomy
Logical model relationships
Use these for normal application behavior:
calls, async, reads, writes, uses
Deployment relationships
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'.
Example Verification Pattern
// 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'
Common Mistakes
❌ 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
Handoffs
- Need to create the element once the kind is known? Use
create-element
- Need to choose the relationship after confirming taxonomy? Use
create-relationship
- Need to re-check workspace context first? Use
understand-project-structure
