software-engineer
Core software engineering principles for code style, documentation, and development workflow. Applies when editing code, working in software repositories, or performing software development tasks.
Install with Tessl CLI
npx tessl i github:siviter-xyz/dot-agent --skill software-engineer74
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
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 has good structural completeness with explicit 'what' and 'when' clauses, but suffers from being too broad and generic. It describes high-level categories rather than specific capabilities, and its scope is so wide that it would likely conflict with more specialized skills in a large skill library.
Suggestions
Narrow the scope to specific capabilities (e.g., 'Enforces consistent code formatting, naming conventions, and inline documentation standards') rather than broad categories
Add distinctive trigger terms that differentiate this from other coding skills (e.g., 'style guide', 'conventions', 'best practices', 'code review')
Clarify what makes this skill distinct from language-specific or tool-specific skills to reduce conflict risk
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain ('software engineering') and mentions some areas ('code style, documentation, development workflow') but these are categories rather than concrete actions. No specific verbs like 'format', 'lint', 'write docstrings', or 'review pull requests'. | 2 / 3 |
Completeness | Clearly answers both what ('Core software engineering principles for code style, documentation, and development workflow') and when ('Applies when editing code, working in software repositories, or performing software development tasks') with explicit trigger guidance. | 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', 'debug', 'PR', 'git', or specific file types. | 2 / 3 |
Distinctiveness Conflict Risk | Very generic scope that would conflict with many other skills - any coding skill, documentation skill, git skill, or language-specific skill could overlap. 'Software development tasks' is extremely broad. | 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 concise bullet-point format and clear organization with appropriate references. The main weakness is the lack of concrete code examples to illustrate the patterns being described, which would make the guidance more immediately actionable.
Suggestions
Add a brief code example showing self-documenting code vs. over-commented code to illustrate the 'avoid unnecessary comments' principle
Include a concrete example of proper color library usage (e.g., chalk) with NO_COLOR support to make the output formatting section executable
| 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 guidelines but lacks concrete code examples. Instructions like 'use color libraries (chalk, colors, etc.)' are specific but no executable code snippets demonstrate the patterns. | 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 sequencing for multi-step processes or validation checkpoints for the development workflow itself. | 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 workflow-patterns.md and implementation-workflow.md. | 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.
- 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.