general-best-practices

General software development best practices covering code quality, testing, security, performance, and maintainability across technology stacks

Quality

11%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./general-best-practices/SKILL.md

Quality

Content

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill is essentially a textbook summary of general software engineering best practices that Claude already knows thoroughly. It provides no concrete code examples, no executable commands, no project-specific guidance, and no novel information. It consumes significant token budget while adding virtually zero actionable value beyond what Claude can generate from its training data.

Suggestions

Either remove this skill entirely (Claude already knows all of this) or narrow it to project-specific conventions and preferences that differ from general best practices, e.g., 'In this project, we use X pattern for error handling' with concrete code examples.

Add executable code examples for each practice area — e.g., show the specific error wrapping pattern, the exact logging format, or the concrete test structure expected in this project.

Convert abstract principles into actionable checklists or workflows with validation steps, e.g., a PR review checklist or a step-by-step process for adding a new feature with specific commands to run.

If this is meant as a reference, split into focused sub-files (testing.md, security.md, etc.) and make SKILL.md a concise overview with links, rather than inlining all content.

Dimension	Reasoning	Score
Conciseness	This is extremely verbose and consists almost entirely of general software engineering advice that Claude already knows. Every section (SOLID principles, error handling, clean architecture, testing best practices, security fundamentals) is common knowledge for an LLM. Nearly every token is wasted restating textbook material with no project-specific or novel information.	1 / 3
Actionability	The entire skill is abstract advice with zero concrete code, commands, or executable examples. Statements like 'Write short, focused functions' and 'Use parameterized queries to prevent SQL injection' are vague directives with no specific implementation guidance, no code snippets, and no copy-paste-ready content.	1 / 3
Workflow Clarity	There are no multi-step workflows, no sequenced processes, and no validation checkpoints. The content is a flat list of general principles organized by topic headers, with no procedural guidance for how to actually apply any of these practices in a concrete workflow.	1 / 3
Progressive Disclosure	The content is organized into logical sections with clear headers, which provides some structure. However, it's a monolithic wall of generic advice that could benefit from being split into focused files, and there are no references to any supporting documents or examples.	2 / 3
	Total	5 / 12 Passed

Description

14%

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 too vague and broad to be effective for skill selection. It reads more like a category label than a skill description, listing abstract topics without concrete actions or explicit trigger conditions. It would likely conflict with many other development-related skills due to its lack of specificity and distinctiveness.

Suggestions

Add a 'Use when...' clause with explicit trigger conditions, e.g., 'Use when the user asks for code review, best practices guidance, or help improving code quality in an existing codebase.'

Replace the abstract category list with specific concrete actions, e.g., 'Reviews code for anti-patterns, suggests refactoring improvements, recommends testing strategies, and identifies security vulnerabilities.'

Narrow the scope to reduce conflict risk—either focus on a specific aspect (e.g., code review vs. security) or clearly delineate what distinguishes this from other development skills.

Dimension	Reasoning	Score
Specificity	The description lists broad categories ('code quality, testing, security, performance, maintainability') but no concrete actions. It doesn't say what the skill actually does—there are no verbs describing specific operations like 'reviews code', 'generates tests', or 'identifies vulnerabilities'.	1 / 3
Completeness	The description loosely addresses 'what' (general software development best practices) but provides no 'when' clause or explicit trigger guidance. The absence of a 'Use when...' clause caps this at 2 per the rubric, and the 'what' is so vague it warrants a 1.	1 / 3
Trigger Term Quality	Terms like 'code quality', 'testing', 'security', 'performance', and 'maintainability' are somewhat relevant keywords users might mention, but they are very broad and missing natural variations users would say (e.g., 'best practices', 'code review', 'refactor', 'clean code', 'unit tests').	2 / 3
Distinctiveness Conflict Risk	This description is extremely generic—'general software development best practices across technology stacks' would conflict with virtually any coding, testing, security, or performance-related skill. It has no clear niche or distinct triggers.	1 / 3
	Total	5 / 12 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 — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository: mindrally/skills
Commit: 05a7130

Reviewed: 14 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.