golang-stretchr-testify
Comprehensive guide to stretchr/testify for Golang testing. Covers assert, require, mock, and suite packages in depth. Use whenever writing tests with testify, creating mocks, setting up test suites, or choosing between assert and require. Essential for testify assertions, mock expectations, argument matchers, call verification, suite lifecycle, and advanced patterns like Eventually, JSONEq, and custom matchers. Trigger on any Go test file importing testify.
87
89%
Does it follow best practices?
Impact
77%
1.67xAverage score across 3 eval scenarios
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 identifies its domain (stretchr/testify for Go), lists specific capabilities across multiple packages, and provides explicit trigger conditions. It uses third person voice appropriately and includes both high-level and granular trigger terms that a Go developer would naturally use.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and concepts: assert, require, mock, suite packages, mock expectations, argument matchers, call verification, suite lifecycle, Eventually, JSONEq, custom matchers. These are highly specific capabilities. | 3 / 3 |
Completeness | Clearly answers both what ('Covers assert, require, mock, and suite packages in depth') and when ('Use whenever writing tests with testify, creating mocks, setting up test suites, or choosing between assert and require. Trigger on any Go test file importing testify.'). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms: 'testify', 'assert', 'require', 'mock', 'suite', 'Go test file', 'assertions', 'mock expectations', 'argument matchers'. These are exactly the terms a Go developer would use when seeking help with testify. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — targets a specific Go library (stretchr/testify) with specific package names and patterns. Very unlikely to conflict with general Go testing skills or other language testing skills due to the explicit library and package references. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
79%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, well-structured testify reference skill with excellent actionability and conciseness. Code examples are executable and cover the key API surface area effectively. The main weaknesses are the lack of a complete mock workflow inline (delegated to a missing reference file) and the slightly unbalanced content distribution — assertions are comprehensive inline while mocks are sparse without the bundle support.
Suggestions
Include a minimal but complete mock example inline (define mock, set expectations, call SUT, assert expectations) so the skill is self-contained even without the referenced mock.md file.
Add the referenced ./references/mock.md bundle file or expand the mock section to cover the core mock workflow without requiring external navigation.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient throughout. It assumes Claude knows Go testing basics, avoids explaining what testify is beyond a one-line intro, and uses code examples as the primary teaching mechanism. The assertion reference table is dense but useful — every line adds a distinct API call. | 3 / 3 |
Actionability | All code examples are executable Go code, not pseudocode. The assert/require distinction is shown with a complete, copy-paste-ready test function. The suite example includes the required launcher function. The Common Mistakes section provides specific anti-patterns with concrete fixes. | 3 / 3 |
Workflow Clarity | The skill covers multiple distinct topics (assert vs require, mocks, suites) with clear sections, and the suite lifecycle is well-sequenced. However, there's no explicit workflow for writing tests end-to-end (e.g., when to create mocks, when to verify expectations), and the mock section defers most detail to a reference file without showing a complete mock workflow inline. | 2 / 3 |
Progressive Disclosure | The skill references a mock reference file (./references/mock.md) and cross-references other skills, which is good structure. However, the bundle has no files, so the mock reference is unverifiable. The core assertions section is quite long inline and could benefit from being split out, while the mock section feels too thin without its reference file being available. | 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 |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Repository
- samber/cc-skills-golang
- Commit
e9761db
- 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.