Request

request

Submit cloud resource, application environment, or ticket/work order requests through the service catalog.

Flow

Eight tools exist: smartcmp_list_services, smartcmp_get_request_catalog, smartcmp_list_available_bgs, smartcmp_list_flavors, smartcmp_list_facets, smartcmp_list_resource_bundles, smartcmp_submit_request, and smartcmp_get_request_status.

Multi-resource routing boundary

This skill is for one CMP request flow at a time. That single flow may still represent one service catalog / one resource type / one shared parameter set with quantity N.

Keep the request in this skill when the user wants multiple instances of the same resource type with the same configuration, for example:

• "several identical Linux VMs for one project"
• "multiple instances of the same database service with shared parameters"
• "quantity N of one resource type with one shared parameter set"

Route to request-decomposition-agent only when the request needs to be split into distinct sub-requests, especially when the user gives:

• multiple resource types in one ask
• per-instance differences such as "first ..., second ..., third ..."
• different specs per instance
• mixed roles/components that should become separate CMP requests

Quantity by itself is not a decomposition signal. The request workflow and submit tool should interpret same-type quantity from the user's original language without requiring AtlasClaw core to pre-structure resource_count.

When this boundary is hit, do not continue with the single-catalog parameter collection flow in this skill.

Single-instance vs shared-quantity contract

This skill supports two request shapes, and they are not interchangeable:

• Single-instance request: one resource type, one instance, one resourceSpecs item, and no top-level count field unless the selected catalog explicitly requires one.
• Same-type multi-instance request: one resource type, one shared parameter set, one explicit quantity value from the selected catalog schema or fallback quantity, with resourceSpecs following the selected catalog schema.

For same-type multi-instance requests:

• Read the selected catalog instructions before choosing the quantity key. If an active field in instructions.topLevelFields or instructions.params clearly declares instance quantity, use that exact key and location. Do not choose from a fixed alias list.
• If the selected catalog does not declare a quantity/count field, use fallback top-level quantity.
• When the selected catalog has one instructions.resourceSpecs item, keep one shared resourceSpecs item for the shared parameter set.
• When the selected catalog declares multiple instructions.resourceSpecs items, build each declared item exactly once; do not treat the number of specs as the requested instance count.
• Do not duplicate identical resourceSpecs entries just to represent quantity N.
• Do not invent per-instance names, hostnames, IPs, disk sizes, or other per-instance overrides when the user asked for shared parameters.
• If the user supplies per-instance differences, separate names for each instance, or mixed component roles, stop using this skill and route to request-decomposition-agent.

Do not infer decomposition solely from resourceSpecs length. A single catalog can legitimately declare multiple resource specs. Decomposition is driven by user semantics, such as separate CMP requests or per-instance differences, not by a submit-script spec-count heuristic.

Submitted request status flow

Use smartcmp_get_request_status only for submitted request status or approval-result checks. Pass an explicit Request ID when present. For "刚才提交的 申请", reuse the most recent smartcmp_submit_request Request ID in this conversation; if none exists, ask for the Request ID. Request IDs are user-facing values such as REQ20260501000095, RES20260501000095, TIC20260316000001, or CHG20260413000011. Never pass UUID-shaped internal identifiers to the status tool.

The status script returns structured fields only. Treat the tool output as lookup data, not final user-facing text. Explain the result in the current user's message language using state, statusCategory, approvalPassed, currentStep, currentApprover, provisionState, error, and updatedAt.

Status semantics:

• APPROVAL_PENDING: not approved yet; approval is still pending.
• APPROVAL_REJECTED / APPROVAL_RETREATED: not approved; rejected or returned.
• STARTED / TASK_RUNNING / WAIT_EXECUTE / FINISHED: approval has passed or the request has entered later execution.
• INITIALING / INITIALING_FAILED / FAILED / CANCELED: report the current state as initialization, failure, or cancellation; do not claim approval or rejection.

Complete flow

