CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

apportion

One goal is about to be handed to an autonomous run: the user takes a plan of units with checks, accepted gaps and held judgments, seeing what needed settling first and what returns at the end.

Quality

56%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./merismos/skills/apportion/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

48%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 a densely engineered formal contract: its workflow sequencing and validation logic are genuinely strong, with explicit gates and error-recovery paths for the carrier-write and handoff failure modes. But it buries that clarity under extreme verbosity — an inline Lean specification of nearly 900 lines plus triple restatement in prose — and never once shows a worked example of the sheet or emission it demands, leaving execution to inference despite highly specific structural instructions.

Suggestions

Move the ~870-line Lean formal block to a reference file (e.g. references/contract.lean) loaded only when formal detail is needed, keeping SKILL.md to the protocol prose — the same occasion-bound loading principle round-composition.md already applies (conciseness, progressive_disclosure).

Add one worked example: a small sample sheet (goal, one or two units with certificates, authority lines, focus) and the matching emission, so the demanded output form is shown rather than inferred (actionability).

Deduplicate the Rules section against Protocol — statements like "every line drawn on every sheet" and the handoff- obligations rule appear nearly verbatim three or more times; keep each rule once and cross-reference (conciseness).

DimensionReasoningScore

Conciseness

The body is ~1050 lines dominated by an ~870-line inline Lean formalization, a single-sentence ~450-word "Definition" paragraph, and the same plan-sheet content restated across Definition, Core Principle, Protocol, and Rules — "Every line is drawn on every sheet" and its companions appear in nearly identical words three or more times. This is noticeably verbose with several padded/redundant sections; it avoids anchor 1 only because it does not explain concepts Claude already knows — the padding is novel-but-duplicated contract material, not filler.

2 / 5

Actionability

Concrete procedural guidance exists ("On a taking, emit one entry per unit with its whole certificate — every check, every accepted gap, every held-open item... Park the packaged plan in one durable carrier and emit a navigation block that points to it"), and relay/exception conditions are specific. But there is no worked example — no sample sheet, unit, certificate, or emission format — and dense contract vocabulary ("contrary grounds", "the host's standing procedural contract") leaves the executor to infer most output form. "Some concrete guidance but incomplete" fits; not 4 because executing this still requires heavy interpretation.

3 / 5

Workflow Clarity

The FLOW comment and the apportion/start definitions give a real sequence (ground pointer → pass → sheet → Stop; taking → emit → park carrier → record → handoff) with explicit validation gates (Closable, Recorded, tooThin relay) and error-recovery loops ("Where the carrier write comes back incomplete, nothing closes: the sheet is drawn again and says what the .recordHandoff grounding names"). "Clear sequence with most checkpoints present; minor validation gaps" fits — not 5, because the flow must be synthesized from scattered sections rather than read as one explicit checklist, and validation is expressed as abstract predicates rather than runnable checks.

4 / 5

Progressive Disclosure

Sections are well-organized with clear headers, and references/round-composition.md is a real, well-signaled, one-level-deep reference with explicit load conditions ("Read references/round-composition.md before composing when terminology must remain stable, wording must travel unchanged..."). However, the ~870-line Lean formal block inlined in SKILL.md is precisely the content that belongs one level deep — the reference file itself states the occasion-bound loading principle the formal block violates — leaving "content that should be separate is inline". Fits anchor 3; not 2 (structure and signaling are otherwise good), not 4 (the monolithic inline block is a major placement gap, not a minor one).

3 / 5

Total

12

/

20

Passed

Description

45%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 reads as narrative prose about the user's experience rather than a capability statement: it evokes the domain but never says what the skill does or when to invoke it, and leans on internal vocabulary ("accepted gaps and held judgments") that no user would utter. It is a step above generic filler but below the rubric's good examples on every dimension.

Suggestions

Open with the skill's concrete actions instead of narrating the user's experience — e.g. "Cuts one autonomous goal into coarse execution units, derives each unit's completion checks and invariants, and hands the conditioned plan to the run" — so the 'what' is explicit (specificity, completeness).

Add an explicit trigger clause with natural user phrasing, e.g. "Use when the user mentions handing a goal to an autonomous run, breaking work into units before an unattended run, or planning what each unit must achieve" (completeness, trigger_term_quality).

Replace internal jargon ("accepted gaps and held judgments") with terms a user would actually say ("accepted gaps in coverage", "decisions held open") and add common synonyms such as milestones, breakdown, or handoff (trigger_term_quality, distinctiveness).

DimensionReasoningScore

Specificity

The description names the domain ("a plan of units with checks, accepted gaps and held judgments" for "an autonomous run") but never states an action the skill itself performs — there is no equivalent of "cuts the goal into units" or "derives each unit's completion checks"; it narrates the user's experience ("the user takes a plan... seeing what needed settling first") instead. This matches the anchor "Names the domain but actions are minimal or generic" — not 3, which requires 1-2 concrete actions; not 1, since it is not purely abstract filler.

2 / 5

Completeness

A discernible 'what' is implied only through the artifact ("the user takes a plan of units with checks..."), and the 'when' is weakly implied by the opening "One goal is about to be handed to an autonomous run"; there is no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3. It is above 2 because both a what and a when are present in weak form.

3 / 5

Trigger Term Quality

Some relevant keywords are present ("goal", "autonomous run", "plan", "units", "checks"), but internal jargon no user would say ("accepted gaps and held judgments") is prominent and common variations (break down, milestones, hand off to an agent) are missing. This fits "Some relevant keywords but missing common variations or synonyms" — better than 2 (more than one or two generic keywords), short of 4 (no good natural-phrase coverage).

3 / 5

Distinctiveness Conflict Risk

The autonomous-run framing ("One goal is about to be handed to an autonomous run") carves a niche, but generic terms ("goal", "plan", "checks") leave real overlap risk with general planning/decomposition skills, and no distinguishing term ("apportion", unit decomposition for unattended runs) appears in the description. "Somewhat specific but could still overlap with similar skills" fits best — not 4, since the triggers are not clearly distinct.

3 / 5

Total

11

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (1050 lines); consider splitting into references/ and linking

Warning

Total

15

/

16

Passed

Repository

jongwony/epistemic-protocols

Path

merismos/skills/apportion/SKILL.md

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.