CtrlK
BlogDocsLog inGet started
Tessl Logo

node-check

Verify one CCB worker node and reject hidden fallback, degradation, scope shrinkage, or missing evidence.

52

Quality

58%

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

Fix and improve this skill with Tessl

tessl review fix ./docs/plantree/plans/agentic-loop-workflow/drafts/agentroles.ccb_checker/skills/node-check/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is admirably lean and well-structured as an I/O contract, but it stops short of instructing: the verification procedure, decision criteria for each result class, and any check sequence are entirely missing, so an executor could not perform the check from this document alone.

Suggestions

Add a short ordered check sequence (e.g. 1. Compare delivered scope against assigned node scope, 2. Review evidence for each acceptance criterion, 3. Classify the result) with an explicit validation checkpoint before returning a result.

Define decision criteria for each result class — what evidence distinguishes `pass` from `rework_required` from `blocked` from `non_converged` — since the enum is currently the only concrete guidance.

Give one or two concrete examples of the failure modes to reject (e.g. what "hidden fallback" or "scope shrinkage" look like in a worker result), or move them to a reference file with a clear pointer.

DimensionReasoningScore

Conciseness

The body is 28 lines with zero padding: every line (inputs list, output classes, required report fields) earns its place and assumes Claude's competence with no concept explanations.

5 / 5

Actionability

The output contract is concrete ("Return exactly one result class: pass / rework_required / blocked / non_converged") and inputs are enumerated, but the procedure is absent — there is no guidance on how to detect "hidden fallback", "degradation", or "scope shrinkage", or what distinguishes one result class from another.

2 / 5

Workflow Clarity

No sequenced steps or validation checkpoints exist — the body frames inputs and outputs but never orders the verification work ("Use this skill after a worker returns a node result" is a trigger, not a workflow). It is not 1 because the document is coherent and the I/O frame is clear.

2 / 5

Progressive Disclosure

The skill is under 50 lines, needs no external references, and is organized into clear Inputs/Output sections; per the rubric's simple-skill guidance, well-organized sections alone warrant a 5. No bundle files exist, and the body references none.

5 / 5

Total

14

/

20

Passed

Description

57%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 specific and clearly niched, with a crisp statement of what it does and what it rejects. Its main weaknesses are the complete absence of a "when to use" trigger clause and reliance on unexplained domain jargon ("CCB") that limits natural trigger-term matching.

Suggestions

Add an explicit trigger clause, e.g. "Use when a worker returns a node result" — its absence caps completeness at 3.

Expand natural trigger terms users would actually say, such as "node result", "worker output", "check the worker", rather than relying on the unexplained acronym "CCB".

Name the concrete verification actions (e.g. "review evidence, compare against acceptance criteria, return a result class") to lift specificity from two verbs toward comprehensive coverage.

DimensionReasoningScore

Specificity

"Verify one CCB worker node" and "reject hidden fallback, degradation, scope shrinkage, or missing evidence" name the domain and two concrete actions with specific failure modes, but coverage is not comprehensive — there is no indication of how verification is performed or what the output looks like.

3 / 5

Completeness

The "what" is clear (verify a worker node and reject specific failure classes), but there is no "Use when..." clause or equivalent trigger guidance in the description, which caps completeness at 3.

3 / 5

Trigger Term Quality

Terms like "worker node", "verify", and "node result" are relevant to the domain, but "CCB" is unexplained jargon and natural user phrases or synonyms (e.g. "check the worker's result", "node review") are missing.

3 / 5

Distinctiveness Conflict Risk

"CCB worker node" carves out a clear niche that is unlikely to trigger for unrelated skills; the enumerated failure modes (hidden fallback, degradation, scope shrinkage) further distinguish it from generic verification skills.

5 / 5

Total

14

/

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
SeemSeam/claude_codex_bridge
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.