This skill should be used when the user asks to "deploy to power pages", "upload site", "publish site", "deploy site", "push to power pages", "upload code site", or wants to deploy/upload an existing Power Pages code site to a Power Pages environment using PAC CLI.
85
83%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
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 description excels at trigger term coverage and completeness, clearly specifying when the skill should be used with multiple natural language variations. Its main weakness is that it focuses on a single action (deploy/upload) described many ways rather than listing distinct concrete capabilities. The description is functional and effective for skill selection despite being somewhat repetitive.
Suggestions
Add more specific concrete actions beyond deploy/upload, such as 'Authenticates with PAC CLI, uploads site content, validates deployment status' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description mentions deploying/uploading a Power Pages code site using PAC CLI, which names the domain and a key action, but it doesn't list multiple specific concrete actions beyond deploy/upload. It's essentially one action described in multiple synonymous ways. | 2 / 3 |
Completeness | The description explicitly answers both 'what' (deploy/upload an existing Power Pages code site to a Power Pages environment using PAC CLI) and 'when' (lists specific trigger phrases with 'Use when' equivalent phrasing at the start). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'deploy to power pages', 'upload site', 'publish site', 'deploy site', 'push to power pages', 'upload code site', 'PAC CLI'. These are phrases users would naturally say when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Very distinct niche — Power Pages deployment via PAC CLI is highly specific and unlikely to conflict with other skills. The combination of 'Power Pages', 'PAC CLI', and deployment-specific triggers creates a clear, unique identity. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, highly actionable deployment skill with clear multi-phase workflows, explicit validation checkpoints, and thorough error handling paths. Its main weakness is length—at 350+ lines with all content inline, it could benefit from splitting troubleshooting and reference material into separate files. The workflow clarity and actionability are excellent, with specific commands, decision trees, and feedback loops throughout.
Suggestions
Extract the troubleshooting section (HTML Blocked Attachment Error) and the Progress Tracking table into separate reference files to reduce the main skill's token footprint.
Tighten Phase 6.1's explanation—the quoted block explaining why JS is blocked is verbose; a single sentence would suffice since the AskUserQuestion already provides context.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~350+ lines) and includes some verbosity in explanations (e.g., Phase 6.1's quoted explanation to the user, detailed AskUserQuestion table formats repeated throughout). However, most content is necessary given the complexity of the multi-phase deployment workflow. Some sections could be tightened—the troubleshooting section and Important Notes repeat guidance already covered in the phases. | 2 / 3 |
Actionability | Every phase includes specific, executable PowerShell commands, exact CLI flags, and concrete decision trees for success/failure paths. Commands like `pac pages upload-code-site --rootPath "<PROJECT_ROOT>"` and `pac env update-settings --name blockedattachments --value "<UPDATED_LIST_WITHOUT_JS>"` are copy-paste ready with clear placeholders. Error handling paths are specific and actionable. | 3 / 3 |
Workflow Clarity | The 6-phase workflow is clearly sequenced with explicit validation at each step (verify PAC CLI → verify auth → confirm environment → deploy → verify → handle errors). Each phase has success/failure branches with specific next actions. Feedback loops are present (e.g., retry upload after fixing JS block, re-validate after installation, re-run `pac auth who` after authentication). The progress tracking table provides a clear checklist upfront. | 3 / 3 |
Progressive Disclosure | The skill is a monolithic document with all content inline. While it references external skills (`/activate-site`, `/audit-permissions`, `/test-site`) and one reference file (`skill-tracking-reference.md`), the troubleshooting section, progress tracking table, and important notes could be split into separate reference files. The internal anchor links (e.g., `#suggest-next-steps`, `#troubleshooting-html-blocked-attachment-error`) help navigation but the sheer length makes it harder to parse. | 2 / 3 |
Total | 10 / 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 | |
66a61c6
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.