Update to Plugin Autopilot

{
  "name": "plugin-experience-architect",
  "description": "Use when a set of candidate Skills or app capabilities is technically valid but still needs to become a clear, useful ChatGPT/Codex Plugin that people can understand, discover, and invoke for real work.",
  "included_files": [],
  "skill_md_contents": "---\nname: plugin-experience-architect\ndescription: Use when a set of candidate Skills or app capabilities is technically valid but still needs to become a clear, useful ChatGPT/Codex Plugin that people can understand, discover, and invoke for real work.\n---\n\n# Plugin Experience Architect\n\nDesign the Plugin around user jobs rather than the source repository's internal taxonomy.\n\n## Product decisions\n\n1. State the primary user and the recurring job the Plugin should help complete.\n2. Group candidate Skills by distinct user outcome. Merge duplicates and remove implementation-only capabilities from public discovery.\n3. Make Skill boundaries mutually understandable: each Skill should answer a different invocation question.\n4. Decide which external apps are required, optional, or unnecessary. A Skill should not force authentication unless its workflow truly depends on external data or actions.\n5. Define the host-workspace capability profile. Decide whether the Plugin benefits from read, list, search, grep, write, patch, shell, and Python, and distinguish read-only discovery from mutation-capable operations.\n6. For Plugins that interact with files, repositories, generated artifacts, or local workspace state, include `host-workspace-operator` as a baseline Skill. For deterministic computation/file processing, pair it with `sandbox-python-executor` when appropriate.\n7. Write Plugin listing language from observable capability. Do not promise outcomes the packaged Skills/apps or current host cannot provide.\n8. Choose capabilities that describe meaningful user work, not internal mechanics. Host-native operations may support a capability without becoming the marketing headline.\n9. Write starter prompts as concrete tasks a user would genuinely ask. Cover the Plugin's highest-value workflows without repeating the same request in different words.\n10. Review implicit invocation policy per Skill. Narrow, low-risk workflows may be suitable for implicit discovery; sensitive or destructive workflows need tighter invocation boundaries.\n11. Check the portfolio for discovery collisions, jargon, unexplained acronyms, and source-project naming that means nothing to a new user.\n12. Keep the public surface intentionally smaller than the repository when that produces a clearer product.\n13. Define the one product idea the brand mark should express. Describe the relationship/action visually without prescribing generic AI symbols.\n14. Create a discovery test brief with direct, indirect, and negative prompt families before final listing copy is frozen.\n\n## Host-workspace capability profile\n\nRecord each operation with one of these dispositions:\n\n- `preferred`: the Plugin commonly needs the operation when the host provides it\n- `optional`: useful for some workflows but not required for the core job\n- `mutation`: changes workspace state and needs an explicit authorization boundary\n- `not_needed`: should not be surfaced merely because a host may provide it\n\nAssess at least:\n\n```text\nread\nlist\nsearch\ngrep\nwrite\npatch\nshell\npython\n```\n\nDo not describe these as permissions granted by the Plugin. They are host-native capabilities the Skill can use when present.\n\nIf the Plugin performs repository work, default read/list/search/grep to the discovery phase. Treat write/patch and mutating shell commands as mutation operations. Use Python for deterministic local computation and verification, not as a generic substitute for narrower file/search tools.\n\n## Decision test\n\nFor every public Skill, answer:\n\n- Who needs this?\n- What triggers it?\n- What finished result does it produce?\n- Why is this a separate Skill rather than part of another one?\n- Does it require an app or runtime dependency?\n- Which host-native read/search/mutation capabilities help complete it?\n- What could go wrong if it is invoked implicitly?\n- What source evidence proves the workflow is real?\n\nIf these answers are weak, return the candidate to discovery/compilation instead of polishing the listing.\n\n## Output\n\nProduce a Plugin experience brief containing:\n\n- primary audience and recurring job\n- public Skill set and exclusions\n- required/optional app dependencies\n- host-workspace capability profile\n- mutation boundary for write/patch/shell actions\n- whether `host-workspace-operator` should be installed\n- whether `sandbox-python-executor` is needed\n- Plugin promise grounded in packaged behavior\n- capability list\n- up to three starter prompt directions\n- direct, indirect, and negative discovery-prompt directions\n- invocation-policy notes\n- one visual idea for the brand mark\n- listing risks or unsupported claims\n\n## Handoff order\n\nDo not jump straight from product design to submission.\n\n1. If the target Plugin uses local files or repository state, install the canonical workspace Skill with `install_host_workspace_skill.py`. Do not overwrite an existing customized version without review.\n2. Hand the stable Plugin concept to `plugin-brand-identity-designer` for the light/dark SVG identity pack and compact composer/icon asset.\n3. Hand the exact capabilities, starter prompts, brand paths, host-workspace profile, and discovery test brief to `plugin-directory-listing-writer`.\n4. Run the main Autopilot package validator and `build_directory_pack.py` against the exact artifact.\n5. Only after those gates pass, hand the artifact and evidence to `submission-pack-builder`.\n\nIf workspace capability planning, branding, or listing work exposes a confused product boundary, return to this Skill instead of polishing around the problem.\n"
}