Enterprise role-based access control for Apollo.io. Use when implementing team permissions, restricting data access, or setting up enterprise security controls. Trigger with phrases like "apollo rbac", "apollo permissions", "apollo roles", "apollo team access", "apollo enterprise security".
77
73%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/apollo-pack/skills/apollo-enterprise-rbac/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid skill description that clearly identifies its niche (Apollo.io RBAC), provides explicit trigger terms, and answers both what and when. The main weakness is that the specific capabilities could be more concrete—listing actual actions like creating roles, assigning permissions, or configuring access policies rather than higher-level descriptions.
Suggestions
Add more concrete actions to improve specificity, e.g., 'Creates custom roles, assigns granular permissions, configures data visibility rules, manages team hierarchies' instead of the current general phrases.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Apollo.io RBAC) and mentions some actions like 'implementing team permissions', 'restricting data access', and 'setting up enterprise security controls', but these are somewhat general and don't list concrete specific actions (e.g., creating roles, assigning permissions to specific resources, configuring SSO). | 2 / 3 |
Completeness | Clearly answers both 'what' (enterprise role-based access control for Apollo.io) and 'when' (implementing team permissions, restricting data access, setting up enterprise security controls) with explicit trigger phrases provided. | 3 / 3 |
Trigger Term Quality | Explicitly lists natural trigger phrases like 'apollo rbac', 'apollo permissions', 'apollo roles', 'apollo team access', 'apollo enterprise security'. These cover good variations of terms a user would naturally say when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive due to the specific combination of Apollo.io platform and RBAC/enterprise security domain. The trigger terms are all prefixed with 'apollo' making conflicts with other skills very unlikely. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides highly actionable, executable TypeScript code for implementing Apollo RBAC, which is its primary strength. However, it suffers from being a monolithic document with all implementation details inline rather than using progressive disclosure to separate concerns into referenced files. The workflow lacks validation checkpoints, which is a notable gap for a security-focused skill.
Suggestions
Split the inline code into separate referenced files (e.g., ROLES.md, MIDDLEWARE.md, PROXY.md) and keep SKILL.md as a concise overview with architecture diagram and quick-start guidance.
Add explicit validation/testing steps after each implementation step, e.g., 'Test: send a request as viewer to /apollo/people/match and verify 403 response'.
Remove comments that explain obvious concepts (e.g., '// In production: store in database') to improve token efficiency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly long with extensive inline code that could be split into referenced files. The permission matrix is fully spelled out for all 5 roles which is verbose but arguably necessary for clarity. Some comments explain things Claude would know (e.g., 'In production: store in database'). | 2 / 3 |
Actionability | All code is fully executable TypeScript with proper imports, types, and Express middleware patterns. The five steps provide copy-paste ready implementations covering roles, key management, middleware, proxy, and admin endpoints. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced (1-5) and logically build on each other, but there are no explicit validation checkpoints or verification steps. For a system implementing security controls, there should be testing/validation steps (e.g., 'verify a viewer cannot access enrichment endpoints') to confirm correct RBAC behavior. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of code — approximately 200+ lines of inline TypeScript that would be better split into referenced files. The skill would benefit greatly from a concise overview with links to separate files for each component (roles.ts, middleware.ts, proxy.ts, admin.ts). | 1 / 3 |
Total | 8 / 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 | |
4dee593
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.