Plugins Resources

Choosing and checking a resource

Plugin listings can describe design notes, instruction text or an actual packaged extension. Inspect the downloaded material before assuming it includes executable components. A capability label is intended use, not recorded installation or proof of automatic tests, security enforcement or a persistent memory database.

Check the named host and version, entry points, manifest schema, component files and dependencies separately. JSON syntax alone does not prove that a plugin loads or registers a tool. Prefer the host’s primary documentation over a generic manifest copied from a different application.

For an owned metadata exercise, parse the demo-fullstack-review manifest and inspect its name and version. It contains no tools field and therefore does not by itself supply a compiler, migration guard or test runner. A separate component must implement each advertised capability and have a permitted successful and failed invocation test.

Inspect data flow as well as registration. Memory text, repository files and diagnostics may be sent to an embedding or model provider after installation. Determine storage location, access scope, retention and deletion behavior. Do not infer offline processing or cross-branch authorization from a folder named memory_db.

Keep meaningful successful, invalid and boundary outcomes separate from startup. A memory query can retrieve a stale document; a cloud plan check can miss a consequential change; a host can register a tool whose invocation fails. Preserve those limits and do not convert a toy exercise into a reliability score or permission grant.

The directory includes AI-generated examples and third-party or community material. Check each source and redistribution terms before reuse; SimplyUtils-generated template terms remain unconfirmed and third-party packages retain their own licenses. Downloads require review and adaptation, not an automatic install. Report the listing URL and a small redacted reproduction when a claimed component is absent.

Begin selection with the job you actually need performed. If you want an assistant to remember a project decision, inspect a memory design guide. If you want to review an infrastructure change, inspect the Terraform review guide. If you want a host to expose a small capability, inspect its registration design. These tasks require different inputs and controls. A broad plugin label is less useful than a clear statement of the operation, the allowed environment and the expected result. Choose the smallest relevant resource instead of enabling several unrelated components at once.

For a synthetic selection exercise, imagine an owned project that needs to preserve a decision about an API field. The memory guide offers a scoped ranking model and explains stale records; the full-stack guide explains how to compare a proposed field change with a client contract. Neither download creates an installed database or checker. Read both descriptions, then choose the guide that answers the immediate question. Keep any follow-up installation as a separate task with its own host requirements and permission review. The expected directory result is finding the relevant guide, not activating a plugin.

Review an actual download before adding it to a project. Inspect whether it is Markdown advice, an illustrative manifest, source code or a complete package with the necessary component files. Keep placeholders visible until their values have been reviewed. A file containing a version string is not evidence that the named dependency is installed. If a resource references a component that is not supplied, record it as a requirement rather than pretending the download includes it. Consult the selected host's current documentation for the real installation mechanism.

Plan a disposable evaluation with a known input and expected output. A registration exercise should show which object was registered and what happens with invalid inputs. A retrieval exercise should show the eligible records, their ordering and the empty-result case. A plan-review exercise should explain why a deletion label was flagged and what other checks remain. Keep startup evidence separate from successful invocation. A component can load without doing the advertised job, so finding it in a host's list is only one step in the review.

Treat resource metadata as a way to navigate, not as independent proof of safety or compatibility. Tags can help locate an intended platform but do not establish authorization, verified performance or a working installation. Read any limitations alongside the example. An AI-generated guide may contain useful design reasoning while still requiring adaptation and verification. Upstream packages, submitted text and SimplyUtils examples can have different ownership and terms. Check the individual listing and source rather than applying a license or support promise to the entire directory.

Directory search is useful for narrowing titles, descriptions and tags. Try a concrete task word such as memory or Terraform, then open a matching listing and read its full guide. If a search returns no results, clear it and compare the available categories before concluding that a capability exists or is missing. The search does not inspect your repository, authenticate to a host or run any downloaded code. Reading a list of related tools should not be counted as a demonstration that they work together.

When reporting an issue, include the listing URL, the exact missing file or misleading statement, the selected host version and a small redacted reproduction. Separate a broken download from an unsupported installation step and from an unavailable provider. Avoid attaching credentials, private repository text or production logs. A report should make the fault repeatable without granting broad access. Keep any repair focused on the relevant resource, and repeat its successful and invalid cases before using it in a larger workflow.

Before keeping a resource in a persistent setup, decide how it will be updated or removed. Record which component files were added and which configuration entries were changed. Revisit earlier test evidence when a dependency, host interface or guide changes. Preserve an unavailable result as unavailable rather than treating the last successful run as current proof. This directory provides discovery and explanatory guidance; any connected execution, data retention and account access depend on the components you deliberately select and configure.

• Next.js Project Review Guide - AI-generated guide for reviewing Next.js routes and project boundaries; no scaffolder or linter is bundled.
• Terraform Infrastructure Review Guide - AI-generated plan-review guide with a tested destructive-action fixture. No plugin, security enforcement, cloud execution or cost estimate is supplied.
• FastAPI Backend Review Guide - AI-generated guide with a Python validation exercise; it does not include a FastAPI/Pydantic plugin suite.
• DeepSeek Plugin Design Guide - AI-generated plugin-planning guide with a host-independent registration exercise. It is not a packaged Harness plugin or a verified implementation of its evolving API.
• Claude Full-Stack Plugin Design Guide - AI-generated plugin-design checklist with a minimal metadata exercise. It includes no capability pack, migration runner or automatic schema verification.
• Vite Component Review Guide - AI-generated guide and native HTML exercise; no Vite scaffolder or installed component package is supplied.
• Docker and Kubernetes Review Guide - AI-generated review guide with local status example; it does not ship a Docker or Kubernetes command wrapper.
• Agent Memory Retrieval Design Guide - AI-generated memory-system design notes with an original scoped cosine-ranking exercise. No installable database plugin or zero-hallucination guarantee is included.