CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

elixir-architecture

Elixir system design patterns, context boundaries, and scalable architecture for distributed applications

Quality

64%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skill/elixir-architecture/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a comprehensive, code-rich Elixir architecture reference with strong actionable examples across contexts, distribution, and API design. Its main weaknesses are verbosity from tutorial-style prose, lack of multi-step validation workflows, and monolithic single-file structure with no progressive disclosure to separate reference files.

Suggestions

Trim explanatory prose that restates concepts Claude already knows (e.g. the 'What are Contexts?' definition and bounded-context primer) and lead with the code patterns.

Split deep-dive material (event sourcing, libcluster setup, full API @spec reference) into reference files under references/ and link to them from the overview.

Add explicit validation/checklist steps to the scaling and split-context decision workflows so architectural decisions have concrete checkpoints rather than advisory lists.

DimensionReasoningScore

Conciseness

The body is mostly efficient code-driven guidance, but it includes tutorial prose Claude already knows (e.g. "Contexts are dedicated modules that expose and group related functionality... bounded contexts in your domain") and very extensive before/after examples that could be trimmed.

3 / 5

Actionability

It provides extensive concrete, executable Elixir code (context modules, Ecto.Multi transactions, libcluster config, PubSub, event store, typed @spec APIs) that is largely copy-paste ready, with only minor gaps such as a few `...` placeholders in the split-context examples.

4 / 5

Workflow Clarity

Numbered decision frameworks and an architecture evolution path (monolith, umbrella, microservices) give a loose sequence, but as an advisory pattern catalogue it lacks explicit validation checkpoints or feedback loops; no cap applies since the operations are not destructive or batch.

3 / 5

Progressive Disclosure

The content is well sectioned with headers, but everything lives in a single ~440-line file with no bundle files (references/scripts/assets absent) and no internal one-level-deep references; material like the full event-store implementation and cluster config that could be split out is inlined.

3 / 5

Total

13

/

20

Passed

Description

56%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description clearly identifies the Elixir architecture niche with strong domain keywords, but it is purely a topic list with no actionable verbs and no explicit trigger guidance for when Claude should activate it. Adding a 'Use when...' clause and concrete verbs would substantially raise its score.

Suggestions

Add an explicit trigger clause, e.g. 'Use when designing Elixir systems, defining Phoenix context boundaries, or planning horizontal scaling and node clustering for distributed applications.'

Replace topic-noun phrasing with concrete actions, e.g. 'Designs context boundaries, structures umbrella applications, and plans distribution strategies for scalable Elixir systems.'

Include natural synonyms users actually say (Phoenix contexts, OTP, concurrency, microservices) to broaden trigger coverage.

DimensionReasoningScore

Specificity

The description names a specific domain ("Elixir system design patterns", "context boundaries", "scalable architecture for distributed applications") but lists only topic nouns with no concrete actions or verbs, matching the anchor where the domain is named but actions are minimal or generic.

2 / 5

Completeness

It clearly states what the skill covers (system design patterns, context boundaries, scalable architecture) but provides no "Use when..." clause or trigger guidance, which per the rubric caps completeness at 3.

3 / 5

Trigger Term Quality

Natural, domain-accurate terms an architect would say are present ("Elixir", "system design patterns", "context boundaries", "distributed applications"), with only minor gaps in common synonyms like Phoenix, OTP, concurrency, or scalability.

4 / 5

Distinctiveness Conflict Risk

The description targets a fairly distinct niche (Elixir system design and distributed architecture) with mostly specific triggers, though there is minor overlap risk with closely related sibling skills like elixir-otp or elixir-phoenix.

4 / 5

Total

13

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository

vircung/opencode-config

Path

skill/elixir-architecture/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.