guidewire-local-dev-loop
Iterate on Gosu rules and configuration without paying the full 5–15 minute runServer rebuild every time. Use when standing up Guidewire Studio against a local InsuranceSuite instance, attaching an IntelliJ remote debugger to runServer, distinguishing changes that hot-reload from changes that force restart, or building a GUnit-driven TDD cycle for rule logic. Trigger with "guidewire studio", "gosu hot reload", "gosu debugger", "gunit", "guidewire runServer".
71
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
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 an excellent skill description that clearly defines a narrow, specialized domain (Guidewire/Gosu development workflow) with concrete actions, explicit trigger guidance, and highly distinctive terminology. It follows the recommended structure with 'Use when...' and 'Trigger with' clauses, and uses third-person voice throughout. The only minor consideration is that the description is somewhat long, but the length is justified by the specificity of the content.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: iterating on Gosu rules/configuration, standing up Guidewire Studio against a local InsuranceSuite instance, attaching an IntelliJ remote debugger, distinguishing hot-reload vs restart changes, and building a GUnit-driven TDD cycle for rule logic. | 3 / 3 |
Completeness | Clearly answers both 'what' (iterate on Gosu rules without full rebuild) and 'when' (explicit 'Use when...' clause with multiple scenarios plus a 'Trigger with' list of keywords). Both dimensions are thoroughly addressed. | 3 / 3 |
Trigger Term Quality | Includes highly specific natural trigger terms that users in this domain would actually say: 'guidewire studio', 'gosu hot reload', 'gosu debugger', 'gunit', 'guidewire runServer'. Also includes contextual terms like 'IntelliJ remote debugger', 'InsuranceSuite', and 'GUnit-driven TDD cycle'. | 3 / 3 |
Distinctiveness Conflict Risk | Extremely niche domain (Guidewire/Gosu development) with highly distinctive trigger terms like 'guidewire studio', 'gosu hot reload', 'gunit'. Very unlikely to conflict with any other skill. | 3 / 3 |
Total | 12 / 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 strong, highly actionable skill that provides concrete commands, a critical decision table for hot-reload vs restart, and thorough error handling. The workflow is well-sequenced with explicit validation steps. Minor weaknesses include slightly verbose framing in the overview/output sections and references to bundle files that don't exist.
Suggestions
Trim the Overview section — the three numbered problems could be condensed to a single sentence each or a compact table, saving ~100 tokens.
Either provide the referenced bundle files (references/implementation-guide.md, references/API_REFERENCE.md) or remove the dangling references to avoid confusion.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The overview section explaining the three productivity problems is useful context but slightly verbose. The prerequisites list basic knowledge Claude would know (what JDK is, what RAM is for). The hot-reload table and error handling table are dense and valuable, but some surrounding prose could be tightened — e.g., the 'Output' section restates what was already covered. | 2 / 3 |
Actionability | Provides fully executable gradle commands, specific IntelliJ configuration steps, concrete bash examples for GUnit TDD, and a detailed hot-reload table with exact change types and their consequences. The examples are copy-paste ready and cover real scenarios. | 3 / 3 |
Workflow Clarity | The five-step workflow is clearly sequenced with explicit validation checkpoints — notably the breakpoint verification habit (step 3 and throughout), the hot-reload table as a decision gate, and the error handling table providing feedback loops for common failure modes. The 'trust the JVM, not Studio' validation principle is a strong checkpoint. | 3 / 3 |
Progressive Disclosure | References to 'references/implementation-guide.md' and 'references/API_REFERENCE.md' are made but no bundle files exist to back them up. The See Also section links to other skills appropriately. However, the skill is quite long (~200 lines) and some content like the full error handling table could potentially be split out. The structure within the file is well-organized with clear headers. | 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 | |
- Commit
a04d1a2
- 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.