Choose a plugin for a problem, not popularity
Start with the team’s pain point, then identify a category, shortlist candidates, and inspect the real capability surface. Ratings, downloads, and stars do not prove fit for your process.
A plugin that improves context discovery or project rules can be more useful than a code generator.
| Choice level | What to find out |
|---|---|
| Category | Code review, PR, testing, UI, Git, infrastructure, and so on |
| Specific plugin | Maintainer, package contents, and compatibility |
| Capability surface | What it reads, changes, runs, and can access |
Useful categories
- Documentation and reference.
- Code navigation and onboarding.
- Code review, Git, GitHub, and PR.
- Browser and UI testing.
- Frontend, refactoring, and static scanning.
- Infrastructure and delivery.
- Custom skills and Workflow Kit.
Practical selection workflow
- Describe one primary team problem.
- Choose one primary and, if needed, one related category.
- Build a short candidate list.
- Check documentation, maintenance, compatibility, and permissions.
- Inspect skills, hooks, shell, network, and write operations.
- Find overlap with existing workflows.
- Select the smallest package that solves the problem.
Capability summary before installation
Package: team-review-kit
Primary category: code review
Related: Git/PR
Out of first version: browser testing, infrastructure
Goal: consistent self-review
Check:
- skills and commands;
- hooks and shell scripts;
- network and credentials;
- files or state it can change.Remove duplicates
Do not install a separate plugin for every category when capabilities overlap. Compare the surfaces, remove duplication, and identify which package owns each workflow.
Canonical lesson source · JavaRush
Open JavaRush material