CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

engram-business-rules

Product and business-rule guardrails for Engram. Trigger: Any change that affects sync behavior, project controls, permissions, or memory semantics.

Quality

76%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/business-rules/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

78%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 body is an exemplar of token efficiency — a lean, well-organized rule set with explicit applicability guidance and no external references to manage. Its only real weakness is actionability: the rules state what must hold but give no worked examples or concrete application procedure, leaving the agent to interpret how to verify compliance.

Suggestions

Add one short worked example showing a compliant vs. non-compliant sync-behavior change (e.g. a fake toggle vs. a rule-backed control) to make 'UI controls must map to real business rules' concrete.

Add an explicit application step such as 'Review any proposed change against Product Rules 1–5 and Sync Rules before implementing' to serve as a validation checkpoint and lift workflow clarity.

For 'fail loudly rather than dropping data silently', specify what loud failure means in Engram (e.g. surfaced error vs. silent queue drop) so the rule is testable in practice.

DimensionReasoningScore

Conciseness

The body is ~30 lines of terse directives ("Local-first remains the default mental model", "fail loudly rather than dropping data silently") with no padding and no explanation of concepts Claude already knows — every token earns its place.

5 / 5

Actionability

The rules are reasonably concrete as design criteria ("must be enforceable server-side", "must be deterministic and testable"), but there are no concrete examples, commands, or mechanisms for applying them — fitting 'some concrete guidance but incomplete' rather than the mostly-executable anchor at 4.

3 / 5

Workflow Clarity

This is a simple, single-purpose skill under 50 lines with an explicit 'When to Use' section, so the simple-skill exception applies and the single action is mostly unambiguous; it falls short of 5 because there is no rule-application or validation checkpoint (e.g. 'verify the proposed change against each rule before implementing').

4 / 5

Progressive Disclosure

The skill is under 50 lines with no need for external references and no bundle files, and the body is cleanly organized into three well-headed sections (When to Use, Product Rules, Sync Rules), which satisfies the simple-skill criterion for a top score.

5 / 5

Total

17

/

20

Passed

Description

62%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, has an explicit and well-structured trigger clause, and avoids all bad-overall-example failure modes (vague one-liners like 'Helps with documents'). Its weaknesses are an abstract 'what' ('guardrails' says nothing about what the skill actually does) and trigger coverage that omits natural synonyms such as enrollment, auth, and org policy that the body itself uses.

Suggestions

Replace the abstract 'guardrails' with concrete actions the skill performs, e.g. 'Reviews and constrains changes to Engram sync, enrollment, permissions, and project policy against the product rules below'.

Broaden the trigger clause with natural synonyms users would actually say: 'enrollment', 'authentication/auth', 'cloud sync', 'org-level policy', and 'memory visibility'.

State what the skill does with the rules (e.g. 'apply these rules when implementing or reviewing such changes') so the 'what' is as explicit as the 'when'.

DimensionReasoningScore

Specificity

"Product and business-rule guardrails for Engram" names the domain and enumerates four topical areas ("sync behavior, project controls, permissions, or memory semantics"), but "guardrails" is abstract and no concrete actions are listed, matching the anchor 'names domain and 1-2 concrete actions, but not comprehensive' rather than the several-specific-actions anchor at 4.

3 / 5

Completeness

It has both a 'what' ("Product and business-rule guardrails for Engram") and an explicit 'when' ("Trigger: Any change that affects sync behavior, project controls, permissions, or memory semantics"), so it is not capped at 3, but the 'what' is too vague to clearly and fully answer both questions for a 5.

4 / 5

Trigger Term Quality

The trigger clause includes relevant keywords like "sync behavior" and "permissions", but misses natural variations users would say and that the body itself uses ("enrollment", "auth", "cloud", "org policy"), fitting the 'some relevant keywords but missing common variations or synonyms' anchor rather than 4.

3 / 5

Distinctiveness Conflict Risk

"for Engram" carves out a clear niche and the triggers are domain-specific, but "sync behavior" and "permissions" are broad terms that could overlap with other sync- or policy-related skills, matching 'mostly distinct; minor overlap risk' rather than the minimal-conflict anchor at 5.

4 / 5

Total

14

/

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.

Repository

Gentleman-Programming/engram

Path

skills/business-rules/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.