CtrlK
BlogDocsLog inGet started
Tessl Logo

706-technologies-containers-docker

Use when you need framework-agnostic Docker and container image guidance for Java projects - Dockerfile design, multi-stage Maven builds, jlink custom runtimes, micro runtime distributions such as Alpaquita, JVM container ergonomics, non-root execution, image metadata, .dockerignore, reproducible builds, vulnerability scanning, SBOM awareness, and production-safe container defaults. This should trigger for requests such as Review Java Dockerfile; Improve Docker image security; Add jlink runtime to a Java container; Add containerization to a Java project; Optimize Java container image size; Review Docker build reproducibility. Part of Plinth Toolkit

72

Quality

91%

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

78%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 well-structured, token-efficient overview with explicit constraints, real verification commands, and an exemplary one-level-deep reference split. The main gaps are the absence of a fix-and-retry feedback loop around the verification steps and a workflow step 3 that stays abstract about which artifacts and reference sections to apply.

Suggestions

Remove or compress the 'When to use this skill' section — it duplicates the frontmatter description's six trigger phrases verbatim and adds no new information to the body.

Add a feedback loop after verification: state what to do when `./mvnw compile` or `./mvnw clean verify` fails (fix the build and re-run before proposing or promoting changes).

Make workflow step 3 concrete: name the artifacts to touch (Dockerfile build/runtime stages, .dockerignore, entrypoint) or link each task type in 'When to use' to the relevant section of references/706-technologies-containers-docker.md.

DimensionReasoningScore

Conciseness

The body is dense and assumes competence ("Keep recommendations at the Dockerfile, image-build, and runtime-container layer", constraint bullets with no basic-concept explanations). It is not anchor 5 because the "When to use this skill" section repeats the six frontmatter trigger phrases verbatim and the BOUNDARIES bullet restates the Scope section — minor trimming opportunities.

4 / 5

Actionability

Concrete commands are present ("Run `./mvnw compile` or `mvn compile`", "Run `./mvnw clean verify`", "Read `references/706-technologies-containers-docker.md`") and constraints name specific checks (Java version, jlink module graph, base-image policy). It is not anchor 5 because step 3 ("Implement or refactor Docker and container build artifacts following the reference patterns") delegates the core actions without naming the specific artifacts or reference sections to use, and not anchor 3 because the guidance that is present is executable, not pseudocode.

4 / 5

Workflow Clarity

The four-step workflow (assess context → identify constraints → apply changes → verify and report) is clearly sequenced with verification checkpoints (MANDATORY compile before proposing, VERIFY before promoting). It is not anchor 5 because there is no error-recovery feedback loop (nothing says what to do when compile or clean verify fails), and not anchor 3 because validation checkpoints are explicit, not merely implied.

4 / 5

Progressive Disclosure

The body is a lean overview that keeps detail in a single, well-signaled, one-level-deep reference ("For detailed guidance, examples, and constraints, see [references/706-technologies-containers-docker.md]"). The referenced file exists in references/ and contains no further nested references, matching the top anchor for clear overview plus easy navigation.

5 / 5

Total

17

/

20

Passed

Description

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

An exemplary description: a concrete, comprehensive capability list, six explicit natural-language trigger phrases, a clearly stated what/when pair, and explicit deferral to sibling skills to avoid conflicts. The only trivial nit is the trailing "Part of Plinth Toolkit" metadata, which adds no trigger value.

DimensionReasoningScore

Specificity

The description enumerates many concrete capabilities: "Dockerfile design, multi-stage Maven builds, jlink custom runtimes, micro runtime distributions such as Alpaquita, JVM container ergonomics, non-root execution, image metadata, .dockerignore, reproducible builds, vulnerability scanning, SBOM awareness". This matches the anchor for multiple specific concrete actions with comprehensive coverage; it is above anchor 4 ("minor gaps") because coverage spans design, runtime, security, and supply-chain concerns with no obvious omissions.

5 / 5

Completeness

It explicitly answers "what" ("framework-agnostic Docker and container image guidance for Java projects" with a concrete topic list) and "when" ("This should trigger for requests such as ..." with six concrete trigger phrases). Both are explicit and concrete, matching the top anchor; it is not anchor 4 because the "when" clause is not merely present but enumerated with realistic trigger requests.

5 / 5

Trigger Term Quality

Natural user-facing triggers are given verbatim ("Review Java Dockerfile; Improve Docker image security; Add jlink runtime to a Java container; Add containerization to a Java project; Optimize Java container image size; Review Docker build reproducibility") alongside natural keywords and synonyms (Docker, Dockerfile, container image, containerization, jlink, .dockerignore, SBOM). This exceeds anchor 4 ("a few natural terms missing") by covering both the casual phrasings users would say and the specific technical terms.

5 / 5

Distinctiveness Conflict Risk

The niche is clear ("framework-agnostic Docker and container image guidance for Java projects") and it explicitly scopes away overlap ("For framework runtime wiring, defer to the matching Spring Boot, Quarkus, or Micronaut skill"). It is not anchor 4 because the Java-specific, framework-agnostic framing leaves minimal overlap risk with sibling framework or testing skills.

5 / 5

Total

20

/

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.

Repository
jabrena/plinth
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.