CtrlK
BlogDocsLog inGet started
Tessl Logo

oma-architecture

Architecture specialist for software/system design, module and service boundaries, tradeoff analysis, and stakeholder synthesis. Uses context-aware methods such as diagnostic routing, design-twice comparison, ATAM-style risk analysis, CBAM-style prioritization, and ADR-style decision records.

60

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/oma-architecture/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

70%

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

The body is a well-structured, validation-aware architecture protocol with clear scene sequencing and good reference navigation, but it carries avoidable redundancy (methods and resource paths each listed twice) and stays at a process-abstraction level rather than giving concrete worked examples. Tightening the duplication and inlining one concrete method example would lift the weaker dimensions.

Suggestions

Remove the duplicate method list: keep either the Transitions descriptions or the Method Selection Summary, not both.

Collapse the References section to a single list; the prose 'Follow resources/execution-protocol.md...' lines duplicate the bullet list that follows.

Inline one short concrete worked example (e.g. a sample ADR skeleton or a two-option design-twice comparison) so guidance is executable rather than purely abstract.

DimensionReasoningScore

Conciseness

The body is dense, table-driven, and free of basic-concept padding, but tokens do not all earn their place: the six methods are listed in Transitions and again verbatim in Method Selection Summary, and the References section lists each resource twice (prose then bullets).

2 / 3

Actionability

It gives a concrete scene sequence and executable `rg` commands, but most guidance is abstract process direction ('Select the lightest sufficient method', 'Diagnose the architecture problem') with the actual method steps deferred to referenced files rather than shown.

2 / 3

Workflow Clarity

A clear PREPARE->ACQUIRE->REASON->VERIFY->FINALIZE sequence is given with an explicit VERIFY checkpoint, a Failure-and-recovery section, and a referenced checklist, matching the anchor for clear sequence with validation and feedback loops.

3 / 3

Progressive Disclosure

SKILL.md acts as an overview pointing to one-level-deep, clearly signaled references (resources/*.md, ../_shared/core/*.md) listed in a dedicated References section; no bundle directories were present to verify against, but the structure itself is well split and navigable.

3 / 3

Total

10

/

12

Passed

Description

67%

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 is specific and well-scoped to a clear architecture niche, but it omits an explicit 'Use when...' trigger clause and leans on method jargon (ATAM/CBAM/design-twice) that users would not naturally say. Adding natural-language trigger terms and a use-when clause would raise completeness and trigger quality.

Suggestions

Add an explicit 'Use when...' clause naming natural user triggers, e.g. 'Use when the user asks about system architecture, module or service boundaries, design tradeoffs, or needs an ADR.'

Soften method jargon in the description (ATAM-style, CBAM-style, design-twice) or move it after the trigger clause so natural terms lead.

Include common variations users actually say ('architecture review', 'service boundaries', 'tech design', 'design doc') to improve trigger term coverage.

DimensionReasoningScore

Specificity

Lists multiple concrete actions ('software/system design, module and service boundaries, tradeoff analysis, and stakeholder synthesis') plus named methods (diagnostic routing, design-twice, ATAM, CBAM, ADR), matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

It clearly answers 'what' but lacks any explicit 'Use when...' trigger clause; per the judging guidelines a missing use-when clause caps completeness at 2 even though the what is strong.

2 / 3

Trigger Term Quality

Natural terms like 'architecture', 'system design', 'tradeoff' are present, but the trigger surface is dominated by method jargon ('diagnostic routing', 'design-twice comparison', 'ATAM-style', 'CBAM-style') that users would rarely say, so common variation coverage is incomplete.

2 / 3

Distinctiveness Conflict Risk

The architecture niche is clearly scoped (system design, boundaries, tradeoffs, ADRs) and method-qualified, making it unlikely to trigger for the wrong sibling skill.

3 / 3

Total

10

/

12

Passed

Validation

100%

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

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
first-fluke/oh-my-agent
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.