CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

speckit

The Spec Kit specification-driven workflow in Meshtastic-Android - how a feature description becomes a spec, a plan, tasks and an implementation, and what the constitution requires at each step. Use this when asked to write or update a spec, plan or tasks file, or when working anywhere under `specs/`.

Quality

85%

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

81%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 well-organized orchestrator skill body: fully executable commands, a clearly sequenced workflow with an explicit analyze validation gate and fix-before-proceed feedback loop, and project-specific conventions. Its main weakness is conciseness — the frontmatter-duplicating Description section, the oversized constitution-principle-6 bullet, and inlined detail that belongs in separate reference files.

Suggestions

Cut the '## Description' section (it restates the frontmatter) and split constitution principle 6's docs-quality CI gate details — 'links, coverage, the DocBundleLoader registry, and locale layout/nav_order... blocking CI gate (docs-quality.yml)' — into a short summary here with the full gate rules in a reference file such as references/constitution.md.

Move time-sensitive content out of the main body or into a clearly labeled section: replace the pinned 'Current constitution (v1.4.2)' version reference with a pointer to the live '.specify/memory/constitution.md', and fold the legacy 'NNN-<slug>' numbering note into the Existing Specs section as an explicit legacy note.

Trim the Related Skills and Extension Hooks sections to one-line pointers (skill name + one trigger phrase) so the body stays a lean command index rather than accumulating detail inline.

DimensionReasoningScore

Conciseness

The body is mostly efficient — command tables, a compact workflow diagram, and terse conventions — but includes content that could be tightened or offloaded: a '## Description' section that largely restates the frontmatter, an oversized single bullet for constitution principle 6 (inlining the full docs-quality CI gate details), and time-sensitive version pinning ('Current constitution (v1.4.2)') that the guidelines penalize outside a deprecated/versions section. This matches the anchor 'mostly efficient but includes some unnecessary explanation or could be tightened' rather than the 4 anchor, which requires only minor trimming.

3 / 5

Actionability

Guidance is fully executable for an orchestrator skill: copy-paste-ready invocations ('/speckit.specify "Feature description here"', '/speckit.workflow speckit "Describe the feature"'), a complete command table with purposes, exact file paths ('specs/<YYYYMMDD-HHMMSS>-feature-name/', '.specify/memory/constitution.md'), concrete naming examples ('20260511-211823-compose-screenshot-testing', 'SST-T001'), and a specific config toggle ('auto_execute_hooks: true' in '.specify/extensions.yml'). This matches the 5 anchor: commands cover the common cases with specific examples.

5 / 5

Workflow Clarity

The end-to-end sequence is numbered 1–6 with each step's output, an explicit validation checkpoint ('/speckit.analyze' with 'Fix any CRITICAL/HIGH findings before proceeding'), and a feedback loop (analyze → fix → proceed); the automated variant documents its review gates. This matches the 5 anchor ('clear sequence with explicit validation steps; feedback loops for error recovery'); the git commit/branch operations are covered by the analyze gate, so the destructive/batch cap does not apply.

5 / 5

Progressive Disclosure

The body is well-sectioned (commands, workflow, file structure, constitution, conventions, tips) and functions as an overview that delegates execution detail to the slash commands rather than inlining it. It is not a 5 because there are no one-level-deep reference files at all: detail-heavy blocks — the seven constitution principles (especially the docs-gate bullet) and the Meshtastic conventions — are inlined in SKILL.md where separate reference files would keep the overview leaner; structure is good but not optimally split.

4 / 5

Total

17

/

20

Passed

Description

83%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 strong description: it explicitly states both the what (the spec → plan → tasks → implementation pipeline with constitution gates) and the when (writing/updating spec, plan, or tasks files, or any work under `specs/`), with project-specific anchoring that keeps conflict risk low. The only improvement space is broadening trigger synonyms and naming more of the individual workflow capabilities.

DimensionReasoningScore

Specificity

The description names several concrete artifacts and transformations — 'how a feature description becomes a spec, a plan, tasks and an implementation, and what the constitution requires at each step' — which matches the anchor 'lists several specific actions; minor gaps in coverage'. It is not a 5 because the capabilities are narrated as a pipeline rather than enumerating the concrete operations (specify, clarify, plan, analyze, implement, issues conversion), leaving minor coverage gaps.

4 / 5

Completeness

It clearly answers both questions with concrete trigger phrases: 'what' is 'a feature description becomes a spec, a plan, tasks and an implementation, and what the constitution requires', and 'when' is explicit — 'Use this when asked to write or update a spec, plan or tasks file, or when working anywhere under `specs/`'. This matches the 5 anchor ('clearly and explicitly answers both what AND when with concrete trigger phrases'); it is above the 4 anchor because the 'when' clause is specific (named file types plus an exact directory scope) rather than generic.

5 / 5

Trigger Term Quality

Natural trigger terms are present — 'spec', 'plan', 'tasks file', 'specification-driven', 'specs/' — phrases a user would actually say when asking for spec work. It falls short of the 5 anchor because common variations like 'specification', 'spec.md', 'tasks.md', or 'analyze' are missing from the trigger set.

4 / 5

Distinctiveness Conflict Risk

The niche is distinct — 'Spec Kit specification-driven workflow' anchored to 'Meshtastic-Android' and the 'specs/' directory gives clear, project-specific triggers unlikely to fire for unrelated skills. Minor overlap risk remains with closely related project skills such as 'implement-feature' and 'code-review', which also activate around specs and implementation work, so it sits at the 4 anchor rather than 5.

4 / 5

Total

17

/

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

meshtastic/Meshtastic-Android

Path

.skills/speckit/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.