Update to Plugin Autopilot

{
  "name": "plugin-directory-listing-writer",
  "description": "Use when a validated ChatGPT/Codex Plugin needs accurate Plugin Directory fields, discovery metadata, starter prompts, and reviewer-facing listing details grounded in the packaged product.",
  "included_files": [],
  "skill_md_contents": "---\nname: plugin-directory-listing-writer\ndescription: Use when a validated ChatGPT/Codex Plugin needs accurate Plugin Directory fields, discovery metadata, starter prompts, and reviewer-facing listing details grounded in the packaged product.\n---\n\n# Plugin Directory Listing Writer\n\nTurn the exact Plugin artifact into clear public listing metadata. Treat listing copy as product metadata that affects both user understanding and model discovery.\n\n## Authority and freshness\n\nRe-check the current official OpenAI Plugin submission, packaging, metadata, and guideline pages before finalizing a public listing. Portal fields and limits can change. Current official documentation overrides remembered limits and examples.\n\n## Required listing pack\n\nPrepare these fields when the current portal requires them:\n\n- Name\n- Subtitle / short description\n- Description / long description\n- Category\n- Developer name / verified developer identity\n- Website URL\n- Customer support URL\n- Privacy policy URL\n- Terms of Service URL\n- Version\n- Package name\n- Capabilities\n- logo asset\n- starter prompts\n- availability notes when relevant\n- release notes\n\nUse `build_directory_pack.py` to extract package-backed fields and expose missing portal-only material. Do not silently invent missing publisher or legal information.\n\n## Writing rules\n\n### Name\n\nUse the customer-facing product or workflow name. Do not expose internal repository slugs unless they are already the public brand.\n\n### Subtitle\n\nDescribe the plain user function in one short line. Prefer a direct verb or outcome. Keep it within the current portal limit; when the form specifies 30 characters, enforce 30 characters rather than relying on a looser package limit.\n\nAvoid claims such as \"best\", \"perfect\", \"revolutionary\", or unverifiable performance language.\n\n### Description\n\nExplain:\n\n1. what users can do with the Plugin\n2. which repeatable workflows it covers\n3. what external data/actions it needs, if any\n4. material boundaries users should understand\n\nWrite from observable packaged behavior. Do not convert implementation detail into customer value claims.\n\n### Developer identity\n\nThe developer name must match the verified individual or business identity selected in the OpenAI Platform submission flow. Never infer a legal publisher name from a GitHub username, repository owner, email domain, or package author field.\n\n### URLs\n\nRequire public, accurate URLs. The support, privacy, terms, and website pages must match the actual publisher and data handling. Missing URLs are blockers for submission readiness when the current portal requires them.\n\n### Capabilities\n\nUse short user-facing capability statements. Each capability should describe meaningful work the Plugin can actually perform. Remove duplicates and internal mechanics.\n\n### Starter prompts\n\nCreate prompts for the highest-value workflows, not cosmetic variants of the same request. Include direct and indirect phrasing where helpful. Test them against the final Plugin.\n\n## Discovery evaluation\n\nBuild a golden prompt set before final metadata sign-off:\n\n- direct prompts that explicitly name the Plugin or workflow\n- indirect prompts that describe the desired outcome\n- negative prompts where the Plugin should not trigger\n\nRecord expected behavior for each prompt. Revise names/descriptions when recall or precision is poor rather than stuffing unrelated keywords into metadata.\n\n## Submission test material\n\nWhen current OpenAI submission requirements call for reviewer test cases, prepare at least the required positive and negative cases. As of the 2026-08-22 baseline used by this repository, the official portal asks for at least five positive and three negative cases. Re-check before every submission.\n\nEach positive case should state:\n\n- user prompt\n- expected Skill/tool/workflow behavior\n- expected result shape\n- fixture or account data required\n\nEach negative case should state:\n\n- prompt/scenario\n- expected refusal, clarification, or fallback\n- why the Plugin should not complete the action\n\n## Output\n\nProduce a directory pack with:\n\n- source commit/ref and version\n- exact field values\n- character-count checks where applicable\n- asset paths\n- starter prompts\n- golden prompt evaluation set\n- reviewer tests\n- missing publisher/legal information\n- claims that still need evidence\n- status: `listing_ready` or `not_ready`\n\nHand the pack to `submission-pack-builder`. Listing readiness is not submission, approval, or publication.\n"
}