This is a task-based selection, not a ranking by stars or a claim that all fifteen belong in one project. Start with a brief, add the tools needed for one user journey, and check the outcome. Repository maintenance, licenses and integrations can change; follow each linked project’s current documentation.
- Context7
- Playwright MCP
- Serena
- Awesome DESIGN.md
- shadcn/ui
- Tailwind CSS
- Lucide
- Supabase
- Drizzle ORM
- TanStack Query
- Zod
- Vitest
- Playwright
- Gitleaks
- axe-core
1. Context7
Find relevant library documentation before asking an agent to change APIs.
Try this: Choose one dependency already in your project. Ask the agent to identify its installed version, retrieve documentation for one API, and cite the result before editing.
Check the result: The explanation names the dependency version and links to the documentation. The resulting code still needs a local build and test.
Before adopting: Documentation retrieval is a hosted service; check authentication and rate limits. It cannot establish that your application works.
Official repository: upstash/context72. Playwright MCP
Let an MCP-capable assistant inspect and interact with a browser during exploratory checks.
Try this: On a local demo, ask the assistant to create an item, refresh, and check whether it persists. Require observed evidence for each step.
Check the result: A record of the actions and visible outcome, plus a screenshot where helpful. Use a disposable browser profile.
Before adopting: An exploratory session is not a repeatable regression suite. The maintainers also document a separate CLI/skills option.
Official repository: microsoft/playwright-mcp3. Serena
Give an agent symbol-aware ways to explore and edit a supported codebase.
Try this: Ask it to find a function and the references that call it. Review that map before requesting a small refactor.
Check the result: The references correspond to real code, and the existing tests pass after the edit.
Before adopting: Language and backend support matter. Follow the repository quickstart rather than assuming every client integration is identical.
Official repository: oraios/serena4. Awesome DESIGN.md
Study written design-system examples and turn your own visual requirements into a specification.
Try this: Choose spacing, typography and component rules for your project. Write an original DESIGN.md, then apply it to one page.
Check the result: The rendered page follows the documented tokens, including focus, error and mobile states.
Before adopting: Reference collections are not permission to reuse another company’s identity. A Markdown file is not automatically read by every agent.
Official repository: VoltAgent/awesome-design-md5. shadcn/ui
Use documented component patterns instead of asking the agent to invent every control.
Try this: Follow the official setup for your framework. Add one form control and an error message, then inspect its keyboard behavior.
Check the result: The control has a label, usable focus, appropriate error feedback and no accidental form submission.
Before adopting: Components become part of a larger application that you maintain. Accessibility still depends on composition and behavior.
Official repository: shadcn-ui/ui6. Tailwind CSS
Express visual constraints using a utility-based styling system.
Try this: Start from the setup matching your framework and installed version. Implement one responsive card using a small spacing and color palette.
Check the result: The intended layout appears at narrow and wide widths, and the compiled stylesheet includes the classes you use.
Before adopting: Version-specific setup matters. Avoid mixing configuration examples from different major versions.
Official repository: tailwindlabs/tailwindcss7. Lucide
Keep interface icon style consistent using an existing icon library.
Try this: Add an icon to a labeled action in the package matching your framework.
Check the result: The action still has a clear accessible name; a decorative icon does not add duplicate screen-reader text.
Before adopting: An icon alone may not explain an unfamiliar action. Check the package license and attribution requirements.
Official repository: lucide-icons/lucide8. Supabase
Explore a Postgres-based backend when the project genuinely needs shared data or accounts.
Try this: Use a disposable development project to store one non-sensitive example record. Define who should be able to read and write it.
Check the result: A user who should not have access cannot fetch or modify another user’s record.
Before adopting: Hosted services can incur charges. Follow the current security documentation; never put privileged server credentials in a public client.
Official repository: supabase/supabase9. Drizzle ORM
Describe database tables and queries in a typed application workflow.
Try this: In a development database, define a reading-list table and review the migration before applying it.
Check the result: A new record can be inserted and queried, and the migration does not unexpectedly remove existing columns.
Before adopting: It is not a substitute for backups or reviewing destructive schema changes. Use documentation for your database driver.
Official repository: drizzle-team/drizzle-orm10. TanStack Query
Manage asynchronous data, cached results and loading/error states in a supported frontend.
Try this: Use the adapter for your framework to fetch a list, show a loading state, and refresh it after a change.
Check the result: Failed requests produce readable errors; stale data refreshes when intended without an endless request loop.
Before adopting: It manages server-state behavior, not your authorization rules or database security.
Official repository: TanStack/query11. Zod
Describe and validate the shape of data crossing a boundary.
Try this: Define the shape of a saved item and reject a missing title or invalid field type before storing it.
Check the result: Both valid and intentionally malformed inputs have explicit outcomes in tests.
Before adopting: Schema validation alone does not sanitize arbitrary HTML or authorize a request. Validate again at the server boundary when there is one.
Official repository: colinhacks/zod12. Vitest
Check small pieces of application logic with repeatable assertions.
Try this: Write tests for filtering a reading list, including an empty list and a missing field.
Check the result: The test fails for an intentionally broken implementation, then passes after the correction.
Before adopting: A passing unit suite does not prove that the browser interface or deployment works.
Official repository: vitest-dev/vitest13. Playwright
Turn a critical browser journey into a repeatable test.
Try this: Automate adding an item and checking the visible list after refresh. Use locators based on labels or roles.
Check the result: The test makes assertions about what the user sees, rather than merely clicking without checking results.
Before adopting: Browser installation and CI configuration are separate setup steps. Keep fixtures and credentials isolated.
Official repository: microsoft/playwright14. Gitleaks
Look for likely secrets in a repository before sharing code.
Try this: Follow the official installation instructions, then scan a disposable example repository with a deliberately fake test token.
Check the result: Review the finding without publishing a real credential. Remove fixtures before using the same process on real work.
Before adopting: No scanner finds every secret. If a genuine secret was exposed, deleting it from the latest file is not sufficient; rotate it.
Official repository: gitleaks/gitleaks15. axe-core
Add automated accessibility checks to a browser testing workflow.
Try this: Run a supported integration against one local form and fix a reported missing-label issue.
Check the result: The automated issue is resolved, and the control is also checked manually with a keyboard.
Before adopting: Automated checks cover only part of accessibility. Reading order, task clarity and assistive-technology behavior need further review.
Official repository: dequelabs/axe-coreA small starting workflow
Write a project brief, find the relevant API with Context7, define an original DESIGN.md, then inspect the complete browser journey. Add database or state-management packages only when the project requires them.