CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

metalbear/mirrord-config

Helps users generate, edit, and validate mirrord.json configuration files for mirrord (MetalBear). Use when the user wants to connect their local process to a Kubernetes environment, configure features (env/fs/network), or needs feedback on an existing mirrord.json. Always ensures output JSON is valid and schema-conformant.

73

Quality

92%

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

Overview
Quality
Evals
Security
Files

Quality

Content

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

An excellent skill body: highly actionable with concrete commands and a copy-paste-ready example, an explicit validation feedback loop, and exemplary progressive disclosure that externalizes deep reference material while keeping non-obvious decision guidance (the fs.mode section) inline. The only improvement is consolidating repeated statements of the validation mandate and minimal-config rule.

DimensionReasoningScore

Conciseness

The body assumes Claude's competence and concentrates on genuinely non-obvious domain knowledge (the fs.mode local-by-default correction, the '{{key}}' literal-vs-Tera pitfall, the speculative-config prohibition), with deep detail correctly pushed to references. Minor verbosity: the validate-before-presenting mandate is stated in three to four places (Critical First Steps, Validation Workflow, Request Types, Response Format) and the minimal-config rule is repeated across sections. Not 5: that repetition could be consolidated; not 3: everything else earns its place.

4 / 5

Actionability

Fully executable guidance throughout: a copy-paste-ready example config, exact commands ('which mirrord', 'mirrord verify-config <file>'), concrete key syntax ('"target": "pod/name"', '"env": {"include": "VAR1;VAR2"}'), a Tera template example, and JSON Pointer error notation. The example scenario covers the most common request end-to-end.

5 / 5

Workflow Clarity

A clear three-step 'Critical First Steps' sequence (load references, check CLI, validate before presenting) plus a mandatory Validation Workflow with an explicit feedback loop ('Fix the config → Re-validate until success') and severity-ordered error reporting. Not 4: validation checkpoints are explicit and enforced, not merely suggested.

5 / 5

Progressive Disclosure

All three referenced files exist and are one level deep, clearly signaled with paths: 'references/schema.json', 'references/configuration.md', and 'references/fs-mode-internals.md' (which correctly externalizes the default file lists while the decision table stays inline). The body keeps only decision guidance and common patterns inline, with the bulk of reference material in separate files. Easy to navigate with well-organized sections.

5 / 5

Total

19

/

20

Passed

Description

88%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 strong description: concrete actions, explicit what-and-when structure, and a clearly anchored niche around mirrord.json. The only room for improvement is adding a few more natural trigger synonyms users associate with mirrord's behavior (traffic mirroring/stealing, debugging pods).

Suggestions

Add one or two behavioral synonyms users naturally use with mirrord, e.g. 'mirror or steal traffic from a pod' or 'debug a local process against a remote Kubernetes pod', to strengthen trigger coverage.

Tie the 'connect local process to Kubernetes' trigger more tightly to mirrord by naming the traffic-mirroring use case explicitly, reducing overlap with generic Kubernetes dev-tool skills.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — 'generate, edit, and validate mirrord.json configuration files', 'feedback on an existing mirrord.json', and 'ensures output JSON is valid and schema-conformant' — giving comprehensive coverage of the skill's capabilities. Not 4: the action list covers generation, editing, validation, review feedback, and conformance with no meaningful gaps.

5 / 5

Completeness

Explicitly answers both 'what' (generate, edit, and validate mirrord.json files) and 'when' via an explicit 'Use when the user wants to...' clause with three concrete trigger conditions. Not 4: the when-clause is explicit and specific rather than weakly implied.

5 / 5

Trigger Term Quality

Good natural keywords: 'mirrord.json', 'connect their local process to a Kubernetes environment', 'configure features (env/fs/network)'. A few natural phrases users commonly say are missing, such as 'mirror traffic', 'steal traffic', 'debug a pod', or the 'k8s' abbreviation, so it falls just short of comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

The mirrord (MetalBear) and mirrord.json anchors create a clear niche with minimal conflict risk, but 'connect their local process to a Kubernetes environment' is phrasing shared with closely related Kubernetes dev-tool skills (telepresence, port-forward), a minor overlap risk. Not 5: that broader phrasing could plausibly match requests not involving mirrord at all.

4 / 5

Total

18

/

20

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

On this page