publish

Publish Seed specification as GitHub Issues for team-based project management

Quality

57%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/publish/SKILL.md

Quality

Content

68%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 gh-CLI workflow with strong upfront validation and user-gated checkpoints. Its main weakness is the absence of post-creation verification for this batch operation, which caps workflow clarity.

Suggestions

Add a verification step after Step 7 that confirms each `gh issue create` succeeded (e.g. check the captured URL/number is non-empty) and aborts with a clear message before deriving downstream issue numbers.

Tighten the repeated "MUST include -R <TARGET_REPO>" reminders and the RFC breadcrumb footer section to reduce redundancy and lift conciseness toward 5.

Consider extracting the large AskUserQuestion JSON blocks and Epic/Task heredoc templates into a reference file to improve progressive_disclosure and reduce inline density.

Dimension	Reasoning	Score
Conciseness	The body avoids explaining concepts Claude already knows and leads with executable `gh`/bash commands and mapping tables; minor redundancy (repeated "MUST include -R" reminders and the RFC breadcrumb section) keeps it just below 5.	4 / 5
Actionability	Concrete, executable commands (gh issue create, label create, heredoc Epic/Task templates, issue-number extraction) cover the common cases; minor gaps from the abstract task-grouping direction in 6a and templated placeholders prevent a 5.	4 / 5
Workflow Clarity	Steps 1-8 are well sequenced with several checkpoints (prereq Stop, duplicate warning, plan-modify loop), but this is a batch operation and there is no verification that issue creation succeeded before deriving EPIC_NUM, so the batch-verification cap holds at 3.	3 / 5
Progressive Disclosure	No bundle files exist; the single SKILL.md is well-sectioned into Usage, Steps 1-8, and Notes with clear headers, so structure is good, though dense inlined JSON/heredoc templates leave minor organization gaps.	4 / 5
	Total	15 / 20 Passed

Description

46%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 states a clear, specific purpose but omits any trigger guidance and leans on Ouroboros-specific jargon, so it answers "what" well while leaving "when" unanswered. It is distinct but would benefit from explicit user-facing trigger phrases.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user wants to turn a Seed spec into GitHub Issues, or says 'publish seed to github' / 'create issues from seed'."

Broaden trigger terms with natural synonyms users would actually say (e.g. "GitHub Issues", "epic", "tasks", "seed to issues") rather than relying on "Seed specification" jargon.

Optionally surface a second concrete action (e.g. "creates an Epic with linked Task issues") to lift specificity toward 4-5.

Dimension	Reasoning	Score
Specificity	Quotes "Publish Seed specification as GitHub Issues" — names the domain and one concrete action (publish to issues), but lists only a single action rather than several specific actions, so it sits at the 3 anchor rather than 4.	3 / 5
Completeness	A clear "what" is present ("Publish Seed specification as GitHub Issues") but no explicit "when"/trigger guidance, so per the rubric a missing "Use when" clause caps completeness at 3.	3 / 5
Trigger Term Quality	"GitHub Issues" is a natural term users say, but "Seed specification" is Ouroboros-specific jargon and the description includes no "Use when" trigger phrasing or synonyms, placing it between anchors 1 and 3.	2 / 5
Distinctiveness Conflict Risk	"Seed specification as GitHub Issues for team-based project management" carves a clear niche with minor overlap risk from generic GitHub-publishing skills; not a 5 because no distinct trigger phrases are stated.	4 / 5
	Total	12 / 20 Passed

Validation

100%

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

Validation for skill structure

No warnings or errors.

Repository: Q00/ouroboros
Path: skills/publish/SKILL.md
Commit: 80333ae

Reviewed: 3 days 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.