senior-engineering
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, delivery, quality gates, and LLM-specific patterns.
67
58%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./prompts/senior-engineering/SKILL.mdQuality
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.
The description does a good job of explicitly stating both what the skill covers and when to use it, with a clear 'Load when' clause. However, the capabilities described are broad and somewhat abstract (e.g., 'planning, delivery, quality gates'), which reduces specificity and increases conflict risk with other development-related skills. The trigger terms could be expanded to include more natural user language.
Suggestions
Add more specific concrete actions — e.g., 'Guides decomposition of complex features into incremental PRs, enforces testing and error-handling standards, applies dependency injection and interface-driven design'
Include more natural trigger terms users would say, such as 'refactor,' 'system design,' 'code architecture,' 'best practices,' 'technical debt,' 'design patterns,' or 'code quality'
Sharpen distinctiveness by clarifying what differentiates this from a general coding skill — e.g., emphasize the senior-engineer methodology, multi-agent orchestration, or LLM-aware development patterns more concretely
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (engineering/software development) and lists some actions like 'architecting systems, reviewing code, orchestrating multi-agent builds,' but these are broad categories rather than multiple specific concrete actions. 'Planning, delivery, quality gates, and LLM-specific patterns' are somewhat abstract. | 2 / 3 |
Completeness | Clearly answers both 'what' (engineering principles for building software, covering planning, delivery, quality gates, LLM-specific patterns) and 'when' ('Load when tackling non-trivial development work, architecting systems, reviewing code, or orchestrating multi-agent builds'). The 'Load when' clause serves as an explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'architecting systems,' 'reviewing code,' 'multi-agent builds,' and 'quality gates,' but misses many natural user phrases like 'refactor,' 'design patterns,' 'code architecture,' 'best practices,' 'clean code,' 'technical debt,' or 'system design.' The term 'non-trivial development work' is vague rather than a natural trigger. | 2 / 3 |
Distinctiveness Conflict Risk | The description is fairly broad — 'engineering principles' and 'non-trivial development work' could overlap with many coding-related skills. However, the mention of 'multi-agent builds,' 'LLM-specific patterns,' and 'quality gates' adds some distinctiveness. It could still conflict with general coding, code review, or architecture skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a well-organized collection of senior engineering principles with good structural flow from planning through execution to quality gates. However, it reads more like a philosophy document than an actionable skill — most guidance is abstract advice rather than concrete, executable instructions. Several sections (Ownership & Accountability, Strong Opinions) contain wisdom Claude already embodies and don't add operational value.
Suggestions
Add concrete examples showing how to apply these principles — e.g., a sample decomposition of a feature request into testable units, or a concrete agent delegation contract with input/output schemas.
Remove or significantly trim the 'Ownership & Accountability' and 'Strong Opinions, Weakly Held' sections, which are interpersonal advice Claude already understands and don't provide actionable engineering guidance.
Add explicit validation/feedback loops to the workflow — e.g., after 'Decompose Before Building', show a concrete checkpoint where the decomposition is verified before proceeding to implementation.
Extract the LLM Orchestration Principles into a referenced file (e.g., LLM_ORCHESTRATION.md) with concrete examples of context budgeting, agent handoff contracts, and checkpoint patterns.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably well-structured and avoids excessive verbosity, but includes several motivational/philosophical statements Claude already knows (e.g., 'No ego-driven attachment to being right', 'I was wrong is a sign of growth') and soft principles that don't add actionable value. Some sections like 'Ownership & Accountability' are life advice rather than engineering guidance. | 2 / 3 |
Actionability | The skill provides structured checklists and heuristics (e.g., the Quality Gates checklist is concrete), but most guidance is directional rather than executable. There are no code examples, no specific commands, no tool invocations, and no concrete examples of applying these principles. Statements like 'Break work into clear, testable units' are advice, not actionable instructions. | 2 / 3 |
Workflow Clarity | There is a clear temporal sequence (Before Writing Code → During Build → Quality Gates) and the Quality Gates section provides an explicit checklist. However, there are no validation checkpoints with feedback loops, no concrete verification steps, and no error recovery guidance. For a skill covering 'multi-agent builds' and 'orchestrating' work, the lack of explicit validation/retry patterns is a gap. | 2 / 3 |
Progressive Disclosure | The content is well-organized with clear section headers and logical grouping, but it's a monolithic document with no references to external files for deeper dives. The LLM Orchestration section and Quality Gates could benefit from linking to more detailed guides. For a skill of this breadth, everything being inline makes it longer than necessary. | 2 / 3 |
Total | 8 / 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.
- Repository
- jdrhyne/agent-skills
- Commit
6768672
- 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.