oma-dev-workflow

Configure development tasks, git hooks, CI/CD, or release automation. Use when creating or fixing a repository development workflow.

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/oma-dev-workflow/SKILL.md

Quality

Content

62%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.

The body delivers strong, executable mise guidance with a well-sequenced, validated workflow, but it is burdened by heavy boilerplate and redundant sections that inflate token cost without adding capability. Its progressive disclosure is undermined by references to bundle files that are absent and by inlining content those files should hold.

Suggestions

Cut the abstract scaffolding (Intent signature, Scenes, SSL-primitive/Actions table, Resource scope, Preconditions) and the duplicated How to Execute / Troubleshooting Guide sections; keep one workflow narrative and the guardrails that are not already implied elsewhere.

Either create the referenced resource files or remove/inline their content: the six resources/*.md and two ../_shared/core/*.md references point to files that do not exist in the bundle.

Fill in or delete the empty "Execution Protocol (CLI Mode)" heading, and move long inline material (Environment Variables, Output Templates, Project Structure) into the reference files indicated by the Reference Guide table.

Dimension	Reasoning	Score
Conciseness	The ~360-line body is noticeably padded: abstract scaffolding Claude does not need ("SSL primitive" table, Intent signature, Scenes), the goal restated across Scheduling/How to Execute/Output Templates, a 26-item guardrail list with many redundant pairs, and a Troubleshooting Guide that duplicates the "Failure and recovery" section.	2 / 5
Actionability	Commands are concrete and copy-paste ready ("mise run //apps/api:dev", root mise.toml snippet, TOML quoting rule, troubleshooting table), but "Execution Protocol (CLI Mode)" is an empty stub heading and a few snippets lack surrounding context.	4 / 5
Workflow Clarity	The workflow is clearly sequenced (Entry → PREPARE/ACQUIRE/ACT/VERIFY/FINALIZE → Transitions → Failure and recovery → Exit) with explicit validation checkpoints (exit codes, output/artifact verification) and destructive-task confirmation, matching the top anchor.	5 / 5
Progressive Disclosure	The Reference Guide table signals external files well with a "When to Load" column, but none of the referenced files (resources/validation-pipeline.md, resources/database-patterns.md, resources/api-workflows.md, resources/i18n-patterns.md, resources/release-coordination.md, resources/troubleshooting.md, ../_shared/core/*) exist in the bundle, and content that belongs in those files (troubleshooting, env vars, output templates) is inlined in SKILL.md.	3 / 5
	Total	14 / 20 Passed

Description

75%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.

A solid third-person description that explicitly covers both what the skill does and when to use it, with domain-specific trigger terms. It falls short of top marks for relying on one generic verb, omitting the core tool name (mise) and common task vocabulary, and offering only one abstract when-condition.

Suggestions

Add natural trigger vocabulary users would actually say, e.g. "Use when the user mentions mise, mise.toml, task runners, lint/test/build tasks, or monorepo dev servers".

Mention migrations, i18n builds, and generated API clients in the what-clause so the description covers the skill's actual scope.

Use more varied, concrete action verbs (run, set up, troubleshoot, parallelize) instead of the single generic "Configure".

Dimension	Reasoning	Score
Specificity	"Configure development tasks, git hooks, CI/CD, or release automation" names the domain plus several specific objects, but relies on a single generic verb and omits capability areas the body covers (migrations, i18n builds, dev servers), so it is not comprehensive.	4 / 5
Completeness	Both what ("Configure development tasks, git hooks, CI/CD, or release automation") and when ("Use when creating or fixing a repository development workflow") are explicitly present, but the when-clause is a single abstract condition rather than concrete trigger phrases users would say.	4 / 5
Trigger Term Quality	Terms like "git hooks", "CI/CD", and "release automation" are phrases users naturally say, but common trigger words are missing: the tool name "mise", plus lint, build, test, dev server, and monorepo.	4 / 5
Distinctiveness Conflict Risk	It carves a clear niche (repository development workflow automation) with distinct triggers, though "CI/CD" and "release automation" carry minor overlap risk with generic deployment/CI skills.	4 / 5
	Total	16 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: first-fluke/oh-my-agent
Path: skills/oma-dev-workflow/SKILL.md
Commit: ce19702

Reviewed: 4 days 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.