CtrlK
BlogDocsLog inGet started
Tessl Logo

create-rt-issue

Create a GitHub issue in camunda/camunda for load-test/Reliability Testing (RT) work, extending create-issue with the component/load-tests label and an rt/foundation, rt/coverage, or rt/enablement classification. Use when asked to create, file, or open an RT/load-test issue.

71

Quality

86%

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

SKILL.md
Quality
Evals
Security

Quality

Content

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

A compact, well-structured extension skill that delegates the common flow to create-issue and adds only RT-specific overrides with concrete labels and inference rules. Adding a full gh issue create example and a post-creation verification step would lift actionability and workflow clarity.

Suggestions

Include a concrete `gh issue create` example showing the full label set (kind/<type>, component/load-tests, rt/*, discovered-by/load-tests) so guidance is copy-paste ready.

Add an explicit post-creation validation checkpoint (e.g. confirm the issue URL, verify all intended labels are present) to strengthen the workflow feedback loop.

State where the inferred `kind/<type>` comes from if not from create-issue's body labeler, since labels are now passed explicitly.

DimensionReasoningScore

Conciseness

Lean and efficient — it assumes Claude's familiarity with create-issue, explains only the RT-specific deltas (override mapping, label table, inference rules), and avoids restating the parent flow or any concepts Claude already knows.

5 / 5

Actionability

Concrete, specific guidance — exact labels, an explicit label-to-meaning table, and precise inference rules plus 'pass all applicable labels explicitly on gh issue create' — but stops short of a full copy-paste command example, keeping it just below the 5 anchor.

4 / 5

Workflow Clarity

A clear sequence (invoke create-issue, apply Override 1 replacing Step 3, apply Override 2 alongside Step 2) with an explicit ambiguity checkpoint ('ask the user to pick one before proceeding — do not guess or apply more than one'), but lacks a full validate→fix→retry feedback loop that would reach 5.

4 / 5

Progressive Disclosure

Under 50 lines, no external references required, and well-organized into Procedure / Override 1 / Override 2 / Labels passed at creation sections — meeting the simple-skill exception for a clean 5.

5 / 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.

A tightly scoped, third-person description that clearly states both capability and trigger conditions with concrete labels and classification terms. Its only weakness is modest synonym coverage in the trigger clause.

DimensionReasoningScore

Specificity

Names the domain and several concrete actions — 'Create a GitHub issue... extending create-issue with the component/load-tests label and an rt/foundation, rt/coverage, or rt/enablement classification' — but deliberately defers the full creation flow to create-issue, leaving minor coverage gaps relative to the comprehensive 5 anchor.

4 / 5

Completeness

Explicitly answers both 'what' (create an RT GitHub issue extending create-issue with specific labels and classification) and 'when' ('Use when asked to create, file, or open an RT/load-test issue') with concrete trigger phrases, matching the 5 anchor.

5 / 5

Trigger Term Quality

'Use when asked to create, file, or open an RT/load-test issue' surfaces several natural phrasings users would say, though it lacks broader synonyms or variations that would warrant a 5.

4 / 5

Distinctiveness Conflict Risk

A clear niche — RT/load-test issues only — with an explicit 'extending create-issue' relationship and a narrow trigger ('RT/load-test issue'), giving minimal overlap with sibling skills.

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
camunda/camunda
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.