Expert in D-Bus IPC (Inter-Process Communication) on Linux systems. Specializes in secure service communication, method calls, signal handling, and system integration. HIGH-RISK skill due to system service access and privileged operations.
67
58%
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/dbus/SKILL.mdQuality
Discovery
40%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 identifies a clear technical niche (D-Bus IPC on Linux) which provides good distinctiveness, but suffers from missing explicit trigger guidance and somewhat abstract capability descriptions. The 'HIGH-RISK' warning is useful context but doesn't help with skill selection. Adding concrete use cases and a 'Use when...' clause would significantly improve this description.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when the user needs to communicate between Linux services, query system state via D-Bus, or debug IPC issues'
Include more natural trigger terms users might say: 'dbus', 'system bus', 'session bus', 'gdbus', 'qdbus', 'busctl'
Replace abstract terms like 'system integration' with concrete actions like 'query systemd services', 'send notifications', 'monitor hardware events'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (D-Bus IPC) and mentions some actions like 'method calls, signal handling, and system integration', but these are somewhat abstract rather than concrete user-facing actions like 'send messages between services' or 'monitor system events'. | 2 / 3 |
Completeness | Describes what the skill does (D-Bus expertise) but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. The rubric caps completeness at 2 for missing this, and the 'what' portion is also weak. | 1 / 3 |
Trigger Term Quality | Includes relevant technical terms like 'D-Bus', 'IPC', 'Inter-Process Communication', 'Linux', 'method calls', 'signal handling', but misses common user variations like 'dbus', 'system bus', 'session bus', 'gdbus', or specific use cases users might mention. | 2 / 3 |
Distinctiveness Conflict Risk | D-Bus IPC is a very specific niche within Linux systems programming. The combination of 'D-Bus', 'IPC', and 'Linux systems' creates clear distinctiveness that is unlikely to conflict with other skills. | 3 / 3 |
Total | 8 / 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 skill provides comprehensive, actionable D-Bus guidance with strong security focus and executable code examples. The TDD workflow and pre-deployment checklist demonstrate good workflow clarity. However, the content suffers from significant redundancy (security principles repeated 5+ times) and could benefit from splitting into multiple files for better progressive disclosure.
Suggestions
Remove redundant security reminders - consolidate into a single authoritative section rather than repeating in sections 2, 3, 5, 8, and 14
Move the detailed implementation patterns (sections 6-7) to a separate PATTERNS.md file, keeping only a brief overview with links in the main skill
Remove the overview explanations of D-Bus concepts (section 1, 4.1) - Claude already knows what D-Bus is and how message buses work
Fix the truncated code in Pattern 1 (SecureDBusClient._validate_bus_name method is cut off mid-regex)
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains significant redundancy - security principles are repeated across sections 2, 3, 5, 8, and 14. The overview section explains concepts Claude already knows (what D-Bus is, bus types). However, the code examples are reasonably efficient. | 2 / 3 |
Actionability | Provides fully executable Python code with complete implementations including SecureDBusClient, SignalMonitor, PropertyAccess, and ServiceDiscovery classes. Test examples are copy-paste ready with proper mocking patterns. | 3 / 3 |
Workflow Clarity | Section 5 provides a clear TDD workflow with explicit steps: write failing test, implement minimum, refactor, verify. Includes validation commands (pytest, mypy, coverage) and the pre-deployment checklist provides explicit verification checkpoints. | 3 / 3 |
Progressive Disclosure | References to external files exist (references/security-examples.md, etc.) but the main document is monolithic at ~400 lines. Performance patterns, implementation patterns, and security standards could be split into separate files. The structure is present but content is not appropriately distributed. | 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 |
|---|---|---|
skill_md_line_count | SKILL.md is long (701 lines); consider splitting into references/ and linking | Warning |
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 |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 11 / 16 Passed | |
1086ef2
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.