Prepare and submit a useful directory listing

A useful directory listing helps another developer make a decision quickly. They should be able to tell what your project does, whether it fits their application and where to find reliable instructions. WirePackages organises submissions into packages, starter kits, tools and freelancer profiles so those decisions begin in the right place.

This guide covers a package, starter kit or tool submission from preparation to review. You do not need a long sales pitch. You do need accurate links, a clear description and enough practical detail for someone who has never heard of the project. Start with the information you would want before adding a new dependency yourself.

Search before creating a new entry

Look for the project's name in the directory and check any matching result. The editorial team may already have prepared an entry, or another authorised member of your team may have submitted one. If an unclaimed editorial listing already exists, use its ownership process rather than creating a duplicate.

Similar names are common, especially among small utilities. Follow the repository and website links before deciding that a match belongs to you. A package fork, a product's desktop edition and a starter kit built around that product may reasonably have different entries. The distinction should be clear in their names and descriptions.

If your project has changed names, review the existing entry first. Updating a recognised listing is usually more useful to readers than leaving an old page behind and adding another that looks unrelated. Keep the explanation of the change concise and point the links at the current official destination.

Choose the section that matches the product

A package is normally a dependency that someone adds to an application. A starter kit supplies the beginning of a new application, including decisions about structure, authentication or frontend tools. A tool supports the development workflow, whether it runs in a terminal, on a desktop or as a hosted service.

Choose the section based on what the reader installs or uses. A Laravel-powered desktop application is still a tool if its purpose is managing projects. A repository containing a complete application template belongs with starter kits even if Composer installs it. Explaining this distinction prevents a reader from trying to require an entire application as a library.

Use the available category and tags to add detail, rather than trying to squeeze every keyword into the name. Keep tags close to actual features and integrations. A package that works with Laravel is not automatically a Filament plugin, and a tool with an AI-related feature is not necessarily an agent framework.

Write a description people can evaluate

Open with the problem the project solves and who it is intended for. Follow with the workflow, the important features and any requirements that affect adoption. For a package, supported PHP and Laravel versions are useful. For a desktop application, platform availability matters more than the framework used to build its marketing site.

Include limitations that materially affect the decision. If a starter kit includes an unauthenticated demonstration endpoint, say that setup is required before production use. If an integration depends on a paid account elsewhere, explain that dependency. These details make the listing more credible and save maintainers repetitive support questions later.

Write in your own words and use concrete examples. Avoid copying an entire README into the description without checking whether its instructions still apply. If you include a code example, run it in the environment you describe and make the required dependencies clear. Readers should not have to guess which version the example targets.

Check the links and images

Use the official homepage, repository and documentation URLs. Open each one before submitting. A repository link that redirects after a rename may still work, but the current destination is easier to understand. A documentation link should lead to usable guidance rather than a generic search page or an unfinished section.

Choose images that show the product accurately. A real interface screenshot or a clear project identity is more informative than unrelated stock imagery. Remove personal data, credentials and private customer content before uploading a screenshot. Keep text large enough to remain legible when the image appears on a directory card.

The form applies upload limits, including allowed image formats and file size. Follow the validation messages if an upload is rejected. If the project has a logo and a screenshot, make their roles clear: the logo identifies the project, while the screenshot should help readers understand how it works.

Save, submit and review the result

Sign in, open Submit and choose the appropriate listing type. Fill in the fields, review the description and save the entry. Drafts let you prepare information before asking for publication. When the listing is ready and any applicable requirements are met, submit it for moderation.

Submission is not the same as publication. The moderation flow gives the team an opportunity to check relevance and accuracy. If an entry needs changes, use the feedback to improve the existing submission. Repeated duplicate entries make that review harder and can leave readers unsure which page is authoritative.

Once the entry is published, open its public page and check it again. Confirm that the title, links, images and pricing category match what you intended. Read it on a narrow screen as well as a desktop if possible. The public page is the experience prospective users receive, so it deserves a final pass.

Maintain the entry as the project changes

Return to My listings when a release changes compatibility, documentation or availability. A concise current listing is more useful than an impressive description of a version nobody should install. If a project is discontinued, update its status and explanation through the available management flow rather than leaving readers to discover that after installation.

Good directory content reduces uncertainty. It tells a developer what they are getting, which instructions to follow and what to check next. That is the standard to aim for when preparing a submission, and the same standard makes later updates much easier to review.