Update to Vertical Bar Agent

{
  "name": "deployment",
  "description": "Assemble a CrossCheck Release Package and run it through a CI workflow — create the package, add customization items, then start a workflow run and follow it. Use when the user wants to deploy, promote, or release NetSuite customizations between environments, asks what a release contains, wants a CI workflow started or its run status, or says deploy / release / promote / 배포 / 릴리스. These are the only mutating tools this plugin exposes; read the authorization rules below before calling one.",
  "included_files": [],
  "skill_md_contents": "---\nname: deployment\ndescription: Assemble a CrossCheck Release Package and run it through a CI workflow — create the package, add customization items, then start a workflow run and follow it. Use when the user wants to deploy, promote, or release NetSuite customizations between environments, asks what a release contains, wants a CI workflow started or its run status, or says deploy / release / promote / 배포 / 릴리스. These are the only mutating tools this plugin exposes; read the authorization rules below before calling one.\n---\n\n# Deployment — release packages and CI workflow runs\n\nFour read tools and three that mutate. The mutating three are the **only** writes this plugin\nperforms against CrossCheck, and they are governed differently from everything else here.\n\n| Tool | Kind | Requires |\n| --- | --- | --- |\n| `cc_list_release_packages`, `cc_get_release_package` | read | workspace scope |\n| `cc_list_ci_workflows`, `cc_get_ci_workflow`, `cc_get_ci_workflow_run` | read | Cognito identity + workspace scope |\n| `cc_create_release_package` | **MUTATES** | `deploy:write` |\n| `cc_add_release_package_items` | **MUTATES** | `deploy:write`, package still a draft |\n| `cc_start_ci_workflow_run` | **MUTATES** | an **identified Cognito user** |\n\n## The authorization rule that trips people\n\n`cc_start_ci_workflow_run` needs a real signed-in human. This is a server guard, not a client check,\nso you cannot work around it and should not try.\n\nWhen a run is refused for identity, call `runtime_info` before choosing the recovery path. On an\ninstalled local surface, use the **`setup`** skill to sign in, then retry. On a hosted remote surface,\n`setup` and `login` do not exist: ask the user to reconnect or reauthorize the MCP connector in the\nhost, then retry only after `runtime_info` / `whoami` reports verified request identity. Do not report\nan identity refusal as a workflow problem.\n\nCall `cc_start_ci_workflow_run` only for the deployment intent the user explicitly requested in the\ncurrent conversation. Some hosts additionally require fresh human interaction for every call; that\nhost prompt is a safety aid, not authorization authority. It does not approve a Pipeline stage.\nStage approval still happens in CrossCheck, by a person. Never imply the plugin can approve that\nstage.\n\n## The order, and why it is the order\n\n1. **Resolve workspace routing from `runtime_info`.** Call `cc_workspaces`: use the\n   sole result automatically. If more than one is returned, ask the user to choose by safe name.\n   Never select the first, invent an id, or reuse one after the conversation changes workspace.\n2. **`cc_create_release_package`** `{workspaceId?, name, description?, environmentId?}` — returns the\n   server response unchanged, including the package id you will need next.\n3. **`cc_add_release_package_items`** `{workspaceId?, packageId, items[]}` — the response carries\n   `autoInclude.status`. **Read it.** CrossCheck may pull in dependencies you did not list, and that\n   set is what will actually deploy. Report what `autoInclude` added, not what you asked for.\n   Items can only be added while the package is a **draft**; a package past that state refuses, and\n   the refusal is the server's, so surface it verbatim rather than retrying.\n4. **`cc_list_ci_workflows`** / **`cc_get_ci_workflow`** — pick the workflow and read its ordered\n   stages. `cc_get_ci_workflow` joins each stage to its environment name, which is the only readable\n   way to confirm a promotion is aimed where the user thinks it is. Confirm the target environment\n   with the user before step 5 whenever the workflow touches production.\n5. **`cc_start_ci_workflow_run`** `{workspaceId?, workflowId, packageId}` — the request body is exactly\n   the package id. The host must ask a person immediately before this call. Returns the server\n   response unchanged; actual environment writes remain blocked on CrossCheck stage approval.\n6. **`cc_get_ci_workflow_run`** — poll for status. A started run is not a finished one; do not report\n   a deployment as done from the start call's response.\n\n## Reporting\n\n* **The server is authoritative on everything** — authorization, identity, workspace, draft state,\n  baseline rules. These tools return its response *unchanged* by design. Quote it; do not paraphrase\n  a refusal into your own words, and never soften one into \"it may not have permission\".\n* **Say what is in the package**, from `cc_get_release_package` after the adds, not from the list you\n  submitted — `autoInclude` is exactly the gap between the two.\n* **A run has stages.** \"Started\" is one fact and \"passed\" is another; give the run id and the stage\n  it is on rather than a single verdict.\n\n## Do not\n\n* Do not create a package to \"see what happens\". These are writes to a customer's release pipeline.\n* Do not start a run the user did not ask for, and never as a way of testing that a package is valid.\n* Do not retry a refused mutation with different arguments hoping it lands — a refusal names its\n  reason, and working around it is the one thing this governed exception exists to prevent.\n"
}