CtrlK
BlogDocsLog inGet started
Tessl Logo

competition-container-runtime

Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for live container runtime analysis, mounted secrets, sidecars, namespaces, init containers, entrypoint drift, and route-to-container resolution. Use when the user asks why a live container differs from manifests, where a mounted secret is consumed, how a sidecar or init container changes runtime state, or which route resolves to which live container. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.

70

Quality

86%

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

SKILL.md
Quality
Evals
Security

Quality

Content

72%Weight 40%Scale 1-3

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 lean, well-structured overview with good progressive disclosure, but it stays at the level of approach guidance and omits the concrete runtime commands that would make it directly actionable, and its verification checkpoints are implicit rather than explicit.

Suggestions

Add concrete executable commands for the core inspection steps (e.g. `docker inspect`, `docker exec`, `kubectl describe pod`, `kubectl get pod -o yaml`, mount/route probes) so the guidance is copy-paste ready.

Make verification explicit in the workflow — e.g. a checkpoint after mapping the live runtime that confirms a consuming process was actually identified before reporting deviation.

Reduce the slight overlap between Quick Start, Workflow, and What To Preserve by letting the Workflow carry the procedure and trimming What To Preserve to evidence-format rules only.

DimensionReasoningScore

Conciseness

Lean body with no over-explanation of concepts Claude already knows; every section (Quick Start, Workflow, Read This Reference, What To Preserve) earns its place.

3 / 3

Actionability

Gives concrete categories to inspect (manifest vs running container, mount chain, route boundaries) but no executable commands or tooling invocations such as `docker inspect` or `kubectl describe`, so guidance is incomplete for copy-paste use.

2 / 3

Workflow Clarity

Steps are clearly sequenced (Quick Start 1–5, Workflow 1–3), but verification is implicit ("Prove one minimal live path", "Reproduce the effect") rather than explicit validation gates, leaving checkpoints implicit.

2 / 3

Progressive Disclosure

Body is an overview that signals a single one-level-deep reference ("Load `references/container-runtime.md`", verified to exist) plus clear routing to sibling skills, with content appropriately split.

3 / 3

Total

10

/

12

Passed

Description

100%Weight 40%Scale 1-3

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, trigger-rich, complete, and clearly distinct from sibling skills via explicit downstream routing. It uses third-person voice and avoids vague fluff.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — "live container runtime analysis, mounted secrets, sidecars, namespaces, init containers, entrypoint drift, and route-to-container resolution" — rather than vague language.

3 / 3

Completeness

Explicitly answers both what (the CTF-sandbox runtime analysis workflow) and when (an explicit "Use when the user asks..." clause with concrete triggers).

3 / 3

Trigger Term Quality

Natural user phrasings are covered: "why a live container differs from manifests", "where a mounted secret is consumed", "how a sidecar or init container changes runtime state", "which route resolves to which live container".

3 / 3

Distinctiveness Conflict Risk

Clear niche (live container runtime deviation) with explicit routing — "Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here" — making wrong-skill triggering unlikely.

3 / 3

Total

12

/

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
zhaoxuya520/reverse-skill
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.