manage-portal-applications
Manage the applications that hold API credentials inside an API Experience Hub portal. Use when a portal consumer needs to list their applications, check if a name is available, create a new application, update metadata, rotate the client secret, or delete an application they no longer use.
68
82%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Risky
Do not use without reviewing
Quality
Discovery
100%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 strong skill description that clearly defines its scope (managing applications within an API Experience Hub portal), lists six specific actions, and includes an explicit 'Use when' clause with natural trigger scenarios. The description is concise, uses third-person voice, and occupies a distinct niche that minimizes conflict risk with other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: list applications, check name availability, create a new application, update metadata, rotate the client secret, and delete an application. These are all clearly defined operations. | 3 / 3 |
Completeness | Clearly answers both 'what' (manage applications holding API credentials in an API Experience Hub portal) and 'when' (explicit 'Use when' clause listing six specific trigger scenarios like listing apps, checking name availability, creating, updating, rotating secrets, or deleting). | 3 / 3 |
Trigger Term Quality | Includes natural keywords a user would say: 'applications', 'API credentials', 'API Experience Hub', 'portal', 'client secret', 'rotate', 'create', 'delete', 'name is available'. These cover the domain well and match how a portal consumer would phrase requests. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: API Experience Hub portal application management. The combination of 'API Experience Hub', 'portal consumer', 'client secret rotation', and 'API credentials' creates a very specific domain unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 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.
The skill provides highly actionable, well-structured API operation definitions with clear YAML schemas and examples. Its main weaknesses are verbosity from repeated boilerplate across steps (especially the identical input descriptions) and missing validation checkpoints for destructive operations like deletion and secret rotation. The monolithic structure could benefit from progressive disclosure given its length.
Suggestions
Add a validation checkpoint before deletion (Step 7) that lists active contracts bound to the application, warning the user about what will be revoked.
Deduplicate the repeated input descriptions (targetOrganizationId, portalId) by defining them once at the top and referencing them in subsequent steps.
Add a verification step after secret rotation (Step 5) to confirm the new secret works before updating all consumers.
Consider splitting the detailed step YAML into a separate reference file, keeping SKILL.md as a concise overview with links to each operation's details.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill has some unnecessary verbosity — repeated 'What you'll need' sections, 'What you've built' celebration text, and redundant descriptions for the same inputs (targetOrganizationId, portalId) copied across every step. The YAML blocks are well-structured but the surrounding prose could be significantly tightened. | 2 / 3 |
Actionability | Each step provides concrete, structured YAML with specific operationIds, input/output schemas, examples, and path expressions. The guidance is copy-paste ready for the API consumer workflow and includes practical examples like redirect URIs and application names. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced and the name-check-before-create pattern is good. However, the deletion step (Step 7) is a destructive operation with no validation checkpoint — no confirmation of contracts that will be revoked, no 'verify application has no active contracts first' step. The secret rotation step also lacks a verification step to confirm the new secret works before decommissioning the old workflow. | 2 / 3 |
Progressive Disclosure | The content is a long monolithic document (~180 lines) with all seven steps inline. Steps like 'View Application Details' and 'Update Application Metadata' could be referenced separately. The 'Next Steps' and 'Related Jobs' sections provide good cross-references, but the main body would benefit from splitting into overview + detailed step files. | 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
- mulesoft/mulesoft-dx
- Commit
32e2b58
- 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.