Access Granola meeting data programmatically for developer workflows. Use when reading notes from the local cache, building MCP integrations, extracting action items into code, or syncing meeting outcomes to dev tools. Trigger: "granola dev workflow", "granola MCP", "granola local cache", "granola developer", "granola programmatic".
59
70%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/granola-pack/skills/granola-local-dev-loop/SKILL.mdQuality
Discovery
75%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 well-structured with clear 'what' and 'when' sections and a distinct niche targeting Granola developer workflows. Its main weaknesses are that the specific actions could be more concrete (e.g., what exactly does 'access programmatically' entail?) and the trigger terms feel artificially constructed rather than matching natural user language.
Suggestions
Replace vague phrases like 'access programmatically' with more concrete actions such as 'parse meeting transcripts', 'read cached JSON notes', or 'export action items to issue trackers'.
Add more natural trigger terms users would actually say, such as 'meeting notes', 'Granola API', 'Granola action items', or 'sync meetings'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (Granola meeting data) and some actions (reading notes, building MCP integrations, extracting action items, syncing meeting outcomes), but the actions are somewhat vague—'access programmatically' and 'syncing meeting outcomes to dev tools' lack concrete specificity about what operations are performed. | 2 / 3 |
Completeness | The description clearly answers both 'what' (access Granola meeting data programmatically for developer workflows) and 'when' (reading notes from local cache, building MCP integrations, extracting action items, syncing to dev tools), with an explicit 'Use when' clause and trigger terms. | 3 / 3 |
Trigger Term Quality | The explicit trigger terms like 'granola MCP', 'granola local cache', 'granola developer' are useful but quite niche and compound. Natural user phrases like 'meeting notes', 'action items', or just 'Granola' are missing, and the listed triggers feel artificially constructed rather than naturally spoken. | 2 / 3 |
Distinctiveness Conflict Risk | The skill is highly distinctive—it targets a specific product (Granola) combined with a specific use case (developer/programmatic workflows). This is unlikely to conflict with other skills due to the narrow niche. | 3 / 3 |
Total | 10 / 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 solid, actionable skill with real executable code and clear structure covering multiple integration methods. Its main weaknesses are the lack of inline validation/confirmation steps before external operations (GitHub issue creation), duplicated cache-reading logic across steps, and some verbosity that could be trimmed. The content would benefit from factoring shared code into a utility and adding explicit checkpoints.
Suggestions
Add a dry-run or confirmation step before creating GitHub issues (e.g., print planned issues and prompt for confirmation) to prevent unintended external side effects.
Factor the cache-reading logic into a single reusable utility referenced by later steps instead of duplicating it in Steps 1, 3, and 4.
Add inline validation after cache parsing (e.g., assert expected keys exist, print a sample document structure) so errors are caught early before downstream steps.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary verbosity — e.g., the Step 4 bash script largely duplicates the cache-reading logic from Step 1, and the MCP section lists capabilities Claude could infer. The git commit example in Step 5 is padding with a hypothetical date and names. However, most code blocks earn their place. | 2 / 3 |
Actionability | The skill provides fully executable Python and bash code for reading the cache, extracting action items, and creating GitHub issues. The MCP config JSON is copy-paste ready. Code is concrete with specific file paths, real library calls, and working patterns. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced and numbered, but there are no validation checkpoints. The cache-reading step doesn't verify the parsed structure is correct before proceeding, and the action-item-to-GitHub pipeline has no dry-run or confirmation step before creating issues (a destructive/external operation). The error handling table at the end is helpful but reactive rather than inline. | 2 / 3 |
Progressive Disclosure | The skill has reasonable section structure and references external resources at the bottom, plus a 'Next Steps' pointer. However, with no bundle files, the inline content is quite long (~150 lines of code), and the cache-reading logic is duplicated rather than factored into a referenced utility. The MCP community server list and error table could be split out to keep the main skill leaner. | 2 / 3 |
Total | 9 / 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 | |
d41e58e
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.