Execute software engineer specializing in creating production-ready ADK agents with best practices, code structure, testing, and deployment automation. Use when asked to "build ADK agent", "create agent code", or "engineer ADK application". Trigger with relevant phrases based on skill purpose.
47
51%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/ai-ml/jeremy-adk-software-engineer/skills/adk-engineer/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 establishes a clear domain (ADK agents) and includes an explicit 'Use when' clause with trigger phrases, which is good for completeness. However, the specific capabilities listed are high-level categories rather than concrete actions, and the final sentence ('Trigger with relevant phrases based on skill purpose') is meaningless filler that wastes space. The description would benefit from more specific action verbs and expanded trigger term coverage.
Suggestions
Replace vague capability categories with concrete actions, e.g., 'Scaffolds ADK agent projects, generates handler code, writes unit tests, configures CI/CD pipelines, and sets up deployment manifests.'
Expand trigger terms to include common user variations like 'ADK project', 'agent development kit', 'deploy agent', 'agent scaffold', 'agent boilerplate'.
Remove the meaningless sentence 'Trigger with relevant phrases based on skill purpose' — it adds no information and wastes description space.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (ADK agents) and mentions some areas like 'code structure, testing, and deployment automation,' but these are high-level categories rather than concrete, specific actions. It doesn't list what specific operations are performed (e.g., 'scaffold project directories', 'generate unit tests', 'create CI/CD pipelines'). | 2 / 3 |
Completeness | It answers both 'what' (creating production-ready ADK agents with best practices, code structure, testing, deployment automation) and 'when' (explicit 'Use when' clause with trigger phrases). Both components are present and explicit, meeting the threshold for a score of 3. | 3 / 3 |
Trigger Term Quality | It includes some useful trigger phrases like 'build ADK agent', 'create agent code', and 'engineer ADK application', but misses common variations users might say such as 'ADK project', 'agent development kit', 'deploy agent', or 'agent testing'. The final sentence 'Trigger with relevant phrases based on skill purpose' is vague filler that adds no value. | 2 / 3 |
Distinctiveness Conflict Risk | The ADK-specific focus provides some distinctiveness, but 'production-ready' code, 'best practices', 'testing', and 'deployment automation' are broad enough to overlap with general software engineering or other agent-building skills. The term 'ADK' helps narrow it but isn't universally understood without expansion. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads as a high-level process guide rather than an actionable engineering skill. It describes what to do at an abstract level but provides zero executable code, specific ADK commands, file templates, or concrete configuration examples. The workflow is logically sequenced but lacks the specificity and validation checkpoints needed for a production engineering skill.
Suggestions
Add concrete, executable code examples: a minimal ADK agent scaffold (e.g., agent entrypoint, tool definition, test file) with actual ADK API calls and CLI commands.
Include specific commands for each workflow step, e.g., `adk create`, `adk run`, `pytest tests/`, with expected outputs so Claude knows what success looks like.
Add a validation feedback loop: after step 4 (implement), show explicit 'run tests → check output → fix → re-run' with concrete test commands rather than just mentioning 'validate locally'.
Remove generic software engineering advice (retries, backoff, structured error responses) that Claude already knows, and replace with ADK-specific patterns, gotchas, or configuration details.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably structured but includes some unnecessary framing ('Use this skill to...', 'Engineer production-ready...') and explains general software engineering practices (retries, backoff, logging, input validation) that Claude already knows. The examples section describes outcomes abstractly rather than providing concrete artifacts. | 2 / 3 |
Actionability | The skill provides no executable code, no concrete commands, no specific file contents, and no copy-paste-ready examples. Instructions are high-level process descriptions ('Scaffold structure', 'Implement incrementally') without any concrete ADK code, CLI commands, or configuration snippets. The examples section describes request/result pairs at an abstract level without showing actual code or commands. | 1 / 3 |
Workflow Clarity | Steps are listed in a logical sequence (clarify → propose → scaffold → implement → guardrails → validate), and there is mention of validation ('Validate locally'). However, there are no explicit validation checkpoints between steps, no feedback loops for error recovery during the build process, and the validation step lacks specific commands or expected outputs. | 2 / 3 |
Progressive Disclosure | The skill references a detailed playbook at `${CLAUDE_SKILL_DIR}/references/SKILL.full.md` and external docs, which is good progressive disclosure structure. However, no bundle files were provided to verify these references exist, and the main content itself could benefit from better separation—the error handling and examples sections contain content that could be more concisely integrated or split out. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
69c73e9
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.