---

name: jira-service-project-issue-intake description: "Create a structured Jira issue in a service project after reviewing the request-type field requirements."

Jira Service Project Issue Intake

Create a structured Jira issue in a service project after reviewing the request-type field requirements.

Required Aident Actions

• <action-tag>composio:jira_tools:jira_get_service_desk_request_type_fields</action-tag> (required inputs: serviceDeskId, requestTypeId): Tool to retrieve JSM request type field metadata for filling out portal requests. Use when you need to know which fields are required and their valid values.
• <action-tag>composio:jira_tools:jira_get_create_metadata_issue_type_fields</action-tag> (required inputs: projectIdOrKey, issueTypeId): Tool to retrieve field metadata for a specific issue type in a project. Use this to discover required fields, allowed values, and field configurations before creating issues of a specific type.
• <action-tag>composio:jira_tools:jira_create_issue</action-tag> (required inputs: projectAction · Get Service Desk Request Type Fieldscified project. IMPORTANT: Different Jira projects may have custom required fields beyond the standard ones (summary, project_key, issue_type). If issue...

Use Aident Loadout to read the current Action schema Action · Get Create Metadata Issue Type FieldsIf an Action is billable or mutating, run Aident preflight, show the affected target and quoted cost or risk, and wait for explicit user confirmation before execution.

Workflow

1. Confirm the requested outcome, source material, destination,Action · Create Issuesource-derived guidance below to create a concrete plan. Resolve ambiguity before invoking an Action.
2. Select only the Aident Actions whose documented effect directly advances the requested outcome. Do not invoke every listed Action by default.
3. Inspect the current schema and prepare the minimum valid input for each selected Action.
4. Preflight each selected Action. Execute it only after any required confirmation, in dependency order, and carry returned IDs or asset URLs into later steps.
5. Verify the returned IDs, URLs, statuses, or artifacts against the acceptance criteria. Report partial completion precisely and do not repeat paid or mutating calls blindly.

Source-Derived Guidance

• Resolve the exact service project and request type, inspect its request fields, and inspect the generic Jira create metadata for the selected issue type.
• Map the supplied request details to a generic Jira issue payload and show every field before creation.
• Use composio:jira_tools:jira_create_issue only after confirmation and verify the returned issue key.
• Do not claim that this creates a customer-portal request or applies JSM customer, SLA, approval, or portal behavior.

Execution Boundaries

• Treat upstream provider-specific commands as background knowledge only. Execute the workflow through the exact Aident Actions above.
• Never request raw credentials in chat. Use Aident Vault connection flows for required accounts.
• Preserve user-provided wording, brand constraints, rights restrictions, and target identifiers. Do not invent authorization.
• Read current state before a mutation, state the exact target, and include a rollback or recovery step in the result.
• Stop when a required integration is disconnected, preflight rejects the input, the target is ambiguous, or the user declines a required confirmation.

Output

Return the execution plan, selected Action names, confirmed targets, Aident result identifiers or asset URLs, verification evidence, and any remaining blocked step.

Attribution

This Skill adapts the reviewed upstream workflow. See UPSTREAM.md for the pinned source and LICENSE.txt for the preserved license.