Jira Create Issue

Jira: Create Issue

Write, gated. Run from this skill's directory:

python3 ../jira/scripts/jira_tool.py create_issue --project PAYKAN --summary "Fix checkout crash" \
  --issue_type Bug --confirm

Creating a subtask under an existing parent -- same tool, add --parent_key and use --issue_type Sub-task:

python3 ../jira/scripts/jira_tool.py create_issue --project PAYKAN --summary "Build checkout UI" \
  --issue_type Sub-task --parent_key PAYKAN-100 --labels Frontend --confirm

(First-time setup, once per environment: pip install -r ../jira/requirements.txt.)

--project, --summary, and --issue_type are required. --issue_type Sub-task requires --parent_key. Optional: --description, --labels (comma-separated), --assignee_account_id, --priority, --components (comma-separated), --custom_fields (a JSON object of customfield_NNNNN -> value for any field this project's create screen requires beyond the flags above -- resolve ids/shapes via python3 ../jira/scripts/jira_tool.py list_fields first, never guess either).

Check for a remembered convention first

Before treating a create request as a single action, check whether the user has told you to remember a standing convention for issue creation on this project (e.g. "every task also gets a specific kind of subtask" or "issues of a certain type always get a certain label"). This tool has no opinion of its own about team process -- never invent or assume a convention, only apply one the user actually asked you to remember. If one applies, state the whole resulting set of creates (parent, then its convention subtask, etc.) before running anything, rather than creating only the literal issue asked and leaving the rest unspoken. See ../jira/README.md's "Agent memory" section for how these conventions differ from the Jira-side facts the rest of this toolset caches.

Assignee

--assignee_account_id needs a Jira account_id, not a display name -- resolve one via jira-search-users first (e.g. search_users --query john) rather than guessing.

Also requires JIRA_DEPLOYMENT_TYPE (cloud or server) to be set: Jira Cloud identifies users by accountId, Server/Data Center by username, and the tool won't guess which one this instance is. If the result is an "error" naming JIRA_DEPLOYMENT_TYPE, tell the user to set that environment variable once -- it isn't something to retry around.

Confirmation

This refuses to execute unless run with --confirm (enforced in code, not just prompted). Unless JIRA_AUTO_CONFIRM_WRITES=true is set:

1. State exactly what you're about to create (project, summary, type, and parent if it's a subtask) and wait for the user's explicit yes.
2. Only then re-run the same command with --confirm appended.
3. If the result has "requires_confirmation": true, treat that as the tool declining to act -- relay pending_action to the user and ask, don't retry with --confirm on your own.

If the result contains "error", relay the tool's actual error text to the user instead of retrying silently or guessing a cause -- e.g. a project without subtasks enabled rejects --issue_type Sub-task with a specific Jira error naming the problem; quote it. If a subtask create fails, do not fall back to creating a regular (non-subtask) issue as a substitute without asking first -- that produces an unrequested duplicate of the parent instead of what the user actually asked for. Tell the user the subtask failed and why, then let them choose (retry after fixing the project's issue-type config, or explicitly agree to a regular linked issue instead) before running anything.

See ../jira/README.md for architecture details and the full environment-variable table.