engram-plugin-thin

Adapter boundary rules for plugin integrations. Trigger: Changes in plugin scripts/hooks for Claude, OpenCode, Gemini, or Codex.

Quality

62%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/plugin-thin/SKILL.md

Quality

Content

60%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 a model of brevity and clean structure for a simple rule-set skill, but its rules stay at the descriptive level rather than giving executable guidance, and the workflow lacks explicit validation gates for what is essentially a multi-agent compatibility operation.

Suggestions

Add one concrete executable example showing the intended thin-adapter shape (e.g. a small pseudocode or real snippet of 'parse input -> call API -> return') to lift actionability past high-level hints.

Turn the Compatibility Checklist into a guarded workflow with explicit pass/fail gates and a 'only proceed when all boxes pass' step so the multi-agent verification has validation checkpoints.

Clarify what 'reuse a shared contract' means concretely — name the contract file or type — so the rule is actionable instead of abstract.

Dimension	Reasoning	Score
Conciseness	The body is extremely lean (~20 lines): short imperative rules and a tight checklist with no padding and no explanation of concepts Claude already knows; every token earns its place.	5 / 5
Actionability	Guidance is high-level ('Keep adapters thin: parse input, call API/tool, return') with no executable code, commands, or concrete examples showing how to parse or call; the rules describe rather than instruct, leaving the specific execution steps missing.	2 / 5
Workflow Clarity	There is a clear sequenced checklist for verifying compatibility across the supported agents, but the boundary rules themselves lack validation checkpoints, and the checklist is a verification aid rather than a guarded multi-step workflow with explicit pass/fail gates.	3 / 5
Progressive Disclosure	The skill is under 50 lines, single-purpose, and well-organized into three clearly headed sections (When to Use, Boundary Rules, Compatibility Checklist) with no need for external references — meeting the simple-skill exception for a top score.	5 / 5
	Total	15 / 20 Passed

Description

65%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 is concise, third-person, and answers both what and when with concrete trigger cues tied to named agents. Its main weakness is that the substantive actions are deferred to the body, leaving the description itself light on concrete capabilities.

Suggestions

Fold one or two concrete boundary actions into the description itself (e.g. 'Enforce thin adapters: parse input, call the API, return; push complex logic to the Go core.') so the 'what' is concrete, not just the domain.

Reframe the trigger as a natural user-facing phrase rather than an internal cue, e.g. 'Use when editing agent plugin hooks/adapters for Claude, OpenCode, Gemini, or Codex.'

Avoid the 'Trigger:' label keyword; it reads as metadata rather than the prose-style triggers the rubric's good examples use.

Dimension	Reasoning	Score
Specificity	Names the domain (plugin integrations) and concrete actions are implied via 'scripts/hooks' and 'setup behavior', but the actual rule verbs ('Keep adapters thin', 'Put complex logic in Go core') live in the body rather than the description, so it lists the domain with only weakly-stated actions.	3 / 5
Completeness	Provides a clear 'what' (adapter boundary rules) and an explicit 'when' via 'Trigger: Changes in plugin scripts/hooks...', but the 'when' is phrased as an internal cue rather than a natural user-facing trigger phrase, so it is present but could be more explicit.	4 / 5
Trigger Term Quality	Includes natural product names a user would say ('Claude', 'OpenCode', 'Gemini', 'Codex') plus 'plugin scripts/hooks' as trigger terms, giving good keyword coverage with only minor common-variation gaps (e.g. no mention of 'adapters' or 'integrations' as user-facing terms).	4 / 5
Distinctiveness Conflict Risk	The four named agents plus 'plugin scripts/hooks' carve a fairly distinct niche of agent adapter maintenance, with only minor overlap risk against a generic 'Claude Code' or coding skill.	4 / 5
	Total	15 / 20 Passed

Validation

100%

Warnings & errors only

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: Gentleman-Programming/engram
Path: skills/plugin-thin/SKILL.md
Commit: 47f281c

Reviewed: 6 days ago

Table of Contents

Discovery Implementation Validation

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.