CtrlK
BlogDocsLog inGet started
Tessl Logo

add-block

Create or update a Sim integration block with correct subBlocks, conditions, dependsOn, modes, canonicalParamId usage, outputs, and tool wiring. Use when working on `apps/sim/blocks/blocks/{service}.ts` or aligning a block with its tools.

66

Quality

81%

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

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

Extremely actionable, repo-specific content with genuine validation gates — the strongest part of the skill. The weaknesses are structural: a ~1050-line monolithic body with no bundle files, heavy reference material inlined where progressive disclosure expects separate reference files, and a closing checklist that duplicates the body's content. Splitting the reference sections into references/ files and trimming the redundant checklist would raise both conciseness and progressive disclosure without losing guidance.

Suggestions

Move the SubBlock Types Reference, File Input Handling, and OAuth deployment-availability sections into references/ files (e.g. references/subblock-types.md, references/file-input.md) and keep one-line pointers in SKILL.md — this fixes both the monolithic structure and the token budget.

Replace the 29-item checklist with a short pointer to the 'Final Validation' section, or deduplicate it against the body so each gate appears once; nearly every item restates a rule already stated above.

Expand the opening 'Your Task' into the real ordered sequence (author block and meta → register in registry-maps.ts → regenerate generated artifacts → run checks) so the workflow does not have to be reconstructed from scattered sections.

DimensionReasoningScore

Conciseness

The ~1050-line body is dense and mostly genuinely non-obvious repo knowledge (canonicalParamId serialization semantics, deployment gating, generated-artifact rules) rather than concepts Claude already knows, so it does not fall to score 2. But it is noticeably over budget for a SKILL.md body: the SubBlock Types Reference, File Input Handling, and Generated Artifacts sections are full reference manuals inlined rather than pointed to, and the closing checklist re-states body content almost line for line. Mostly efficient content, delivered in a form that could be tightened considerably — anchor 3.

3 / 5

Actionability

Nearly every section gives executable TypeScript, exact file paths, exact function names (getScopesForService, createVersionedToolSelector, normalizeFileInput), and runnable commands (`bun run docs:check`, `bun run check-canvas-sentences.ts --block={service}`). The complete annotated BlockConfig example plus the explicitly good/bad snippets make the guidance copy-paste ready and cover common cases.

5 / 5

Workflow Clarity

The 'Final Validation (Required)' section gives a numbered sequence with explicit verification of each tool in tools.access, the checklist enumerates every gate, and validation commands with failure feedback loops are given throughout (docs:check failure on stale artifacts, check-block-registry rules, fork-dependent-coverage). Not score 5 because the opening 'Your Task' sequence is a three-line stub and the real ordering of work (author, register, regenerate artifacts, validate) must be inferred by stitching together sections scattered across the document.

4 / 5

Progressive Disclosure

No references/, scripts/, or assets/ bundle files exist — everything lives in one monolithic SKILL.md, and ~600 lines of it (SubBlock Types Reference, File Input Handling, OAuth deployment availability, Generated artifacts) is exactly the reference material that anchor 3/2 says belongs in separate, on-demand files. It scores 3 rather than 2 because the body is well-sectioned with clear headers and the pointers it does give are clearly signaled and one level deep (apps/sim/blocks/AGENTS.md, the /add-trigger and add-selector skills, .agents/skills/tool-registry-boundary/SKILL.md).

3 / 5

Total

15

/

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 strong description: third-person, concrete, states what and when explicitly, and is tightly scoped to a specific file path and domain. The only weakness is trigger-term breadth — a few natural user phrasings and service-specific variations are not covered. Scored 5 on specificity, completeness, and distinctiveness; 4 on trigger terms.

Suggestions

Broaden the 'when' clause with one or two natural user phrasings beyond the file path, e.g. 'or when the user asks to add or update an integration for a service' to catch requests that never name the block file.

Consider mentioning that this covers the full lifecycle (creating, updating, migrating to V2) so users asking to 'upgrade a legacy block' trigger it too.

DimensionReasoningScore

Specificity

The description names the domain ('Create or update a Sim integration block') and enumerates multiple concrete capabilities: 'subBlocks, conditions, dependsOn, modes, canonicalParamId usage, outputs, and tool wiring'. This matches the anchor for comprehensive coverage of specific concrete actions; nothing is vague or padded.

5 / 5

Completeness

It explicitly answers both questions: 'Create or update a Sim integration block with correct ...' states the what, and 'Use when working on `apps/sim/blocks/blocks/{service}.ts` or aligning a block with its tools' gives a concrete when with trigger conditions. This is the anchor-5 pattern; it is not score 4 because the when clause is specific rather than generic.

5 / 5

Trigger Term Quality

'Use when working on `apps/sim/blocks/blocks/{service}.ts` or aligning a block with its tools' gives concrete, natural triggers (the block file path, 'aligning a block with its tools'), but coverage is narrower than the anchor-5 pattern of synonyms and varied phrasings — a user asking to 'add a new Slack integration' or 'fix a block's outputs' is only partly covered. Not score 3, since the terms present are specific and users would plausibly say them in this repo.

4 / 5

Distinctiveness Conflict Risk

The description carves a clear niche (Sim block authoring, a specific repo path, specific config concepts like canonicalParamId and dependsOn) that no generic skill would trigger for. Conflict risk with sibling skills (add-trigger, add-selector, add-tools) is explicitly bounded by the 'aligning a block with its tools' framing.

5 / 5

Total

19

/

20

Passed

Validation

81%

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

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (1051 lines); consider splitting into references/ and linking

Warning

frontmatter_unknown_keys

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

Warning

referenced_paths_exist

Referenced path issues: 2 missing

Warning

Total

13

/

16

Passed

Repository
simstudioai/sim
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.