What a Rejected Copilot Plugin Taught Us
A rejected submission can be useful evidence when the outcome and limitations are stated plainly.
Edoworks submitted orqit to GitHub's Awesome Copilot intake. The submission passed automated schema checks and was rejected during manual review. The public intake record documents the process and outcome.
The rejection was reasonable
The plugin repeated capabilities that the host platform had added natively, including planning and model routing. It also encoded workflow assumptions that were specific to one operating environment. Passing a format check did not make those choices generally useful.
Three lessons worth keeping
- Build for a real gap. Repackaging a native capability creates another code path without adding transferable value.
- Separate portable behavior from local policy. Team-specific gates and conventions belong with the team unless they can be stated and tested independently.
- Treat distribution as review. A valid package is only a candidate. Maintainer review can still show that the package should not be published.
What this does not prove
The submission does not demonstrate marketplace acceptance, broad usefulness, adoption, or product demand. It demonstrates a failed distribution attempt with public feedback. That narrower claim is the useful one.