vanity-engineering-review
Reviews codebases, architectures, PRs, and technical plans for vanity engineering — code and systems built for the developer's ego, resume, or intellectual pleasure rather than delivering user or business value. Triggers on: "review this code", "is this over-engineered", "code review", "architecture review", "complexity audit", "vanity check", "is this necessary", "simplify this", "tech debt review", or any request to evaluate whether code or architecture is justified by actual requirements. Also trigger when the user shares a codebase and asks for feedback, when discussing framework/library choices, when reviewing PRs, or when someone is debating whether to refactor or rebuild. Nudge activation when you detect patterns of unnecessary abstraction, premature optimization, or resume-driven technology choices in code the user shares — even if they haven't asked for a vanity review.
69
84%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
92%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 is a strong description with excellent specificity and completeness, clearly defining both the unique 'vanity engineering' evaluation lens and comprehensive trigger conditions. The main weakness is that many of its trigger terms ('code review', 'simplify this', 'review this code') are very generic and would likely conflict with general-purpose code review skills, diluting its distinctiveness. The proactive nudge activation guidance is a nice touch but could exacerbate conflict risk.
Suggestions
Narrow the generic trigger terms to reduce conflict with general code review skills — consider prefixing or qualifying them, e.g., 'Prefer this skill over general code review when the user questions whether complexity is justified or mentions over-engineering.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: reviews codebases, architectures, PRs, and technical plans. Clearly defines the specific lens of evaluation — vanity engineering, unnecessary abstraction, premature optimization, resume-driven technology choices. | 3 / 3 |
Completeness | Clearly answers both 'what' (reviews code/architecture for vanity engineering and unjustified complexity) and 'when' (explicit trigger phrases, contextual triggers like PR reviews and framework debates, and even proactive nudge activation conditions). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'review this code', 'is this over-engineered', 'code review', 'architecture review', 'complexity audit', 'simplify this', 'tech debt review', 'is this necessary'. Also covers contextual triggers like sharing a codebase for feedback or debating refactor vs rebuild. | 3 / 3 |
Distinctiveness Conflict Risk | While the 'vanity engineering' angle is distinctive, many trigger terms like 'code review', 'architecture review', 'simplify this', and 'review this code' are extremely generic and would likely conflict with general code review skills. The overlap risk with standard code review or refactoring skills is significant. | 2 / 3 |
Total | 11 / 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 strong, highly actionable skill with an excellent structured workflow and clear output format. Its main weaknesses are moderate verbosity (philosophical framing and human psychology explanations that Claude doesn't need) and missing bundle files that the skill explicitly references. The diagnostic lenses and severity scale are particularly well-designed for practical application.
Suggestions
Trim the 'Kill Criteria Philosophy' paragraph and 'Core Premise' section — Claude doesn't need explanations of sunk cost fallacy or addition bias to execute the review process.
Provide the referenced bundle files (references/detection-patterns.md and references/kill-criteria-template.md) or inline their essential content, since the skill explicitly depends on them in Phases 2 and 4.
Move the detailed kill criteria tier examples into the referenced kill-criteria-template.md to reduce the main skill's length and improve progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is well-written but includes philosophical exposition that Claude doesn't need (e.g., 'Kill Criteria Philosophy' paragraph about sunk cost bias, addition bias, effort justification). The 'Core Premise' section and 'Kill Criteria Philosophy' section explain human psychology concepts Claude already knows. The diagnostic lenses are efficient, but the overall document could be tightened by ~30%. | 2 / 3 |
Actionability | The skill provides a concrete, structured review process with specific phases, a clear output template with exact sections to produce, a severity scale (V0-V3), seven named diagnostic lenses with specific questions, and detailed kill criteria with concrete examples (e.g., 'zero usage for 30 days', 'CVSS >= 7.0'). The output format is copy-paste ready and the process is fully executable. | 3 / 3 |
Workflow Clarity | The four-phase process (Establish Requirement Anchor → Detection Scan → Vanity Score → Kill Criteria Generation) is clearly sequenced with explicit dependencies (Phase 1 must precede Phase 2 to distinguish necessary from vanity complexity). Each phase has clear inputs, outputs, and validation checkpoints. The kill criteria tiers provide built-in feedback loops with escalation levels. | 3 / 3 |
Progressive Disclosure | The skill references 'references/detection-patterns.md' and 'references/kill-criteria-template.md' which are well-signaled one-level-deep references — good structure. However, no bundle files are provided, meaning these references are broken. Additionally, the kill criteria philosophy and detailed tier examples are inlined when they could be in the referenced template file, making the main skill longer than necessary. | 2 / 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.
- Repository
- bencium/bencium-marketplace
- Commit
2e2fa33
- 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.