Name: flox-publish
Rating: 58.4 (1 reviews)
Author: flox

flox-publish

Use for publishing user packages to flox for use in Flox environments. Use for package distribution and sharing of builds defined in a flox environment.

Quality

66%

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 ./flox-plugin/skills/flox-publish/SKILL.md

Quality

Content

65%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 highly actionable with extensive executable command, manifest, and CI examples and a clear phased workflow, but it is verbose due to repeated commands and restated concepts, lacks explicit error-recovery feedback loops, and is monolithic with no progressive file structure for a skill of this length.

Suggestions

Deduplicate the publishing commands into one canonical reference and refer back to it instead of repeating `flox publish -o myorg ...` across sections.

Add an explicit feedback loop for build-validation failures (e.g., "If `flox build` fails in the clean clone: verify all deps are declared in [install], commit and push, then re-run").

Move the CI examples, Nix-expression publishing, and versioning strategies into referenced reference files (e.g., CI.md, VERSIONING.md) and keep SKILL.md as a concise overview, since no bundle files currently exist.

Dimension	Reasoning	Score
Conciseness	The ~480-line body is domain-specific and useful rather than generic fluff, but it repeats the same commands (`flox publish -o myorg ...` appears 5+ times) and restates the dev→runtime separation in both the workflow and the "Real-world Publishing Workflows" sections, so it could be tightened considerably.	2 / 3
Actionability	It is dense with fully executable, copy-paste-ready guidance: `flox build`/`flox publish` commands, manifest.toml build blocks, GitHub Actions and GitLab CI YAML, and a Nix expression example — matching the anchor for fully executable code/commands.	3 / 3
Workflow Clarity	The three-phase dev→build→runtime workflow and the personal→organization testing progression are clearly sequenced with validation (clean-build validation, local testing), but explicit error-recovery feedback loops ("if the clean build fails, do X then retry") are only implicit via the gotchas section.	2 / 3
Progressive Disclosure	No bundle files exist and the body references no external files; it is a single ~480-line document with clear section headers but with content that should be split out (CI examples, Nix expressions, versioning strategies, config/asset publishing) all inline, fitting the anchor for content that should be separate being inline.	2 / 3
	Total	9 / 12 Passed

Description

67%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 targets a clear niche and includes explicit "Use for..." trigger guidance answering both what and when, but it is repetitive (publishing/distribution/sharing are near-synonyms) and risks overlap with sibling flox skills. Trigger-term coverage is decent but lacks common variations.

Suggestions

Collapse the redundant actions into one clear clause and add distinct concrete verbs (e.g., "Publish built packages to the Flox catalog, distribute them to organizations, and share binaries across environments").

Replace the circular "Use for publishing... for use in Flox environments" with a situational trigger such as "Use when the user wants to publish, distribute, or share a flox package build."

Add distinguishing keywords (catalog, FloxHub, binaries/artifacts) and contrast with flox-sharing/flox-environments to reduce conflict risk.

Dimension	Reasoning	Score
Specificity	Phrases like "publishing user packages to flox", "package distribution", and "sharing of builds" name concrete actions in a specific domain, but the three actions overlap heavily (publishing/distributing/sharing are near-synonyms) rather than listing multiple distinct concrete actions as in the anchor-3 example.	2 / 3
Completeness	It states what the skill does (publishing/distributing/sharing packages) and provides explicit "Use for..." trigger guidance in both sentences; per the judging guidelines the presence of an explicit trigger clause means completeness is not capped at 2.	3 / 3
Trigger Term Quality	Natural terms a user would say are present ("publishing", "packages", "distribution", "sharing", "builds", "flox"), but the awkward phrasing "user packages" and the omission of common variations like "flox publish", "catalog", or "FloxHub" leave it at "some relevant keywords but missing common variations."	2 / 3
Distinctiveness Conflict Risk	The flox-publishing niche is fairly specific, but "sharing of builds defined in a flox environment" and "for use in Flox environments" overlap with sibling skills (flox-sharing, flox-environments) named in the body, so it could still trigger for a related skill.	2 / 3
	Total	9 / 12 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: flox/flox-agentic
Path: flox-plugin/skills/flox-publish/SKILL.md
Commit: 84ba858

Reviewed: 3 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.