jpantsjoha Plugin Submission
Treat every public listing as an external representation of the project. Submit only an artifact that the destination's current policy accepts, and retain a receipt for every send.
Workflow
- Classify the destination and artifact. Determine whether it accepts a full
plugin, a repository, or one standalone
SKILL.md. Do not describe a multi-skill plugin as one skill, or split a skill bundle without an explicit portable artifact. - Read the current primary policy. Use the destination's official submission
instructions or
CONTRIBUTING.md; record its URL, access requirements, licence and validation rules, and any limits on automated or AI-assisted submissions. - Validate eligibility. Check the public candidate URL, release/tag, licence as
detected by the hosting platform, manifest/schema validity, documentation, and the
destination-specific validator. Treat a mismatch or unmet requirement as
blocked, not as an invitation to bypass it. - Prepare one destination matrix. For each target, record: destination, artifact,
policy evidence, status (
ready,blocked,deferred, orhuman-only), exact payload, and rollback action. Reuse the canonical repository description; minimise personal data and never add an email without explicit permission. - Stage, then confirm. Fill or draft public data only after the operator has approved the destination. Immediately before clicking a submit control, opening a PR, or sending a recommendation, restate the exact target and payload and obtain a final human confirmation. A single confirmation may cover multiple named sends only when the full set and payloads are shown together.
- Send through the permitted route. Use a form, PR, issue, or API only when the policy permits that route. Never act where a policy requires a human-authored recommendation, prohibits AI-assisted submissions, or requires credentials/access the operator has not supplied.
- Verify and record the receipt. Capture the submission URL/identifier and status. If a listing is rejected or stale, record the reason and next eligible action. Roll back a repository contribution by closing its PR/issue when appropriate; external directory records require the destination's own removal/update path.
Submission Gate
Do not send until all applicable checks pass:
- The target policy is current and supports the proposed artifact.
- The public repository and exact release are accessible.
- Project licence intent and platform-detected licence agree.
- Required validation has passed, including the destination's validator where available.
- The project has not overstated supported platforms, usage, security review, or affiliation.
- The operator has given final confirmation for the exact outgoing entries.
Outputs
- A destination matrix with evidence URLs and eligibility verdicts.
- A staged payload for every ready target.
- Submission receipts, or an explicit blocked/deferred reason and owner.
Anti-rationalisation
| Temptation | Gate |
|---|---|
| “It is close enough to call the bundle one skill.” | Submit the artifact type the directory actually accepts, or create a deliberate portable export first. |
| “The README says Apache, so platform metadata does not matter.” | Directories evaluate the public repository; resolve detected-licence mismatches before broad listing. |
| “The user asked to submit, so the final click is implied.” | A final confirmation binds authority to the exact external payload. |
| “A PR is harmless discovery.” | A public PR is a durable representation of the project and must follow the contributor policy. |
| “We can automate a human-only form.” | Human-only and no-AI policies are hard stops. |