Revise plugin development procedure with ecosystem checks

[MattPearce]

Updated the procedure section to include ecosystem checks before creating a new plugin.

Let's nudge agents toward first maintaining the ecosystem rather than duplicating effort on vastly similar plugins.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: MattPearce <mattpearce@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[MattPearce]

I've now linked my .org account to my GH but can't add a label to retrigger the bot?

[justlevine]

@MattPearce thanks for your contribution 🤩

I'm not sure I agree with either the skill's premise or its the wording. (I agree and laud the goal to not "rip off" perfectly good actors or plugins or generally churn out duplicative slop.)

AI - and particularly now that you can "just use a skill" to scaffold the plugin - changes the math about when you should use an existing plugin vs code your own. And with the barriers to entries removed, even the fact that it made it through the PRT onto .org doesn't actually guarantee that it's a smart choice to use a plugin at all let alone that specific ones it found via a nonsemantic search - or their actual codebase - of the directory.

That 🌶️take aside, I think we can agree that current LLMs are incapable of enough inference to do any actual "Evaluate"ions, especially without specific instruction on how to determine whether a plugin "covers" any functionality or how to determine what a "core problem" is and whether the plugin "solves" it effectively. Which means in the current loop, there's never a situation where this provides any actual value to the implementation skill and isn't inherently high-token context rot.

At minimum for this to be effective it needs a ref on how to evaluate plugins. Even then it would assumedly be more effective as its own skill explicitly invoked by this one or ideally by the user in a separate context window before this one is invoked.
And then I'd still recommend we eval them heavily, because even if we can agree on the criteria and the best way to handle them as an instruction, my anecdotal experience is even the frontier models at xhigh are currently unable to handle the tasks - even as they eat up entire context windows finding individual plugin svns and grepping their docs and codebases.

[justlevine]

(Please tell me I didn't scare you off 😬😟 If so I'm very sorry. my intent was to provide a direction to consider and iterate on)