CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

mobilebuildmcp-packaging-resource-review

Use when reviewing MobileBuildMCP packaging, resource-root, build artifact, bundled AXe, schema, manifest, and portable macOS distribution changes.

63

Quality

79%

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 ./.agents/skills/mobilebuildmcp-packaging-resource-review/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

A tight, well-structured review skill: lean bullet formatting, concrete file paths, named environment variables, and explicit validation commands with no padding. The only gaps are a handful of vague guardrail items ('remain verified', 'when touched'), no guidance for handling validation failures, and one hedged command.

DimensionReasoningScore

Conciseness

The body is pure lean bullets — 'Review-only by default.', specific file paths, guardrail one-liners, and validation commands — with zero padding and no explanation of concepts Claude already knows. Every token earns its place.

5 / 5

Actionability

Mostly executable: concrete commands ('npm run build', 'npm run verify:portable', 'npx skill-check .agents/skills/mobilebuildmcp-packaging-resource-review') and env vars (MOBILEBUILDMCP_RESOURCE_ROOT, DYLD_FRAMEWORK_PATH). Not 5: a few items stay vague — 'Resource-root utilities when touched' names no files, 'AXe binary/framework expectations remain verified' says nothing about how to verify them, and 'npm run package:macos -- --help (if supported)' is uncertain guidance.

4 / 5

Workflow Clarity

The scope → files → guardrails → validation flow is clearly laid out with explicit validation commands, matching 'clear sequence with most checkpoints present'. Not 5: there is no error-recovery feedback loop (what to do when a guardrail fails or validation errors) and one validation step is hedged with '(if supported)'; not 3 because checkpoints are explicit rather than implicit.

4 / 5

Progressive Disclosure

The skill is under 50 lines with no external references needed, and the four sections (Review scope, Files to inspect, Guardrails, Validation) are well-organized and easy to navigate — the simple-skill case where well-organized sections alone warrant a 5.

5 / 5

Total

18

/

20

Passed

Description

65%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 highly specific, well-scoped trigger description that clearly signals when to use the skill and is unlikely to conflict with other skills. Its weakness is that the 'what' is compressed into a single 'Use when reviewing...' clause with only one action verb, so the skill's actual review capabilities (guardrails, validation) are not stated.

Suggestions

State the 'what' explicitly alongside the trigger, e.g. 'Reviews package/resource integrity, checks published files and portable layouts, and runs build validation for MobileBuildMCP. Use when reviewing packaging, resource-root, build artifact, bundled AXe, schema, manifest, or portable macOS distribution changes.'

Add one or two more concrete action verbs (e.g., 'verifies', 'validates') so the capability list reads as actions rather than a single 'reviewing' clause.

Include a couple of natural synonym terms users might say (e.g., 'release packaging', 'dist bundle') to broaden trigger coverage beyond project jargon.

DimensionReasoningScore

Specificity

The description names a concrete domain and enumerates specific artifacts ('packaging, resource-root, build artifact, bundled AXe, schema, manifest, and portable macOS distribution'), but offers only one action verb ('reviewing'). It is more concrete than the anchor-2 'names the domain but actions are minimal' example, yet lacks the several distinct actions of anchor 4.

3 / 5

Completeness

The 'when' is explicit and detailed ('Use when reviewing ... changes'), but the 'what' — the guardrails and validation the skill actually performs — is only folded into the trigger clause rather than stated as capabilities. Anchor 4 requires both clearly present; anchor 2 (only 'when' with a vague what) is too harsh given the rich, specific trigger.

3 / 5

Trigger Term Quality

Natural contributor phrases like 'packaging', 'build artifact', 'manifest', 'schema', and 'portable macOS distribution' give good keyword coverage. Not 5: terms like 'resource-root' and 'bundled AXe' are project jargon and a few natural synonyms or variations (e.g., 'release', 'dist', 'bundle') are missing.

4 / 5

Distinctiveness Conflict Risk

Highly project-specific triggers ('MobileBuildMCP', 'bundled AXe', 'portable macOS distribution', 'resource-root') create a clear niche with minimal overlap risk against generic review or packaging skills.

5 / 5

Total

15

/

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

referenced_paths_exist

Referenced path issues: 3 missing

Warning

Total

15

/

16

Passed

Repository

getsentry/XcodeBuildMCP

Path

.agents/skills/mobilebuildmcp-packaging-resource-review/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.