Decision-Linked Development (DLD) — a workflow for recording, linking, and maintaining development decisions alongside code. Skills for planning, recording, implementing, auditing, and documenting decisions via @decision annotations.
68
Quality
68%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
dld-decide
skills/dld-decide/SKILL.md
Discovery
42%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 effectively communicates specific capabilities (recording decisions as markdown with YAML frontmatter, collecting context/rationale interactively) but critically lacks any 'Use when...' guidance to help Claude know when to select this skill. The trigger terms are adequate but could include more natural variations like 'ADR' or 'architecture decision'.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when the user wants to document a technical decision, create an ADR, or record why a particular approach was chosen'
Include common trigger term variations: 'ADR', 'architecture decision record', 'document decision', 'record why we chose'
Specify the output format more clearly to distinguish from general documentation skills (e.g., 'Creates ADR-style decision records')
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple concrete actions: 'Record a single development decision', 'markdown file with YAML frontmatter', 'Collects context, rationale, and code references interactively'. These are specific, actionable capabilities. | 3 / 3 |
Completeness | Describes what the skill does but completely lacks a 'Use when...' clause or any explicit trigger guidance. Per rubric guidelines, missing explicit trigger guidance should cap completeness at 2, and this has no trigger guidance at all. | 1 / 3 |
Trigger Term Quality | Contains some relevant terms like 'development decision', 'markdown', 'YAML frontmatter', 'rationale', but misses common variations users might say like 'ADR', 'architecture decision record', 'document decision', or 'why did we choose'. | 2 / 3 |
Distinctiveness Conflict Risk | Somewhat specific to development decisions and markdown files, but 'development decision' and 'markdown file' could overlap with documentation or note-taking skills. The YAML frontmatter detail helps distinguish it somewhat. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
100%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a high-quality skill that demonstrates excellent structure and actionability. It provides a clear conversational workflow with concrete commands, handles edge cases (namespaced vs flat projects, superseded decisions), and includes helpful interaction guidance. The note about printf escape sequences shows attention to practical implementation details.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is lean and efficient, providing only necessary information. It assumes Claude's competence with bash, markdown, and YAML without explaining basic concepts. Every section serves a clear purpose. | 3 / 3 |
Actionability | Provides fully executable bash commands with concrete examples, specific flag usage, and copy-paste ready scripts. The printf piping pattern and escape sequence guidance are particularly actionable. | 3 / 3 |
Workflow Clarity | Clear 8-step sequence with explicit checkpoints (prerequisites check, ID assignment, file creation, index regeneration). Includes conditional logic for namespaced projects and superseded decisions with proper status updates. | 3 / 3 |
Progressive Disclosure | Well-organized with clear sections. References external scripts appropriately without deep nesting. The skill is self-contained at ~100 lines while pointing to shared scripts for reusable functionality. | 3 / 3 |
Total | 12 / 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.