Name: earllm-build
Rating: 52 (1 reviews)
Author: administrakt0r

earllm-build

Build, maintain, and extend the EarLLM One Android project — a Kotlin/Compose app that connects Bluetooth earbuds to an LLM via voice pipeline.

Quality

57%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/AI-Agents-Safe-Coding-Skills/skills/earllm-build/SKILL.md

The canonical home for this skill is earllm-build in administrakt0r/AI-Agents-Safe-Coding-Skills

Quality

Content

57%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is rich with project-specific, actionable technical detail and clear structure, but it is held back by generic boilerplate sections, missing validation checkpoints in its workflows, and inlined reference material that should be split into bundle files.

Suggestions

Remove or replace the generic 'Best Practices' and 'Common Pitfalls' sections with project-specific guidance to tighten conciseness.

Add explicit validation checkpoints to 'Adding A New Feature' and 'Generating A Build Artifact' (e.g., run `./gradlew test` and verify the ZIP contents before proceeding) so workflow clarity can exceed 3.

Move the STT engine reference table and Phase 2 roadmap into separate files under `references/` and link to them from the body to improve progressive disclosure.

Dimension	Reasoning	Score
Conciseness	The core technical content (module graph, critical facts, data flow) is lean and high-value, but the trailing 'Best Practices' and 'Common Pitfalls' sections are generic boilerplate that add no project-specific value, fitting 'mostly efficient but includes some unnecessary explanation'.	3 / 5
Actionability	It provides concrete file names, executable commands (`./gradlew test --stacktrace`, the PowerShell zip command), a data-flow trace, and per-module key-file lists, with only minor gaps versus copy-paste-ready completeness.	4 / 5
Workflow Clarity	The 'Adding A New Feature' steps and build-artifact regeneration give a sequence, but neither includes validation/verification checkpoints, and the zip regeneration is a batch/destructive operation without validation, capping workflow clarity at 3 per the rubric.	3 / 5
Progressive Disclosure	The body is well-organized with clear headers but has no bundle files at all, while sizeable reference material (STT engine comparison table, Phase 2 roadmap, critical technical facts) is inlined that could live in separate reference files, matching 'some structure but content that should be separate is inline'.	3 / 5
	Total	13 / 20 Passed

Description

57%Weight 40%Scale 1-5

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 is specific and clearly distinct but incomplete: it states what the skill does with a concrete technical domain yet lacks an explicit 'Use when...' trigger clause, capping completeness. Trigger-term coverage is decent but misses the project's own name variations.

Suggestions

Append an explicit 'Use when...' clause naming trigger phrases such as earllm, earbud app, voice pipeline kotlin, and bluetooth audio android so completeness can reach 4-5.

Swap the generic verbs 'Build, maintain, and extend' for more concrete operations (e.g., 'wire up Bluetooth SCO/BLE audio capture, integrate STT/TTS, and connect an OpenAI-compatible LLM client') to raise specificity.

Include the project name synonyms ('earllm', 'earbudllm') directly in the description to improve trigger-term quality.

Dimension	Reasoning	Score
Specificity	The description names a concrete domain ("Kotlin/Compose app that connects Bluetooth earbuds to an LLM via voice pipeline") and three actions ("Build, maintain, and extend"), but the verbs are generic lifecycle terms rather than the distinct, concrete operations the anchor-4 example requires, so it sits at 'names domain and 1-2 concrete actions'.	3 / 5
Completeness	It gives a clear 'what' but no 'Use when...' clause or explicit trigger guidance, and the rubric caps completeness at 3 when such guidance is missing.	3 / 5
Trigger Term Quality	It surfaces relevant natural keywords ("Bluetooth earbuds", "LLM", "voice pipeline", "Kotlin/Compose", "Android") but omits the project's own common variations ("earllm", "earbud app", "sco microphone") that appear only in the body, fitting 'some relevant keywords but missing common variations'.	3 / 5
Distinctiveness Conflict Risk	The niche is extremely specific (the named EarLLM One project with Bluetooth-earbud-to-LLM voice pipeline), giving it distinct triggers and minimal overlap with other skills.	5 / 5
	Total	14 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: administrakt0r/AI-Agents-Safe-Coding-Skills
Path: plugins/AI-Agents-Safe-Coding-Skills/skills/earllm-build/SKILL.md
Commit: 57c135b

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.