CtrlK
BlogDocsLog inGet started
Tessl Logo

webhook-transforms

Generic framework for converting external events (SMS, meetings, social mentions) into brain-ingestible signals. Define a transform function, register a webhook URL, and incoming events get processed through the brain pipeline.

54

Quality

61%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./skills/webhook-transforms/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The content is well-structured and concise for a single-purpose skill, with clear sequencing and an error-handling loop. Its main weaknesses are actionability (the core transform function is described rather than shown as executable code) and workflow clarity (a mutating/batch skill that lacks an explicit post-write validation checkpoint, which the rubric caps at 3).

Suggestions

Add a minimal executable transform function (or a concrete template) for at least one example event so the central action is copy-paste ready rather than described in prose.

Insert an explicit validation checkpoint after writing the brain page (e.g. verify the page exists, confirm sanitization stripped HTML/script) before running entity extraction and `gbrain sync`, to lift workflow_clarity above the destructive/batch cap.

Collapse the redundant error-handling bullets ('Surface error type to agent' / 'Don't lose events') into the dead-letter-queue step to tighten conciseness toward 5.

DimensionReasoningScore

Conciseness

The body is lean — terse contract bullets, short phased steps, compact I/O examples — with no over-explanation of concepts Claude already knows; only minor redundancy (e.g. 'Surface error type to agent' / 'Don't lose events' partly restating the dead-letter bullet) keeps it at anchor 4 rather than 5.

4 / 5

Actionability

It provides concrete structure (file paths like `_dead-letter/{timestamp}.md`, commands `gbrain put` / `gbrain sync`), but the central 'transform function' is never given as executable code and the example transforms are illustrative I/O blocks, matching anchor 3 (some concrete guidance but incomplete / pseudocode-level).

3 / 5

Workflow Clarity

Phases are clearly sequenced and error handling offers a feedback loop (dead-letter queue + retry once), but this is a mutating/batch operation with no explicit validation checkpoint after writing brain pages or after sanitization; per the rubric's destructive/batch cap, missing validation holds workflow_clarity at anchor 3.

3 / 5

Progressive Disclosure

No bundle files exist and the body is under 50 lines, single-purpose, and well-organized into clearly labeled sections (Contract, Phases, Example Transforms, Output Format, Anti-Patterns), so the simple-skill exception lets progressive disclosure score 5 with no external references needed.

5 / 5

Total

15

/

20

Passed

Description

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

The description gives a concrete, reasonably specific account of what the skill does but omits an explicit 'Use when...' trigger clause and keeps the most natural trigger phrases in the separate `triggers` field rather than the description text. Specificity and distinctiveness are solid; completeness and trigger-term quality are the weaker dimensions.

Suggestions

Add an explicit 'Use when...' sentence naming the natural trigger phrases (e.g. 'Use when setting up a webhook, processing an incoming webhook event, or transforming an external event for the brain pipeline').

Pull one or two natural trigger terms ('set up webhook', 'process webhook event') into the description body itself instead of relying solely on the `triggers` field.

Tighten 'incoming events get processed through the brain pipeline' into a concrete action (e.g. 'write a sanitized brain page and extract entities') to lift specificity toward 5.

DimensionReasoningScore

Specificity

Names the domain ('converting external events (SMS, meetings, social mentions)') plus several concrete actions ('Define a transform function, register a webhook URL'), but 'processed through the brain pipeline' leaves coverage slightly incomplete, matching anchor 4 rather than 5.

4 / 5

Completeness

It clearly answers the 'what' (converting external events into brain-ingestible signals) but offers no 'Use when...' guidance, so 'when' is only weakly implied; per the rubric a missing explicit trigger clause caps completeness at 3.

3 / 5

Trigger Term Quality

Some relevant keywords appear ('SMS, meetings, social mentions', 'webhook URL'), but the natural trigger phrases users would say ('set up webhook', 'process webhook event') live in the `triggers` field rather than the description, leaving common variations missing per anchor 3.

3 / 5

Distinctiveness Conflict Risk

The webhook-to-brain-signal domain with SMS/meeting/social-mention sources is a fairly clear niche with only minor overlap risk against related ingestion skills, matching anchor 4 rather than the fully-distinct anchor 5.

4 / 5

Total

14

/

20

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

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

Warning

Total

15

/

16

Passed

Repository
garrytan/gbrain
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.