Bence's code style, tech stack, and workflow conventions
48
36%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./bencium-code-conventions/skills/bencium-code-conventions/SKILL.mdQuality
Discovery
7%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description is extremely vague and fails to communicate what the skill actually does or when it should be used. It reads more like a title than a description, providing no concrete actions, no explicit triggers, and no guidance for skill selection. The personal name adds minimal distinctiveness but does not compensate for the lack of substance.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Applies Bence's preferred formatting rules, linting configuration, and naming conventions when writing or reviewing code.'
Add an explicit 'Use when...' clause with trigger conditions, e.g., 'Use when writing code for Bence's projects, when asked about coding standards, or when reviewing pull requests in Bence's repositories.'
Include specific technologies or languages from the tech stack (e.g., 'TypeScript, React, Node.js') to improve trigger term quality and distinctiveness.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague, abstract language ('code style', 'tech stack', 'workflow conventions') without listing any concrete actions or specific capabilities. It does not describe what the skill actually does. | 1 / 3 |
Completeness | The description weakly addresses 'what' (something about code style and conventions) but provides no 'when' clause or explicit trigger guidance. Both dimensions are very weak. | 1 / 3 |
Trigger Term Quality | The terms 'code style', 'tech stack', and 'workflow conventions' are generic and not natural keywords a user would say when requesting help. The personal name 'Bence' is highly specific but not a useful trigger term for capability matching. | 1 / 3 |
Distinctiveness Conflict Risk | The personal name 'Bence' provides some distinctiveness, but 'code style' and 'workflow conventions' are generic enough to overlap with any coding standards or style guide skill. It's somewhat distinguishable due to the personal name but not clearly scoped. | 2 / 3 |
Total | 5 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid personal conventions skill that is concise and well-organized, covering tech stack, code style, workflow, and deployment preferences efficiently. Its main weaknesses are the lack of concrete code examples illustrating the conventions and the absence of explicit validation/feedback loops in the workflow. Adding a few executable examples and linking to supplementary files for detailed patterns would elevate it significantly.
Suggestions
Add 1-2 concrete code examples showing preferred component structure, Zod validation, or Zustand store patterns to improve actionability.
Include explicit validation checkpoints in the development workflow, e.g., 'Run `npx tsc --noEmit` after changes; if errors, fix before committing' to strengthen workflow clarity.
Consider linking to supplementary files for detailed topics like Supabase/Convex setup patterns or TDD examples (e.g., 'See [TDD_EXAMPLES.md](TDD_EXAMPLES.md) for sample test-first workflow').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and well-organized with bullet points. It avoids explaining what React, TypeScript, or TailwindCSS are, and instead states preferences directly. Every line conveys a specific convention or constraint. | 3 / 3 |
Actionability | The skill provides specific, concrete conventions (e.g., 'const toggle = () =>', naming patterns like 'isLoading', 'hasError', directory naming with dashes) but lacks executable code examples for key patterns like component structure, Zod validation setup, or a sample commit workflow. It's more of a reference list than copy-paste-ready guidance. | 2 / 3 |
Workflow Clarity | The development workflow section provides a clear high-level sequence (Explore → Plan → Code → Commit) and TDD guidance mentions ordering (write failing tests first, then iterate). However, there are no explicit validation checkpoints or feedback loops—e.g., what to do if typecheck fails, or how to verify deployment readiness before pushing. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear section headers and logical grouping, making it easy to scan. However, some sections (like Quality Assurance and Component Library) could benefit from linking to separate detailed files for examples or extended guidance, and there are no external references at all. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
20077d3
Table of Contents
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.