1. Call smartcmp_list_services once. Auto-select a catalog only when the user's wording clearly matches one returned catalog; otherwise ask a numbered catalog-selection question.
2. Call smartcmp_get_request_catalog once with the selected catalog UUID to load only that catalog's generated request instructions.
3. Call smartcmp_list_available_bgs with the selected catalog UUID. If one business group is returned, use it. If multiple are returned, ask a concise numbered question using display names only and wait for the user's selection. Do not show business group IDs to the user.
4. Before asking for request fields, check the selected catalog metadata. If a ticket/work-order catalog (serviceCategory: "GENERIC_SERVICE") has instructions.genericRequest, build from that metadata. If a cloud/resource catalog has no instructions.resourceSpecs but its selected catalog metadata has type: "cloudchef.nodes.Compute", use the Compute fallback below. If it has no Markdown and is not Compute, stop and explain that the catalog is missing generated Markdown instructions.
5. Build the request from the selected catalog's generated Markdown metadata: instructions.resourceSpecs, instructions.genericRequest, and instructions.topLevelFields.
6. Ask only for active required fields with no default, plus fields explicitly marked ask: true. Defaults are used silently.
7. Show a JSON preview and ask for confirmation.
8. After the user confirms, call smartcmp_submit_request with the preview JSON.

Steps 1 through 3 are mandatory for every new request. Never ask the user to type a business group before calling smartcmp_list_available_bgs.

Catalog identity contract

• Displayed service list numbers are conversation choices only. Resolve them against the latest smartcmp_list_services result.
• Preserve each returned index when displaying a filtered subset; never renumber catalog choices in the assistant response.
• A catalog-selection question MUST show the exact returned index at the start of every option line, for example 3. LinuxOS. Never ask the user to reply with a number unless those numbers are visible in the response.
• catalogId must be the selected catalog metadata UUID, never the displayed list number and never sourceKey.
• After catalog selection, the next tool call must be smartcmp_get_request_catalog with that UUID. After the selected catalog detail returns, call smartcmp_list_available_bgs with the same UUID.
• There is no catalog questionnaire/default-property/preview tool in this skill. Do not invent one.

Tool sequencing

• One lookup tool call per turn.
• Mandatory catalog discovery is the exception: when the initial list has one clear automatic match, smartcmp_list_services may be followed by smartcmp_get_request_catalog and then smartcmp_list_available_bgs in the same user turn. When the user must choose a catalog, stop after the list and continue with detail plus business-group lookup after their selection.
• smartcmp_get_request_catalog is a schema-loading step, not a user-facing lookup. It may be followed by smartcmp_list_available_bgs in the same turn so catalog selection does not create an empty conversational round trip.
• After a lookup tool result, summarize the resolved result in natural language and ask at most one next question.
• Do not paste raw tool output, _internal metadata, UUID dumps, or JSON meta blocks into the reply.
• If the previous assistant message asked the user to choose a business group and the user replies with a bare number or group name, treat it as a business group selection, never as an unsupported operation.
• In a tool-required turn after a business group selection, call smartcmp_list_available_bgs again with the same selected catalog UUID to refresh the business group list, resolve the user's selection against that result, then continue with generated Markdown, Compute fallback, or the JSON preview.
• During request building, do not call datasource-only tools such as smartcmp_list_components, smartcmp_list_applications, or smartcmp_list_images. The selected catalog metadata and generated Markdown are the request contract.

User Response Language

• Use the current user's language for user-facing replies.
• Keep JSON keys, API fields, catalog names, provider names, and tool names unchanged.
• In Chinese user-facing text, always call SmartCMP resource pools 资源池. Never call them 资源包. Keep API field names such as resourceBundleId and resourceBundleTags unchanged inside JSON or code.

Generated Markdown Instructions

Catalog instructions is expected to be the Markdown generated by the Java catalog instruction builder. For request building, only these sections are in scope:

• # Request Parameter Instructions: YAML parameter contract.
• # Request Instructions: optional request-building guidance.

smartcmp_get_request_catalog exposes the selected catalog's parsed # Request Parameter Instructions YAML as metadata:

