CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

mcclowes/pseudocode

Use before implementing any non-trivial logic — algorithms with subtle invariants, state machines, parsers/evaluators, numerical or financial formulas, concurrency, or anything where correct-looking code is routinely subtly wrong. Write a short language-agnostic plan (data shapes + invariants, control flow, edge cases, interface contract) and check it before generating code. Triggers on "implement this algorithm", "write a function that…", "build a parser/state machine/scheduler", "compute this formula", reworking tricky logic, or any coding task where the hard part is getting the logic right rather than wiring things together. Skip it for CRUD, glue, config, and plumbing where the code is already the spec. Apply this whenever the expensive risk is a logic bug — an off-by-one, a missed null, a wrong ordering, a broken invariant — not just when the user says "pseudocode".

Quality

94%

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

Overview
Quality
Evals
Security
Files

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.

A tightly written, highly actionable instruction skill with a clear gated workflow, explicit checklists, and a feedback loop. The two gaps are motivational prose in "Why this exists" that could be cut, and an orphaned bundle script (the abstraction-level linter) that the body never mentions.

Suggestions

Trim "Why this exists" to one or two sentences — the argument that verification is the bottleneck is background Claude doesn't need; the concrete guidance that follows stands on its own.

Add a self-check step referencing the existing bundle script, e.g. "Validate the plan: `python scripts/lint_pseudocode.py plan.md` checks section coverage, language-agnosticism, and the 60-line budget" — the linter exists for exactly this purpose but is currently undiscoverable.

Fold the closing commentary ("That `> vs ≥` line is the whole game…") into the example's introduction so the point is stated once instead of repeated after the example.

DimensionReasoningScore

Conciseness

The core guidance (gate signals, artifact sections, constraints, example) is dense and assumes Claude's competence, but the "Why this exists" section spends ~180 words on motivational argument ("Generating code is now nearly free; verifying it is the bottleneck") that could be trimmed to a sentence or two, and the closing commentary after the example repeats the section's point.

4 / 5

Actionability

Fully followable instruction-only guidance: an exact gate question with explicit yes/no signal lists, four named artifact sections with what each must contain, do/don't constraint examples ("Write `group rows by key`, not the call" vs `df.groupby(...)`), and a worked example at three abstraction levels. The pseudocode example is the explicitly justified point of the skill, not a substitute for executable code.

5 / 5

Workflow Clarity

Clear sequence — gate, "State the verdict before proceeding", write the plan, review it ("Keep the whole thing reviewable in under ~60 seconds"), implement against it, reconcile — with explicit validation ("check it before generating code"), a checklist (the four sections, "omitting a section is choosing not to look for that class"), and an error-recovery feedback loop ("If the plan turns out wrong while coding, fix the plan, don't just patch the code").

5 / 5

Progressive Disclosure

The body is well-organized with clear headers and appropriately keeps all core content inline in a single file, but the bundle's one auxiliary file, scripts/lint_pseudocode.py (whose docstring says it is "intended for both the skill (self-check)"), is never referenced anywhere in the body — the only navigation path to it is missing, so Claude would never discover or run the linter.

4 / 5

Total

18

/

20

Passed

Description

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

An exemplary description: it explicitly states what the skill does, when to apply it, when to skip it, and the concrete trigger phrases a user would naturally say. The only weakness is that its broadest trigger ("any coding task where the hard part is getting the logic right") creates minor conflict risk with closely related coding skills.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions: "Write a short language-agnostic plan (data shapes + invariants, control flow, edge cases, interface contract) and check it before generating code" — the artifact's four components are named explicitly, giving comprehensive coverage of what the skill does.

5 / 5

Completeness

Both what ("Write a short language-agnostic plan... and check it before generating code") and when ("Use before implementing any non-trivial logic", "Apply this whenever the expensive risk is a logic bug") are explicitly stated with concrete trigger phrases, plus explicit when-not-to-use guidance.

5 / 5

Trigger Term Quality

"Triggers on 'implement this algorithm', 'write a function that…', 'build a parser/state machine/scheduler', 'compute this formula', reworking tricky logic" covers natural phrases users would actually say, with synonyms (invariants, off-by-one, missed null, broken invariant) and explicit skip terms (CRUD, glue, config, plumbing).

5 / 5

Distinctiveness Conflict Risk

The pre-implementation pseudocode niche is clear and the skip list ("Skip it for CRUD, glue, config, and plumbing") disambiguates well, but "any coding task where the hard part is getting the logic right rather than wiring things together" and "reworking tricky logic" are broad enough to overlap with refactoring- and algorithm-implementation-adjacent skills — a minor overlap risk.

4 / 5

Total

19

/

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.

Reviewed

On this page