Engineering principles for building software like a senior engineer. Load when tackling non-trivial development work, architecting systems, reviewing code, or orchestrating multi-agent builds. Covers planning, execution, quality gates, and LLM-specific patterns.
Install with Tessl CLI
npx tessl i github:jdrhyne/agent-skills --skill senior-engineering76
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
67%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 has good structure with explicit 'Load when' triggers and covers both what and when effectively. However, the capabilities remain somewhat abstract ('engineering principles', 'quality gates') rather than listing concrete actions, and the trigger terms could conflict with other development-focused skills. The mention of 'LLM-specific patterns' and 'multi-agent builds' provides some unique differentiation.
Suggestions
Add more concrete actions like 'designs system architecture diagrams', 'implements design patterns', 'establishes testing strategies' to improve specificity
Include additional natural trigger terms users might say: 'best practices', 'code structure', 'technical debt', 'scalability', 'maintainability'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names domain (engineering/software development) and some actions (planning, execution, quality gates, architecting, reviewing code), but actions remain somewhat abstract rather than concrete specific operations. | 2 / 3 |
Completeness | Clearly answers both what ('Engineering principles for building software') and when ('Load when tackling non-trivial development work, architecting systems, reviewing code, or orchestrating multi-agent builds') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'architecting systems', 'reviewing code', 'multi-agent builds', but missing common natural variations users might say like 'design patterns', 'refactoring', 'best practices', 'code quality'. | 2 / 3 |
Distinctiveness Conflict Risk | The 'senior engineer' framing and 'LLM-specific patterns' provide some distinction, but 'reviewing code' and 'development work' could overlap with many coding-related skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
77%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-crafted principles document that excels at conciseness and workflow structure. It provides clear mental models and checklists for senior engineering practices. The main weakness is the lack of concrete, executable examples - it tells you what to do but not how to do it with specific code or commands.
Suggestions
Add 1-2 concrete code examples demonstrating key principles (e.g., 'Interface First' with a before/after showing type definitions before implementation)
Consider splitting LLM Orchestration Principles into a separate ORCHESTRATION.md file with more detailed agent delegation patterns and examples
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely lean and efficient. Every bullet point earns its place with no unnecessary explanation of concepts Claude already knows. The format uses terse, actionable statements without padding. | 3 / 3 |
Actionability | Provides clear principles and checklists but lacks concrete code examples or executable commands. The guidance is specific but remains at the conceptual level rather than copy-paste ready implementation. | 2 / 3 |
Workflow Clarity | Clear sequencing through 'Before Writing Code' → 'During Build' → 'Quality Gates' phases. The Quality Gates section provides an explicit checklist with validation steps. The incremental approach with checkpoints addresses error recovery. | 3 / 3 |
Progressive Disclosure | Well-organized with clear section headers and logical grouping, but this is a monolithic document with no references to external files for deeper dives. For a principles document of this scope, some content (like LLM Orchestration) could be split out. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
68%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 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
description_trigger_hint | Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...') | Warning |
metadata_version | 'metadata' field is not a dictionary | Warning |
license_field | 'license' field is missing | Warning |
body_examples | No examples detected (no code fences and no 'Example' wording) | Warning |
body_steps | No step-by-step structure detected (no ordered list); consider adding a simple workflow | Warning |
Total | 11 / 16 Passed | |
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.