• instructions.topLevelFields
• instructions.topLevelRequired
• instructions.params
• instructions.genericRequest
• instructions.resourceSpecs
• instructions.requestInstructions from exactly # Request Instructions, when that section exists

Ignore old JSON instruction payloads. Do not use instructions.parameters or legacy raw params as the request schema. Use instructions.params only when it is parsed from # Request Parameter Instructions.

Instruction section boundary

The catalog Markdown body may contain multiple instruction sections, such as # Request Parameter Instructions, # Request Instructions, # Preapproval Instructions, or other future sections. For this request skill, only # Request Parameter Instructions and # Request Instructions are in scope.

• Read # Request Parameter Instructions first; it is the authoritative schema contract.
• The # Request Instructions section is optional. If it is absent, use # Request Parameter Instructions only.
• For free-form Markdown instructions, read only the content under exactly # Request Instructions.
• Stop reading request instructions at the next same-level heading that starts with # , such as # Preapproval Instructions.
• Never fall through to # Preapproval Instructions or any other section when # Request Instructions is missing.
• Ignore all other sections for request building. They must not change required fields, defaults, when behavior, resource tag handling, payload shape, or submit/preview behavior.
• A catalog body with only # Preapproval Instructions has no request-body instructions. It is still requestable only if # Request Parameter Instructions contains enough request schema metadata.

Markdown field rules

