CtrlK
BlogDocsLog inGet started
Tessl Logo

spike

Run throwaway prototypes to validate feasibility, compare approaches, and report a verdict.

60

Quality

70%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/spike/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

75%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 tight, actionable skill body with a clear sequenced workflow, concrete output conventions, and a copy-paste verdict template. The two real defects are cosmetic/structural: section headings are plain text rather than markdown headers, and a trailing migration note injects non-instructional noise.

Suggestions

Convert "Loop", "Output shape", "Multi-spike ideas", "Verdict format", and "Rules" into proper markdown headings (## ...) so sections render and navigate correctly.

Delete the "PilotDeck Migration Note" section — temp-dir source paths and review status are migration metadata, not skill instructions.

Make the Stress step slightly more concrete (e.g. name one candidate failure mode class per artifact type, or require recording the observed failure in the verdict) to close the actionability and feedback-loop gap.

DimensionReasoningScore

Conciseness

The body is lean, bullet-first, and assumes Claude's competence ("create the smallest runnable artifact that validates or invalidates the idea"), but the "PilotDeck Migration Note" section — source temp-dir paths and review status — is migration metadata that earns no tokens, fitting anchor 4 ('minor instances that could be trimmed') rather than anchor 5.

4 / 5

Actionability

Concrete, executable guidance throughout: default workspace `.tmp/openclaw-spikes/<slug>`, repo layout `spikes/<NNN-slug>/`, a copy-paste-ready verdict template, "Split into 2-5 independent questions", "keep inputs equal and measure the same dimensions". Minor gaps — "read enough docs/source" and "try one edge case" remain high-level — place it at anchor 4 rather than fully-executable anchor 5.

4 / 5

Workflow Clarity

A clear five-step sequence (Question → Research → Build → Stress → Verdict) with the Stress step as an explicit checkpoint and evidence required in the verdict; no destructive/batch operations, so no cap applies. It lacks a validate→fix→retry feedback loop after Stress, keeping it at anchor 4 rather than 5.

4 / 5

Progressive Disclosure

The skill is under 50 lines and self-contained with no external references, eligible for 5 under the simple-skill guideline — but "Loop", "Output shape", "Multi-spike ideas", "Verdict format", and "Rules" are plain text lines rather than markdown headers, so sections are not well signaled; anchor 4 ('minor organization gaps') is the best fit.

4 / 5

Total

16

/

20

Passed

Description

66%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 concise, third-person description with concrete actions and a clear niche, but it is missing the "when" half entirely — no trigger phrases tell Claude (or a dispatcher) when to invoke it. Natural synonyms like "spike" and "proof of concept" would strengthen both trigger quality and distinctiveness.

Suggestions

Append a trigger clause, e.g. "Use when the user says 'spike this', 'quick prototype', 'is this possible', 'compare A/B', or asks for a proof of concept before committing to a build."

Include natural synonyms users would actually say — "spike", "proof of concept", "POC", "feasibility check" — to improve trigger term coverage.

Add a brief negative boundary (e.g. "Not for production implementation or questions answerable by reading docs") to further reduce overlap with general build/prototyping skills.

DimensionReasoningScore

Specificity

Lists three specific concrete actions — "Run throwaway prototypes", "validate feasibility", "compare approaches", "report a verdict" — but omits capabilities the body covers (multi-spike splitting, workspace conventions), matching anchor 4 ('several specific actions; minor gaps in coverage') rather than the comprehensive coverage of anchor 5.

4 / 5

Completeness

The "what" is clear and multi-action, but there is no "Use when..." clause or equivalent trigger guidance in the description; per the judging guideline this caps completeness at 3, exactly matching the anchor 'Has a clear what but when is missing'.

3 / 5

Trigger Term Quality

Natural terms like "throwaway prototypes", "compare approaches", and "validate feasibility" are present, but common synonyms users actually say — "spike", "proof of concept", "POC", "is this possible" — are missing (they exist only in the body), fitting anchor 4 ('good keyword coverage; a few natural terms missing').

4 / 5

Distinctiveness Conflict Risk

The throwaway-prototype/feasibility-verdict framing is a recognizable niche, but without trigger phrases in the description it could overlap with general prototyping or build skills, fitting anchor 4 ('mostly distinct; minor overlap risk').

4 / 5

Total

15

/

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
OpenBMB/PilotDeck
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.