morphir-architect

Expert Morphir application architect providing guidance on AST design, functional programming patterns, IR transformations, and code generation for morphir-dotnet. Triggers include "architecture", "design patterns", "AST", "IR", "functional programming", "code generation".

1.06x

Quality

42%

Does it follow best practices?

Impact

95%

1.06x

Average score across 3 eval scenarios

Securityby

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/morphir-architect/SKILL.md

Quality

Content

35%

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

This skill is comprehensive in scope but severely undermined by its verbosity — it reads more like a knowledge base dump than a concise skill file. It explains many standard FP concepts Claude already knows, inlines content that should be in separate files, and references multiple future/stub scripts. The code examples and decision trees provide genuine value but are buried in excessive surrounding text.

Suggestions

Reduce content by 60-70%: remove explanations of standard FP concepts (monads, lenses, Result type), remove the cross-agent compatibility section, and trim the review capability section to essential commands only.

Move the pattern catalog, playbooks, and review report templates into separate referenced files (e.g., PATTERNS.md, PLAYBOOKS.md, REVIEW.md) and keep SKILL.md as a concise overview with navigation links.

Remove or clearly mark all 'future'/'stub'/'planned' scripts and features — they add noise without actionability. Only document what actually exists and works.

Add inline validation steps within playbooks (e.g., 'Run dotnet build to verify the new type compiles' after Phase 1) rather than relying solely on post-workflow checklists.

Dimension	Reasoning	Score
Conciseness	Extremely verbose at 600+ lines. Extensively explains concepts Claude already knows (what monads are, what lenses are, what ADTs are, what Railway-Oriented Programming is). Massive sections on review processes, feedback loops, quarterly schedules, cross-agent compatibility, and templates that add little actionable value. The pattern catalog re-explains standard FP concepts at length.	1 / 3
Actionability	Contains concrete F# and C# code examples that are mostly executable, and specific file paths and commands. However, many examples are illustrative rather than copy-paste ready for the actual morphir-dotnet codebase (e.g., the validatePerson example is generic, not project-specific). Several scripts referenced are marked as 'future' or 'stub', reducing immediate actionability.	2 / 3
Workflow Clarity	The playbooks have numbered steps with phases and checklists, and the decision trees provide clear branching logic. However, validation checkpoints are mostly post-workflow checklists rather than inline verification steps. The review workflow lacks concrete validation commands (the review scripts are stubs or future). No feedback loops for error recovery in the playbooks themselves.	2 / 3
Progressive Disclosure	References to knowledge bases and external files are well-signaled with clear paths. However, the SKILL.md itself is monolithic — it inlines enormous amounts of content (full pattern catalog, complete playbooks, review report templates, cross-agent instructions) that should be in separate referenced files. The skill tries to be both an overview and a comprehensive reference, defeating progressive disclosure.	2 / 3
	Total	7 / 12 Passed

Description

50%

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 identifies a specific technology (morphir-dotnet) and lists relevant topic areas, but relies on vague language ('providing guidance') rather than concrete actions. The trigger terms mix highly specific terms (AST, IR, morphir-dotnet) with overly generic ones (architecture, design patterns) that would cause conflicts. It would benefit from more concrete action verbs and a proper 'Use when...' clause with situational context.

Suggestions

Replace 'providing guidance on' with specific concrete actions like 'Designs AST node structures, implements IR-to-code transformations, applies functional programming patterns for morphir-dotnet projects'.

Add an explicit 'Use when...' clause with situational triggers, e.g., 'Use when the user is building or designing a morphir-dotnet application, working with Morphir IR transformations, or needs help structuring Morphir AST nodes'.

Narrow overly generic trigger terms like 'architecture' and 'design patterns' by qualifying them (e.g., 'Morphir architecture', 'Morphir design patterns') to reduce conflict risk with other skills.

Dimension	Reasoning	Score
Specificity	Names the domain (Morphir application architecture) and lists several areas (AST design, functional programming patterns, IR transformations, code generation), but these are more like topic areas than concrete actions. It says 'providing guidance' which is vague rather than listing specific operations like 'designs AST nodes', 'transforms IR to target code', etc.	2 / 3
Completeness	The 'what' is partially addressed (guidance on AST design, FP patterns, IR transformations, code generation). There is a 'Triggers include' clause which attempts to address 'when', but it lists generic keywords rather than providing explicit situational guidance like 'Use when building or designing morphir-dotnet applications'. The trigger list is not a true 'Use when...' clause with contextual scenarios.	2 / 3
Trigger Term Quality	Includes some relevant keywords like 'AST', 'IR', 'functional programming', 'code generation', 'architecture', and 'design patterns', but these are fairly technical/generic terms. Missing natural user phrases like 'morphir-dotnet project structure', 'how to structure my Morphir app', or domain-specific terms users would actually say. 'Architecture' and 'design patterns' are very broad and could match many unrelated skills.	2 / 3
Distinctiveness Conflict Risk	The mention of 'morphir-dotnet' is quite specific and distinctive, but trigger terms like 'architecture', 'design patterns', 'functional programming', and 'code generation' are extremely broad and would easily conflict with many other skills. A user asking about 'design patterns' in any context could inadvertently trigger this skill.	2 / 3
	Total	8 / 12 Passed

Validation

90%

Warnings & errors only

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

Validation — 10 / 11 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (1047 lines); consider splitting into references/ and linking	Warning

	Total	10 / 11 Passed

Repository: finos/morphir-dotnet
Commit: 7c0c06d

Reviewed: about 2 months ago

Table of Contents

Discovery Implementation Validation

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.