• Top-level JSON always includes catalogId, catalogName, businessGroupId, and name.
• For same-type multi-instance requests with shared parameters, fill the selected catalog's declared quantity field in its exact declared location. If none exists, use fallback top-level quantity. Keep resourceSpecs aligned to the selected catalog schema; for a single-spec catalog, use one shared resourceSpecs[] item.
• Quantity alone does not require decomposition; per-instance differences do.
• Generated field attributes belong in # Request Parameter Instructions, not in the # Request Instructions prose. Keep field metadata such as type, required, defaultValue, default_value, when, ask, label, description, source, lookup hints, and selectable values on the declared field itself.
• If an active field declares static options, use option id as the payload value and display option labels only as user-facing help.
• Do not add a second field-property list after body text such as "Do not invent fields that are not declared in # Request Parameter Instructions." Treat the body as generic request guidance only.
• If topLevelFields.name.ask: true and the user has not supplied a name, ask for the request/resource name. Do not auto-generate it.
• Do not include userLoginId; submit.py injects it.
• Put root request fields declared in instructions.params.<key> under the top-level JSON object params.<key>. These are catalog form fields from catalog.form_definition_id, not resource spec fields.
• Root instructions.params fields follow the same active-field rules as resource fields: evaluate when, use defaults silently, show static options, ask only for active required/no-default or ask: true fields, and omit inactive or empty optional fields.
• Do not put root instructions.params fields into resourceSpecs[].params. Do not put resourceSpecs[].params fields into the top-level params object.
• For ticket/work-order catalogs (serviceCategory: "GENERIC_SERVICE") with instructions.genericRequest, build a genericRequest object instead of resourceSpecs. Put instructions.genericRequest.description at genericRequest.description. Put fields declared under instructions.genericRequest.processForm.<key> at genericRequest.processForm.<key>. Follow the same active-field rules: evaluate when, use defaults silently, ask only for active required/no-default or ask: true fields, and omit inactive or empty optional fields.
• For each instructions.resourceSpecs[], create one resourceSpecs[] item and copy node and type exactly when present.
• Treat field schemas declared directly on instructions.resourceSpecs[], other than node, type, resourceBundleId, resourceBundleTags, resourceBundleParams, and params, as direct resource spec fields. Put each active value directly on the same resourceSpecs[] item as <key>. These fields are for special resources such as Compute/VM, where SmartCMP expects values like computeProfileId, flavorId, logicTemplateId, templateId, credentialUser, credentialPassword, networkId, securityGroupIds, or systemDisk at resourceSpecs[] level rather than under params.
• Preserve each direct field's declared type from Markdown. In particular, serialize Compute securityGroupIds as a JSON array of security group id strings, even when only one security group is selected; never serialize it as a single string or comma-separated string.
• Direct resource spec fields declared with type: "object" must be serialized as JSON objects at resourceSpecs[] level. For Compute systemDisk, preserve the object shape from Markdown or user input, for example "systemDisk": {"size": <disk size>}. Never serialize systemDisk as a raw number or string, and never move it under params.
• For direct Compute fields, use the exact field names declared by generated Markdown, such as computeProfileName, cpu, and memory. Do not replace them with alternate fields such as computeProfileId unless the selected catalog declares those alternate fields.
• Do not create or consume a literal fields object. Direct resource spec fields must be declared directly on instructions.resourceSpecs[].
• Put resourceBundleTags at the same level as resourceBundleId, resourceBundleParams, and params in Markdown. If it is active and has no defaultValue / default_value, call smartcmp_list_facets after business group selection with node_type from that spec's type, then ask the user to choose resource tags. Serialize selected values at resourceSpecs[].resourceBundleTags as ["<facet.key>:<option.key>"].
• resourceBundleTags and resourceBundleId are mutually exclusive for the same resourceSpecs[] item. If both are declared and active, use resourceBundleTags and omit both resourceBundleId and resourceBundleParams.
• If resourceBundleId.defaultValue exists and no active resourceBundleTags is used for that spec, put that value at resourceSpecs[].resourceBundleId.
• If an active resourceBundleId has no default and no active resourceBundleTags, call smartcmp_list_resource_bundles after business group selection and ask the user to choose one. Use the selected bundle id at resourceSpecs[].resourceBundleId.
• For smartcmp_list_resource_bundles, pass business_group_id from the selected business group, node_type from resourceSpecs[].type, and component_type from instructions.componentType / catalog component_type, falling back to catalog sourceKey only when generated Markdown does not declare it.
• Put resourceBundleParams.<key> values under resourceSpecs[].resourceBundleParams.<key>.
• resourceBundleParams is only for defaulted resource-pool placement fields declared there, such as available_zone_id and resource_group_id. Include those fields only when they already have a non-empty default value. Do not ask the user for missing resourceBundleParams; omit them instead. VPC, VSwitch, subnet, security group, and other network configuration fields must be under resourceSpecs[].params unless generated Markdown declares them directly on the resource spec, such as Compute networkId and securityGroupIds.
• Put params.<key> values under resourceSpecs[].params.<key>.
• External API lookup fields such as VPC, VSwitch, subnet, security group, and table-async selections, including direct Compute lookup fields, should appear in generated Markdown only when they already have a non-empty default. If old Markdown still declares one of these lookup fields without a default, omit it and do not ask the user for an internal id.
• Use defaultValue / default_value silently. Do not ask the user whether to modify a default.
• When an active field has static options, always show the option labels and ids as user-facing help when collecting remaining fields or showing the preview summary. This applies even when the field has a default. Do not ask a blocking question only for that defaulted field, but make alternatives clear so the user can override the default before confirmation.
• Format defaulted static options like: 地址类型: 默认 internet（公网）；可选：internet=公网，intranet=私网.
• Ask only when an active required field has no default, or when a field has ask: true, except missing resourceBundleParams values, which are omitted.
• Optional fields without a user value or non-empty default are omitted.
• Never serialize metadata keys such as type, required, defaultValue, default_value, when, source, label, ask, or options.

when rules

• Evaluate when before asking or serializing a field.
• If when is false, the field is inactive: do not ask for it and do not include its default.
• Evaluate from already resolved values in the same spec.
• Treat unquoted right-hand words as string literals: AddressType == intranet means AddressType == "intranet".
• Boolean values use true and false.
• If the user explicitly provides a value for a field with a default, use the user value and re-evaluate dependent when fields.

Request shape

