Tessl • The management layer for AI agent skills

This is a dense, highly prescriptive hub skill: it assumes the reader's competence, provides concrete commands and explicit validation verdict-handling per harness, and delegates detail via clearly anchored one-level-deep links. Its weaknesses are extreme clause density in several rule paragraphs, inlining of reference-grade per-harness operational detail, and reliance on workflow files that are not present in the evaluated bundle. Overall a strong instruction-only skill whose structure would benefit from offloading the Long-Running Validation detail to a reference file.

Suggestions

Move the per-harness Long-Running Validation rows (Claude Code, Codex, Pi, warden hosts) into a reference file such as references/dev-validate-run.md, keeping only the routing rule and a table of harness→route in SKILL.md.

Ship workflows/dev-implement.md and workflows/dev-fix.md in the skill bundle — the body's section anchors (§ 1-11, § 5) point to them but they are absent, so the core process cannot be followed from the provided files.

Break the longest multi-clause rules (the Round Contract rebasing paragraph and Engineering Rules exceptions) into shorter declarative statements or a table so each rule states one constraint.

Dimension	Reasoning	Score
Conciseness	The body contains essentially no padding and no explanations of concepts Claude already knows — every sentence carries project-specific rules like "A test whose premise died is deleted whole in the commit that kills the premise", assuming high competence. It falls short of 5 because several passages (e.g., the Round Contract rebasing paragraph and the Long-Running Validation harness rows) are so clause-dense that they could be tightened or tabulated, and a few rules are restated across Round Contract and Validation.	4 / 5
Actionability	Concrete, copy-paste-shaped commands with explicit placeholders are given throughout: ".agents/skills/orch/scripts/dev-validate-run --worktree [WORKTREE_PATH]", "git diff --no-renames --name-only [PREVIOUS_ROUND_COMMIT] HEAD -- <each loaded file's repo path>", and "bg_task action: \"spawn\" with notifyOnExit: true", plus explicit output interpretation ("state=timeout and state=lost are both failed validations"). It is not 5 because the two core workflows themselves are only named as arrow chains and delegated to workflow files whose steps are not shown in this body.	4 / 5
Workflow Clarity	Sequences are stated explicitly ("activate → plan → implement → validate → commit → QA labels → summary → artifact → return (§ 1-11)") and validation is unusually explicit, including the run-notes question/answer protocol, interrupted-run recovery, and verdict routing for fail states. It stays at 4 rather than 5 because the detailed step-by-step execution lives in the referenced workflow files rather than here, and a few dense passages (the rebase-diff rule, the Engineering Rules exceptions) require re-reading to follow.	4 / 5
Progressive Disclosure	Section organization is good and cross-references are clearly signaled with one-level-deep markdown links (e.g., "[dev-implement.md § 5. Validate](workflows/dev-implement.md#5-validate)", "[../orch/references/waiter-launch.md](../orch/references/waiter-launch.md)"), but the skill's own bundle files referenced as core content (workflows/dev-implement.md, workflows/dev-fix.md) are not present in the bundle, and ~40 lines of reference-grade operational detail (the per-harness Long-Running Validation rows, Round Contract channel mechanics) are inlined in SKILL.md. This lands on the 'content that should be separate is inline' side of the 3 anchor rather than the 'most content is appropriately placed' of 4.	3 / 5
	Total	15 / 20 Passed

Description

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

The description is short, in third person, and gives an explicit 'Load when...' trigger clause with two concrete task framings, which keeps it functional and distinguishable. Its weaknesses are thin natural-language trigger coverage and a 'what' that is only implied inside the when-clause rather than stated independently. It is a solid, lean routing description with room to name more concrete capabilities and user phrasings.

Suggestions

State the 'what' independently of the trigger clause, e.g., 'Implements delegated issues end-to-end (plan, code, validate, commit, return artifact) and applies review fixes as a dev agent.'

Add natural trigger variations users would actually say, such as 'write the code for', 'address review comments', or 'fix review findings'.

Name the concrete deliverables (validated commit plus dev-return artifact) so the skill's output is explicit and less confusable with the reviewer skill.

Dimension	Reasoning	Score
Specificity	"implementing an issue or applying review fixes" names the dev-agent domain and exactly two concrete actions, matching the 'names domain and 1-2 concrete actions, but not comprehensive' anchor. It does not reach 4 because it lists only two actions with no detail on what implementation or fix application involves, and is not a 2 because the actions named are concrete rather than generic.	3 / 5
Completeness	The explicit trigger clause "Load when implementing an issue or applying review fixes as a dev agent" answers 'when' with concrete triggers, and the 'what' (implement issues, apply review fixes) is stated, though only embedded inside the when-clause rather than as an independent statement. It satisfies both what and when so it clears the 3 cap, but the what is not separately and fully articulated as the 5 anchor requires.	4 / 5
Trigger Term Quality	Relevant keywords like "implementing an issue", "applying review fixes", and "dev agent" are present, but common variations users would naturally say (e.g., "code the change", "address review comments", "fix findings", "write the implementation") are missing, matching the 'some relevant keywords but missing common variations or synonyms' anchor. It is above 2 because the terms present are domain-meaningful rather than generic, but below 4 because coverage of natural phrasings is thin.	3 / 5
Distinctiveness Conflict Risk	"implementing an issue or applying review fixes as a dev agent" carves a clear niche distinct from sibling skills like the reviewer skill (which performs reviews rather than applies fixes), with only minor overlap risk on the review-fixes side. It is below 5 because "applying review fixes" could plausibly collide with a review/QA skill's triggers, and above 3 because the dev-agent framing is specific rather than broadly overlapping.	4 / 5
	Total	14 / 20 Passed

Validation

75%

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 — 12 / 16 Passed

Validation for skill structure

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning
relative_links	Relative link issues: 7 missing, 16 suspicious	Warning
referenced_paths_exist	Referenced path issues: 1 missing	Warning

	Total	12 / 16 Passed

Repository: vanillagreencom/kendex
Path: skills/dev/SKILL.md
Revision: 32d7bc7

Reviewed: 13 hours ago

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.

dev

Table of Contents

Is this your skill?