CtrlK
BlogDocsLog inGet started
Tessl Logo

propose-issue

Propose a GitHub issue as a MoltNet daemon task. Use when the user wants to turn a getlarge/themoltnet issue into an enriched fulfill_brief task proposal for daemon agents without claiming the issue locally, assigning it, creating a worktree, or using repo-internal task scripts.

72

Quality

88%

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

SKILL.md
Quality
Evals
Security

Quality

Content

88%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 well-structured, highly actionable workflow with explicit stop/validation checkpoints and copy-paste-ready code. Its main weakness is redundancy between the markdown brief template and the JS snippet, plus heavy inlining that progressive disclosure would otherwise split out.

Suggestions

De-duplicate the brief content: keep the canonical brief shape in one place (e.g., a references/brief-template.md) and have the JS snippet construct it from that shape, removing the near-identical markdown and JS copies.

Move the self-contained publish snippet into scripts/propose-issue.mjs and reference it from the body, reducing the inlined ~100-line block while preserving the skill's publishable-self-contained intent via a note.

Tighten the brief-shape prose (lines 97-135) to the essential sections so the workflow step reads as guidance rather than a near-complete restatement of the JS output.

DimensionReasoningScore

Conciseness

Generally lean with terse rules and code blocks, but the recommended markdown brief shape (lines 97-135) is largely duplicated by the JS brief-construction array (lines 206-237), a minor redundancy that keeps it at anchor 4 rather than anchor 5's "every token earns its place".

4 / 5

Actionability

Provides fully executable, copy-paste-ready guidance: concrete token-minting bash commands and a complete ESM snippet using @themoltnet/sdk with an explicit env-var invocation block, matching anchor 5's coverage of the common case.

5 / 5

Workflow Clarity

A clear 5-step sequence is packed with explicit validation/checkpoint gates ("stop and tell the user", "If this prints an empty token, stop", "ask whether to continue", "Ask once before publishing", "stop after the preview"), satisfying anchor 5's explicit validation steps and feedback loops; the publish is non-destructive with confirm gating so no destructive cap applies.

5 / 5

Progressive Disclosure

Well-organized single-file structure with clear headers and no nested references, but the large self-contained JS snippet and brief template are inlined rather than split into separate reference/script files (the self-contained inlining is justified, hence 4 not lower), and there are no external bundle files to signal.

4 / 5

Total

18

/

20

Passed

Description

87%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 third-person, concrete, and explicitly answers both what and when with a clear, distinct niche and explicit boundary exclusions. Its only gap is slightly narrower positive-action coverage and a few missing synonyms versus the top anchor.

Suggestions

Add a couple of natural trigger synonyms (e.g., "backlog", "queue up", "file a daemon task") so the trigger clause catches more phrasings users would naturally say.

Expand the positive action set slightly beyond a single propose/publish verb (e.g., "enrich", "preview", "publish") to push specificity toward anchor 5.

DimensionReasoningScore

Specificity

Names the core concrete action ("Propose a GitHub issue as a MoltNet daemon task" / "turn ... into an enriched fulfill_brief task proposal") and lists several concrete negative-boundary actions (no claiming, assigning, worktree, repo scripts), landing between anchor 3 (1-2 actions) and anchor 5 (comprehensive) at anchor 4's "several specific actions; minor gaps".

4 / 5

Completeness

Explicitly answers both what (propose/turn an issue into an enriched fulfill_brief task proposal for daemon agents) and when ("Use when the user wants to turn a getlarge/themoltnet issue into ..."), matching anchor 5's clear-and-explicit both what AND when with concrete triggers.

5 / 5

Trigger Term Quality

Natural keywords a user would say are present ("GitHub issue", "issue", "task", "proposal", "daemon") with an explicit "Use when the user wants to turn a ... issue into ..." trigger phrase; not anchor 5 because synonyms and variations are missing.

4 / 5

Distinctiveness Conflict Risk

A clear narrow niche (MoltNet daemon task proposals from getlarge/themoltnet issues) is explicitly differentiated from the sibling claim-issue and repo-internal scripts, giving minimal conflict risk per anchor 5.

5 / 5

Total

18

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
getlarge/themoltnet
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.