{
  "catalogId": "<selected catalog UUID>",
  "catalogName": "<selected catalog name>",
  "businessGroupId": "<selected business group id>",
  "name": "<user-provided request name>",
  "quantity": 3,
  "resourceSpecs": [
    {
      "node": "<from instructions.resourceSpecs[].node>",
      "type": "<from instructions.resourceSpecs[].type>",
      "resourceBundleId": "<from resourceBundleId default or selected resource pool id>",
      "resourceBundleTags": ["<facet.key>:<option.key>"],
      "resourceBundleParams": {
        "<key>": "<active value>"
      },
      "<directResourceSpecKey>": "<active value>",
      "params": {
        "<key>": "<active value>"
      }
    }
  ],
  "params": {
    "<key>": "<active value from instructions.params>"
  }
}

Omit empty objects. Do not move resourceBundleId into either top-level params or resourceSpecs[].params, do not put declared resourceBundleParams fields inside any params, and do not put network fields inside resourceBundleParams. Never include resourceBundleId or resourceBundleParams when resourceBundleTags is used in the same spec. Do not serialize a fields wrapper. Serialize each active direct resource-spec field schema as resourceSpecs[].<key>. Same-type multi-instance requests must use the catalog-declared quantity field or fallback quantity; never duplicate identical resourceSpecs[] entries just to represent quantity. Catalogs that declare multiple resourceSpecs should include each declared item once. For Compute, securityGroupIds must be an array, for example "securityGroupIds": ["sg-xxxxxxxx"]. For Compute, systemDisk must be an object, for example "systemDisk": {"size": <disk size>}.

Ticket/work-order generated Markdown request shape:

{
  "catalogId": "<selected catalog UUID>",
  "catalogName": "<selected catalog name>",
  "businessGroupId": "<selected business group id>",
  "name": "<user-provided request name>",
  "genericRequest": {
    "description": "<active value from instructions.genericRequest.description>",
    "processForm": {
      "<key>": "<active value from instructions.genericRequest.processForm>"
    }
  }
}

Omit genericRequest.processForm when no form fields are declared or active.

Business-Group Resolution

• Use smartcmp_list_available_bgs as the authoritative source.
• If the user already specified a tenant / 租户 / 部门 / BU / 项目 and it uniquely matches an available business group, use that business group.
• If multiple groups remain, ask one concise numbered question with group names only. Do not display business group UUIDs.
• Use the selected business group's id as top-level businessGroupId.
• If a request name is still missing when asking for business group selection, ask for both in the same sentence, for example: 请回复业务组编号和资源名称，例如：2 slbtest01.

Service Selection

• Call smartcmp_list_services once at the start of a new request.
• Match user wording against the returned catalog name and service category.
• If the result contains zero catalogs, report that no matching published catalog exists and stop the request workflow.
• If multiple catalogs could match, ask a numbered catalog-selection question.
• When the user selects by number, resolve the number to the selected catalog metadata UUID, then call smartcmp_get_request_catalog with that UUID before any catalog-dependent lookup or request-field assembly.

Runtime Lookups

Use extra lookup tools only when generated Markdown requires or explicitly asks for a value that cannot be taken from the user or a default.

• smartcmp_list_facets: use only when generated Markdown declares an active resourceBundleTags field without a default. Pass node_type from resourceSpecs[].type. Build tag values as ["<facet.key>:<option.key>"] from the API response.
• smartcmp_list_resource_bundles: use only when generated Markdown declares an active resourceBundleId field without a default and no active resourceBundleTags field. Pass the selected business group id, component_type, and node_type. The tool applies fixed strategy=RB_POLICY_STATIC, enabled=true, and readOnly=false filters.
• smartcmp_list_flavors: use only when generated Markdown declares an active required compute-profile field without a default and the value must be chosen from SmartCMP flavor data, or when the selected catalog is a no-Markdown Compute fallback and the user provided a spec such as 2c4g.
• Do not call those tools for fields that already have active defaults.

Facet lookup result handling

After smartcmp_list_facets returns, treat the result as selectable resource tag data only:

