adobe-acrobat-sign
Adobe Acrobat Sign integration. Manage Users, Agreements, Widgets. Use when the user wants to interact with Adobe Acrobat Sign data.
60
70%
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 ./skills/adobe-acrobat-sign/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 adequately identifies the product domain and provides an explicit 'Use when' clause, which is good for completeness. However, the capabilities listed are high-level entity types rather than specific actions, and the trigger terms miss common natural language phrases users might use when needing e-signature functionality. The strong product specificity helps with distinctiveness but the description could be more actionable.
Suggestions
Replace generic 'Manage' with specific actions like 'Create, send, and track signature agreements; manage signing widgets; add and configure users in Adobe Acrobat Sign.'
Add natural trigger terms users would say, such as 'e-signature', 'digital signature', 'send for signing', 'signature request', or 'signing workflow'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Adobe Acrobat Sign) and some actions ('Manage Users, Agreements, Widgets'), but the actions are high-level categories rather than specific concrete operations like 'create agreements', 'send for signature', 'check signing status'. | 2 / 3 |
Completeness | Answers both 'what' (manage Users, Agreements, Widgets in Adobe Acrobat Sign) and 'when' ('Use when the user wants to interact with Adobe Acrobat Sign data'), with an explicit trigger clause. | 3 / 3 |
Trigger Term Quality | Includes 'Adobe Acrobat Sign', 'Users', 'Agreements', 'Widgets' which are relevant but misses natural user terms like 'e-signature', 'digital signature', 'sign document', 'send for signing', or 'DocuSign alternative'. | 2 / 3 |
Distinctiveness Conflict Risk | Adobe Acrobat Sign is a very specific product, making this clearly distinguishable from other skills. The mention of the specific product name creates a clear niche unlikely to conflict with other skills. | 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 skill provides solid, actionable CLI commands for integrating with Adobe Acrobat Sign via Membrane, with good coverage of authentication, connection management, and action execution. Its main weaknesses are unnecessary introductory explanation, a broken workflow reference ('Step 2' is never defined), and an actions table with empty descriptions that adds bulk without value.
Suggestions
Remove the introductory paragraph explaining what Adobe Acrobat Sign is — Claude already knows this. Start directly with the overview or working instructions.
Fix the workflow gap: 'Step 2' is referenced after connection setup but never defined. Either add the missing step or renumber/restructure the flow.
Either populate the Description column in the Popular Actions table or remove the column entirely to avoid empty cells that waste tokens.
Add a brief validation/verification step after running actions (e.g., check the output field for errors) to improve workflow robustness.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The opening paragraph explaining what Adobe Acrobat Sign is wastes tokens on information Claude already knows. The popular actions table has empty description columns, adding visual bulk without value. The Membrane CLI setup and auth flow sections are reasonably efficient but could be tighter. | 2 / 3 |
Actionability | The skill provides concrete, copy-paste-ready CLI commands for every step: installation, authentication, connection setup, action discovery, action execution, and proxy requests. Flag tables and JSON parameter examples make it fully executable. | 3 / 3 |
Workflow Clarity | The connection setup workflow is well-sequenced with state handling (READY, BUILDING, CLIENT_ACTION_REQUIRED, errors), but there are no explicit validation checkpoints after running actions or proxy requests. The 'Step 2' referenced after connection setup is never defined, creating a gap in the workflow. | 2 / 3 |
Progressive Disclosure | The content is a single monolithic file with no references to supporting documents. The popular actions table, proxy request details, and best practices could be split into separate files. However, for a skill of this size (~150 lines), the section structure is reasonable, though the empty description columns in the actions table suggest missing content that should either be filled or linked. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- membranedev/application-skills
- Commit
f484c82
- 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.