cerebro-source-integration
Scaffold Cerebro source integrations following existing source, preview, runtime, and test patterns.
67
52%
Does it follow best practices?
Impact
95%
1.21xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.factory/skills/cerebro-source-integration/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, narrow domain (Cerebro source integrations) which gives it good distinctiveness, but it lacks explicit trigger guidance ('Use when...') and doesn't enumerate specific concrete actions beyond scaffolding. The trigger terms are project-specific jargon that may not match how users naturally phrase requests.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to create a new Cerebro source integration, add a data source connector, or scaffold integration boilerplate.'
Include natural trigger term variations users might say, such as 'new integration', 'add source', 'create connector', 'boilerplate', or 'integration template'.
List more specific concrete actions, e.g., 'Generates source configuration files, creates preview components, sets up runtime handlers, and scaffolds test suites for Cerebro integrations.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names a domain ('Cerebro source integrations') and mentions some structural elements ('source, preview, runtime, and test patterns'), but doesn't list specific concrete actions beyond 'scaffold'. It's more of a single action with context rather than multiple specific capabilities. | 2 / 3 |
Completeness | It describes what ('scaffold Cerebro source integrations following existing patterns') but has no explicit 'Use when...' clause or equivalent trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' itself is also somewhat thin, so this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant terms like 'Cerebro', 'source integrations', 'scaffold', and 'patterns', but these are fairly project-specific jargon. Missing common variations a user might say like 'new integration', 'add source', 'create connector', or 'boilerplate'. | 2 / 3 |
Distinctiveness Conflict Risk | The description is highly specific to 'Cerebro source integrations' which is a clear niche. It's unlikely to conflict with other skills due to the project-specific terminology and narrow scope. | 3 / 3 |
Total | 8 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a concise, well-structured skill that efficiently communicates the high-level workflow for scaffolding Cerebro source integrations. Its main weakness is a lack of concrete, actionable examples—no sample code, no specific file references, no example config validation patterns—which limits its utility for guiding Claude through the actual implementation. The security constraints in step 4 are valuable but would benefit from concrete patterns or references to existing implementations.
Suggestions
Add a concrete example showing the structure of an existing source integration (e.g., a specific file path like `sources/example_source/` and a brief code snippet of its config parsing pattern) to improve actionability.
Include an explicit validation checkpoint between implementation steps, such as 'Run `go test ./sources/new_source/...` after config parsing before implementing preview behavior' to strengthen the workflow.
Reference at least one specific existing integration by name/path (e.g., 'Use `sources/github/` as the closest template for HTTP-based integrations') to make step 1 immediately actionable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line carries weight. No unnecessary explanations of what Cerebro is, what integrations are, or how testing works. Assumes Claude understands the codebase patterns and can follow terse instructions. | 3 / 3 |
Actionability | The steps are directional but lack concrete examples—no specific file paths, no code snippets showing config parsing patterns, no example test structure. Instructions like 'Protect network-facing settings against loopback' are specific in intent but vague in execution without showing how existing integrations do it. | 2 / 3 |
Workflow Clarity | Steps are sequenced logically (copy existing → implement → validate → test → verify), and there's a final verification step with `make verify`. However, there are no explicit validation checkpoints between steps (e.g., validate config parsing before moving to preview behavior) and no feedback loop for handling test failures. | 2 / 3 |
Progressive Disclosure | The skill is short and well-organized with clear sections, but it references 'sources/' and existing integrations without pointing to any specific example files or companion documentation. With no bundle files provided, there's a missed opportunity to reference concrete examples that would aid navigation. | 2 / 3 |
Total | 9 / 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
- writer/cerebro
- Commit
3aeaf20
- 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.