junit5-extensions
Skill0 starsChanged 35 days agoMITView on GitHub
Use when the agent needs to create, review, or debug JUnit 5 extensions, custom annotations, lifecycle callbacks, parameter resolvers, or reusable execution hooks.
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 12 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Use helpers, builders, or local fixtures first.
- Distinctive: line 22
Create an extension only when the behavior is cross-cutting and repeated.
- Distinctive: line 23
Read references/extension-patterns.md before adding a new extension.
- Distinctive: line 24
Read references/lifecycle-and-state.md before storing state or coordinating multiple callbacks.
- Distinctive: line 29
Keep state explicit and scoped safely.
- Distinctive: line 30
Keep extension behavior testable and unsurprising.
- Distinctive: line 31
Prefer explicit registration when discoverability matters.
- Distinctive: line 32
Keep meta-annotations small and intention-revealing.
- Distinctive: line 36
Add focused tests for the extension itself.
- Distinctive: line 37
Verify lifecycle ordering and failure behavior.
- Distinctive: line 38
Avoid hidden global behavior that changes unrelated tests.
- Distinctive: line 39
Read references/extension-testing.md when the extension has multiple callbacks or parameter rules.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
JUnit 5 Extensions
1. Confirm That an Extension Is Warranted
- Use helpers, builders, or local fixtures first.
- Create an extension only when the behavior is cross-cutting and repeated.
- Read references/extension-patterns.md before adding a new extension.
- Read references/lifecycle-and-state.md before storing state or coordinating multiple callbacks.
2. Implement Deliberately
- Choose the smallest relevant callback or resolver interface.
- Keep state explicit and scoped safely.
- Keep extension behavior testable and unsurprising.
- Prefer explicit registration when discoverability matters.
- Keep meta-annotations small and intention-revealing.
3. Validate
- Add focused tests for the extension itself.
- Verify lifecycle ordering and failure behavior.
- Avoid hidden global behavior that changes unrelated tests.
- Read references/extension-testing.md when the extension has multiple callbacks or parameter rules.
4. Troubleshooting
- Problem: The extension hides too much setup. Fix: Move local test setup back into the test class and keep only the true cross-cutting concern in the extension.
- Problem: Parameter resolution is ambiguous. Fix: Narrow the supported parameter types or add clearer registration boundaries.
- Problem: The extension works only when tests run in a certain order. Fix: Remove hidden shared state and verify callback scope explicitly.
In this repository6 other files it gives its agents.
- junit5-analysisSkill
- junit5-architectureSkill
- junit5-ciSkill
- junit5-coreSkill
- junit5-migrationSkill
- junit5-skillSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.