main

name: jayrat description: Manage Jira with the jrc CLI. Use for reading, creating, editing, transitioning, assigning, commenting on, linking, cloning, watching, voting on, or deleting issues; attachments, projects, boards, sprints, users, releases, automation rules, bulk transitions, custom fields, server diagnostics, and raw Jira API requests.

Jayrat Jira workflows

Use jrc as the sole Jira interface. Do not extract credentials or call Jira with another HTTP client.

Establish capabilities

  1. Confirm that jrc is on PATH.
  2. Run jrc version --output json when available.
  3. Inspect every command before constructing it:
jrc describe commands <command> <subcommand>

For commands exposing --fields, inspect the supported output names with jrc describe fields <command> <subcommand>. The bare describe fields command lists the registered field-filtering commands; other command paths correctly have no field schema.

Treat the active schema as authoritative. If a documented flag is unavailable, do not invent it; use an available safe workflow or tell the user that jrc must be upgraded.

Safety contract

  • Run every Jira mutation with --dry-run first and inspect the complete structured payload.
  • Treat a clear user request as authority to apply the matching mutation after a successful dry-run. Ask only when scope, target, or destructive impact is ambiguous.
  • Pass mandatory --confirm flags only when the user’s request clearly covers that destructive or bulk action.
  • Never use jrc config dump --show-token. Filter ordinary config dumps to the minimum required fields.
  • Use --description-file, --body-file, or --data-file for multiline or shell-sensitive input. Use - for stdin when appropriate.
  • Use only relative paths or same-origin absolute URLs with jrc api. Reject cross-origin requests.
  • Use --output json and jq for scripting. Do not parse human text.

Resolve context before writing

Read only the needed defaults:

jrc config dump --output json | jq '{jira_project, create_defaults, custom_fields}'

Discover project-specific values rather than guessing:

jrc project issue-types --project PROJ --output json
jrc project create-metadata --project PROJ --issue-type Bug --output json
jrc project components --project PROJ --output json
jrc project priorities --project PROJ --output json
jrc user list --query 'Ada' --output json

Use configured description templates and defaults unless the user overrides them. Use Markdown, never Jira wiki markup. Do not assume that every Epic needs an Epic Name; follow create metadata and configured custom fields.

Core workflow

For reads, execute directly. For writes, construct one set of arguments, run it with --dry-run, inspect it, then rerun the same arguments without --dry-run.

Create due dates, parents, and fix versions in the initial request when the active schema supports them:

jrc issue create --project PROJ --summary 'Concise title' \
  --issue-type Bug --description-file /tmp/description.md \
  --due-date 2026-08-01 --parent PROJ-10 --fix-version v1.2.0 \
  --dry-run --output json

Report structured results, including the issue key and URL returned by jrc. If a mutation partially succeeds, report the created or changed resource and the failed follow-up precisely; do not silently retry with weaker fields.

Load task-specific guidance

  • Read issues.md for issue reads, creation, editing, transitions, comments, assignment, watchers, votes, and cloning.
  • Read links-and-attachments.md for relationships, children, watchers, and attachment workflows.
  • Read projects-releases-automation.md for projects, boards, sprints, users, releases, automation, server info, and completions.
  • Read bulk-and-api.md for immutable bulk plans and raw REST escape-hatch rules.