target-bind

Use when the user wants to bind a Unit (or many Units) to a destination — a specific Kubernetes cluster+namespace, an ArgoCD Application, a Flux Kustomization, an OCI registry, a Tofu workspace. Phrases like "set up a target", "point this unit at my cluster", "bind these units to prod", "hook up Argo/Flux", "change the namespace this deploys to", "promote these to a different target". Creates or updates a Target with the right provider/toolchain and parameter JSON, attaches Units via cub unit set-target (or --where for bulk), and stops without applying — apply is cub-apply's job. Do not load for installing a worker (use worker-bootstrap first — Targets reference Workers), for running apply (use cub-apply), or for authoring the Unit's YAML (use config-as-data).

Quality

88%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Discovery

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is an excellent skill description that covers all dimensions thoroughly. It provides specific concrete actions, rich natural trigger phrases, clear what/when guidance, and explicit negative boundaries to prevent conflicts with related skills. The description is detailed yet focused, making it easy for Claude to correctly select this skill from a large pool.

Dimension	Reasoning	Score
Specificity	Lists multiple specific concrete actions: creates/updates a Target with provider/toolchain and parameter JSON, attaches Units via 'cub unit set-target' (or --where for bulk), and explicitly states it stops without applying. Also enumerates specific destination types (Kubernetes cluster+namespace, ArgoCD Application, Flux Kustomization, OCI registry, Tofu workspace).	3 / 3
Completeness	Clearly answers both 'what' (creates/updates Targets, attaches Units, supports multiple providers) and 'when' (explicit trigger phrases and use-case guidance). Also includes explicit 'do not use when' guidance distinguishing it from worker-bootstrap, cub-apply, and config-as-data skills.	3 / 3
Trigger Term Quality	Excellent coverage of natural trigger phrases users would say: 'set up a target', 'point this unit at my cluster', 'bind these units to prod', 'hook up Argo/Flux', 'change the namespace this deploys to', 'promote these to a different target'. Also includes domain-specific terms like Kubernetes, ArgoCD, Flux, OCI, Tofu workspace.	3 / 3
Distinctiveness Conflict Risk	Highly distinctive with explicit boundary-setting: 'Do not load for installing a worker (use worker-bootstrap first), for running apply (use cub-apply), or for authoring the Unit's YAML (use config-as-data).' This directly addresses conflict risk with related skills and carves out a clear niche.	3 / 3
	Total	12 / 12 Passed

Implementation

77%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a strong, highly actionable skill with excellent workflow clarity — clear sequencing, preflight gates, stop conditions, and verification steps. The main weakness is moderate verbosity (some sections like 'What a Target is' and 'Evidence' could be trimmed) and references to bundle files that don't exist. The provider/toolchain table and executable CLI examples are particularly well done.

Suggestions

Trim the 'What a Target is' section to 1-2 sentences — Claude can infer entity semantics from the commands and parameters.

Consolidate 'Verify chain' and 'Evidence' into a single verification section to reduce redundancy.

Dimension	Reasoning	Score
Conciseness	The content is mostly efficient and well-structured, but includes some sections that could be tightened — e.g., the 'What a Target is' explanation and the 'Do not load for' section partially restate information Claude could infer from the skill description. The 'Evidence' section is somewhat redundant with 'Verify chain'. Overall reasonably lean but not maximally token-efficient.	2 / 3
Actionability	Provides fully executable, copy-paste-ready CLI commands for every step: target creation (single and multi-provider), unit binding (single and bulk), verification commands, and parameter JSON examples. The provider/toolchain table is concrete and immediately usable.	3 / 3
Workflow Clarity	The workflow is clearly sequenced (steps 1-6) with explicit preflight gates, stop conditions, and a thorough verify chain. Validation checkpoints are well-defined: checking worker existence before proceeding, verifying KubeContext accessibility, confirming blast radius for bulk operations, and post-creation verification steps.	3 / 3
Progressive Disclosure	References to external docs and files are present (references/triggers-recipes.md, references/cub-cli.md, references/filters-and-queries.md, external docs URLs), but no bundle files are provided to support them. The content is somewhat long and could benefit from splitting the provider parameter details or trigger-filter configuration into separate reference files rather than inlining everything.	2 / 3
	Total	10 / 12 Passed

Validation

81%

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 — 9 / 11 Passed

Validation for skill structure

Criteria	Description	Result
allowed_tools_field	'allowed-tools' contains unusual tool name(s)	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	9 / 11 Passed

Repository: confighub/confighub-skills
Commit: 59ea831

Reviewed: about 18 hours 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.