Core software engineering principles for code style, documentation, and development workflow. Applies when editing code, working in software repositories, or performing software development tasks.
73
66%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/software-engineer/SKILL.mdQuality
Discovery
59%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 provides a reasonable structure with both 'what' and 'when' clauses, but suffers from being too broad and abstract. It describes principles rather than concrete actions, and its wide scope ('software engineering') creates high conflict risk with more specialized skills. The trigger terms are adequate but not comprehensive.
Suggestions
Narrow the scope or clarify what makes this skill distinct from language-specific or tool-specific coding skills (e.g., 'Establishes baseline conventions when no language-specific skill applies')
Add concrete actions instead of abstract 'principles' (e.g., 'Enforces consistent naming conventions, adds inline comments, structures functions for readability')
Include more natural trigger terms users would say: 'coding standards', 'best practices', 'clean code', 'refactoring', 'code review'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain ('software engineering') and mentions general areas ('code style, documentation, development workflow') but lacks concrete actions. No specific verbs like 'format', 'lint', 'write docstrings', or 'review pull requests'. | 2 / 3 |
Completeness | Answers both 'what' (core software engineering principles for code style, documentation, workflow) and 'when' with explicit triggers ('Applies when editing code, working in software repositories, or performing software development tasks'). | 3 / 3 |
Trigger Term Quality | Includes some relevant terms ('code', 'software repositories', 'software development') but misses common variations users would say like 'coding', 'programming', 'refactor', 'PR', 'git', 'functions', or specific file types. | 2 / 3 |
Distinctiveness Conflict Risk | Very broad scope ('software engineering principles') would likely conflict with many other skills - any coding skill, documentation skill, or workflow skill could overlap. Not clearly distinguished from language-specific or tool-specific skills. | 1 / 3 |
Total | 8 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured principles document that efficiently communicates coding standards and workflow expectations. Its strengths are conciseness and clear organization with appropriate references. The main weakness is the lack of concrete, executable examples - the guidance is directive but abstract, which limits immediate actionability for specific implementation scenarios.
Suggestions
Add a concrete code example demonstrating self-documenting code vs. over-commented code to illustrate the commenting principles
Include a specific example of the 'Stop and ask' workflow showing a decision tree or scenario walkthrough
Add executable examples for output formatting showing proper color library usage vs. hardcoded ANSI codes
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient, using bullet points with brief explanations. It assumes Claude's competence and doesn't explain basic concepts like what comments are or how Git works. | 3 / 3 |
Actionability | Provides clear directives and specific guidance (e.g., what to look for in workflow detection, when to stop and ask), but lacks concrete code examples or executable commands. The guidance is specific but descriptive rather than demonstrative. | 2 / 3 |
Workflow Clarity | The 'Stop and ask' section provides clear decision points, and workflow detection has specific items to check. However, there's no explicit sequenced workflow with validation checkpoints for multi-step development tasks. | 2 / 3 |
Progressive Disclosure | Well-organized with clear headings and scannable structure. References to detailed guidance files are clearly signaled at the end with one-level-deep links to specific topics. | 3 / 3 |
Total | 10 / 12 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 — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
3376255
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.