• Do not call smartcmp_list_components or any other datasource tool to interpret facet results.
• Do not display raw facet records, id, aspects, createdBy, timestamps, lock versions, deleted flags, or JSON meta blocks.
• Use the compact FACET_META data from the tool result. The payload shape is [{ "key": "<facet key>", "label": "<display label>", "options": [{ "key": "<option key>", "label": "<display label>" }] }].
• If the user already supplied a tag/environment word, match it against facet option key or label. If exactly one option matches, use it.
• If exactly one active facet and one option are available, use that option.
• Otherwise ask one concise numbered question using display labels only, for example: 请选择资源环境：1. 开发 2. 测试 3. 生产.
• When asking the facet question, stop and wait for the user's answer. Do not show a JSON preview in the same reply.
• Store selected tags only as "<facet.key>:<option.key>" strings in resourceSpecs[].resourceBundleTags.

Missing Markdown

If a cloud/resource catalog has no instructions.resourceSpecs, use Compute fallback only when the selected catalog metadata explicitly has type: "cloudchef.nodes.Compute". For other cloud/resource catalogs, do not guess provider-specific request fields and do not submit. Explain that the catalog is missing generated Markdown instructions.

Compute fallback

This fallback keeps legacy Linux VM / Windows VM catalogs usable while newer cloud component catalogs use generated Markdown.

Use Compute fallback only when all of these are true:

• The selected catalog has no instructions.resourceSpecs.
• The selected catalog metadata has type: "cloudchef.nodes.Compute".
• Business group has already been resolved through smartcmp_list_available_bgs.

Compute fallback sequence:

1. Ask for missing request name and description, plus VM login user/password if they were not provided. Mask credentialPassword in previews.
2. Call smartcmp_list_facets with the selected businessGroupId to choose resource pool tags. Use returned facet.key and option key, not display labels.
3. Call smartcmp_list_flavors when the user supplied a spec such as 2c4g, or ask the user to choose a flavor if no unambiguous match exists. Use the flavor id as computeProfileId.
4. Build one resourceSpecs[] item using selected catalog node and type when present.

Compute fallback JSON shape:

{
  "catalogId": "<selected catalog UUID>",
  "catalogName": "<selected catalog name>",
  "businessGroupId": "<selected business group id>",
  "name": "<user-provided request name>",
  "description": "<user-provided request description>",
  "resourceSpecs": [
    {
      "node": "<selected catalog node, when present>",
      "type": "cloudchef.nodes.Compute",
      "resourceBundleTags": ["<facet.key>:<option.key>"],
      "computeProfileId": "<flavor id>",
      "credentialUser": "<user-provided login user>",
      "credentialPassword": "<user-provided login password>"
    }
  ]
}

For ticket/work-order catalogs (serviceCategory: "GENERIC_SERVICE") without generated instructions.genericRequest Markdown, submit only this minimal shape after collecting name and description:

{
  "catalogId": "<selected catalog UUID>",
  "catalogName": "<selected catalog name>",
  "businessGroupId": "<selected business group id>",
  "name": "<user-provided request name>",
  "genericRequest": {
    "description": "<user-provided description>"
  }
}

Submit Contract

Before submit:

1. Show a short summary in the user's language.
2. Show JSON 预览 / JSON Preview with a fenced JSON block.
3. Mask credentialPassword as "******".
4. Ask the user to confirm.
5. Stop. Do not call smartcmp_submit_request until the user confirms.

After confirmation:

• User says yes → call smartcmp_submit_request with json_body.
• User says no → ask what to change.
• Any field added or changed after a preview or failed submission changes the request payload and invalidates every earlier confirmation. Show the updated summary and JSON preview, then ask for fresh confirmation before the next submit attempt.
• A bare number is a selection for the latest displayed list unless the immediately previous assistant message displayed a JSON preview and asked for confirmation.

Interaction Rules

• smartcmp_list_services at most once per request conversation.
• smartcmp_get_request_catalog once after catalog selection and before catalog-dependent lookups or request-field assembly.
• smartcmp_list_available_bgs is normally called once after catalog selection. It may be called one extra time only to resolve a user's business group selection in a tool-required turn.
• Never claim submitted unless smartcmp_submit_request actually executed.
• Never display raw internal metadata to the user.