CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

portaljs-connect-ckan

Wire a scaffolded PortalJS portal to a CKAN backend over its API. Generates a tiny server-side fetch client (no runtime dependency) and feeds the /search catalog and /@namespace/slug showcases from CKAN instead of datasets.json. Use when connecting an existing portal to a live CKAN instance instead of a static manifest.

Quality

89%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

85%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-structured skill body: a tight step summary delegating the full workflow to a canonical doc, a real one-level reference file, explicit validation checkpoints, and a feedback-oriented error table. The only weaknesses are slight repetition in the Overview and that the generated client is specified but its code is not inlined anywhere in the bundle.

Suggestions

Inline a minimal executable snippet of the ckanAction fetch helper in SKILL.md (or in references/reference.md) so step 4's client generation is executable without fetching the external command doc.

Trim the Overview's restatement of the static-pre-render rationale ("so the catalog is pre-rendered at build time and the site can still be statically deployed") since getStaticProps/getStaticPaths already implies it.

DimensionReasoningScore

Conciseness

The body is efficient: an 8-step summary delegates the full workflow to a canonical doc, the error table is compact, and the React 19 / @portaljs/ckan caveat is genuinely non-obvious knowledge. Minor over-explanation could be trimmed — e.g., "so the catalog is pre-rendered at build time and the site can still be statically deployed" restates the point already made by "fetch CKAN server-side in getStaticProps/getStaticPaths", and the Overview repeats the catalog/showcase rewire story told again in Instructions and Output. Fits anchor 4 (efficient, minor instances that could be trimmed) rather than 5.

4 / 5

Actionability

Concrete and mostly executable: named files (lib/ckan.ts, pages/search.tsx, pages/[owner]/[slug].tsx), named endpoints (package_search?rows=1, organization_show), runnable commands (npx next build, npm run i18n:check), and copy-paste invocations in Examples. The gap is that the main artifact — the generated fetch client — is specified but not shown; the actual code lives in the external canonical doc, so the body alone gives a specification rather than code. That is a minor gap, matching anchor 4 rather than 5; it is well above anchor 3 since steps, commands, and validation calls are all concrete.

4 / 5

Workflow Clarity

Eight clearly sequenced steps with explicit validation checkpoints: step 3 verifies the CKAN backend is reachable and validates org filters, step 7 verifies the build ("fix any error before reporting success"), and step 8 reports what changed. The Error Handling table adds feedback loops (re-prompt on bad URL, list valid orgs via organization_list, fix the first error and re-run the build). This matches the anchor-5 pattern of sequence + explicit validation + error-recovery loops; anchor 4 would require a missing checkpoint.

5 / 5

Progressive Disclosure

Well-organized sections (Overview, Prerequisites, Instructions, Output, Error Handling, Examples, Resources) with one-level-deep references that all resolve: references/reference.md exists in the bundle and holds the detail (env vars, endpoint table, filters, troubleshooting) without nesting further, and the canonical workflow doc is clearly signaled in both Instructions and Resources. Matches anchor 5 (clear overview, well-signaled one-level references, easy navigation); not 4 since there are no organization gaps to cite.

5 / 5

Total

18

/

20

Passed

Description

92%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 highly specific, third-person description that states concrete actions with exact route and artifact names and closes with an explicit "Use when…" trigger clause. Its only weakness is modest keyword synonym coverage beyond the core "connect/CKAN/portal" phrasing.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — "Wire a scaffolded PortalJS portal to a CKAN backend over its API", "Generates a tiny server-side fetch client (no runtime dependency)", "feeds the /search catalog and /@namespace/slug showcases from CKAN instead of datasets.json" — naming the exact routes, artifacts, and what gets replaced. All verbs are third person and every action is concrete; this matches the comprehensive-coverage anchor rather than the score-4 anchor, which permits minor gaps.

5 / 5

Completeness

Explicitly answers both questions: what ("Generates a tiny server-side fetch client… feeds the /search catalog and /@namespace/slug showcases from CKAN") and when ("Use when connecting an existing portal to a live CKAN instance instead of a static manifest"). The "Use when" clause is present, specific, and includes concrete trigger conditions, matching the anchor-5 example pattern; a 4 would require the when-clause to be less explicit than it is.

5 / 5

Trigger Term Quality

Includes natural terms a user would say — "connecting", "CKAN", "portal", "live CKAN instance", "backend", "static manifest", "datasets.json" — but coverage is not exhaustive: common variations like "data portal", "link/hook up", or "catalog backend" phrasings are absent. Good keyword coverage with a few natural terms missing fits anchor 4; not 3 (the key phrase "connect … CKAN" is exactly what users say) and not 5 (no synonym/extension-level coverage).

4 / 5

Distinctiveness Conflict Risk

The niche is narrow — connecting an existing PortalJS portal to a live CKAN instance — and the trigger explicitly distinguishes it from sibling skills ("instead of a static manifest", "connecting an existing portal" vs. scaffolding, adding datasets, or deploying). Conflict risk with other skills is minimal, matching anchor 5; anchor 4 would require noticeable overlap with closely related skills, but the related portaljs skills each have clearly separate triggers.

5 / 5

Total

19

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

14

/

16

Passed

Repository

datopian/portaljs

Path

skills/portaljs-connect-ckan/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.