lisa-jira-build-intake

JIRA Build Intake: $ARGUMENTS

All Atlassian operations in this skill go through lisa-atlassian-access. Do not call MCP tools or acli directly.

$ARGUMENTS is one of:

1. A JIRA project key (e.g. SE) — scans that project for tickets in the configured ready status.
2. A full JQL filter (e.g. project = SE AND component = "frontend" AND Status = Ready) — used as-is. The skill will not append a Status = <ready> clause if the JQL already names a status, so callers can intentionally widen. It also auto-scopes the query to the current repo (Phase 1 step 2) unless the JQL already constrains repo (a repo: label or component = term), so a multi-repo project / forwarded assignee filter is not widened to sibling repos by accident.

Run one build-intake cycle. The first eligible ready ticket is claimed, built via the lisa-jira-agent flow, transitioned to the configured done status (env-aware — see below), then the cycle exits. Remaining ready tickets stay queued for later scheduler invocations.

Workflow resolution

Status names are read from .lisa.config.json jira.workflow.*, falling back to defaults documented in the config-resolution rule. Bash pattern:

# Read role with default fallback. Local overrides global per-key.
read_role() {
  local role="$1" default="$2"
  local local_v global_v
  local_v=$(jq -r ".jira.workflow.${role} // empty" .lisa.config.local.json 2>/dev/null)
  global_v=$(jq -r ".jira.workflow.${role} // empty" .lisa.config.json 2>/dev/null)
  echo "${local_v:-${global_v:-$default}}"
}

READY=$(read_role ready "Ready")
CLAIMED=$(read_role claimed "In Progress")

For env-keyed done, resolve the env first, then look up done[<env>]:

1. Explicit caller arg (target_env=staging) wins.
2. Otherwise, infer the env from the PR's base branch via deploy.branches (reverse lookup: if base is staging, env is staging).
3. If done in config is a string (not a map), use it directly regardless of env.
4. If done is a map and env cannot be resolved, fail loudly — do not pick arbitrarily.

# Resolve env, then DONE.
TARGET_ENV="${target_env:-}"  # from caller args if supplied
if [ -z "$TARGET_ENV" ] && [ -n "$PR_BASE_BRANCH" ]; then
  TARGET_ENV=$(jq -r --arg b "$PR_BASE_BRANCH" \
    '.deploy.branches // {} | to_entries[] | select(.value == $b) | .key' \
    .lisa.config.json 2>/dev/null | head -1)
fi

DONE_RAW=$(jq -r '.jira.workflow.done // empty' .lisa.config.json 2>/dev/null)
DONE_TYPE=$(jq -r '.jira.workflow.done | type' .lisa.config.json 2>/dev/null)
if [ "$DONE_TYPE" = "string" ]; then
  DONE="$DONE_RAW"
elif [ "$DONE_TYPE" = "object" ]; then
  [ -z "$TARGET_ENV" ] && { echo "ERROR: jira.workflow.done is env-keyed but env not resolvable"; exit 1; }
  DONE=$(jq -r --arg e "$TARGET_ENV" '.jira.workflow.done[$e] // empty' .lisa.config.json)
  [ -z "$DONE" ] && { echo "ERROR: jira.workflow.done has no entry for env '$TARGET_ENV'"; exit 1; }
else
  # Default: env-keyed map matching legacy hardcoded names.
  case "$TARGET_ENV" in
    dev) DONE="On Dev" ;;
    staging) DONE="On Stg" ;;
    production) DONE="Done" ;;
    *) echo "ERROR: cannot resolve done status without env"; exit 1 ;;
  esac
fi

Run one build-intake cycle. The first eligible ticket in $READY is claimed by transitioning to $CLAIMED, built via the lisa-jira-agent flow, transitioned to $DONE on completion, then the cycle exits.

Confirmation policy

Do NOT ask the caller whether to proceed. Once invoked with a project key or JQL, run the cycle to completion — claim and dispatch the first eligible ticket through lisa-jira-agent, transition a successful build to $DONE, write the summary, and exit. The caller (a human or a cron) has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background queue.

Specifically forbidden:

• Previewing projected scope (ticket count, projected PR count, build duration) and asking whether to continue.
• Offering A/B/C-style choices like "proceed / skip a few / dry-run only" — the documented behavior IS the default.
• Pausing because the queue is large, tickets look complex, or tickets are likely to be Blocked by lisa-jira-agent's pre-flight gate. The pre-flight Blocked outcome is a valid terminal state of the per-ticket lifecycle (owned by lisa-jira-agent), not a failure mode — surfacing those tickets to humans is success.
• Pausing because the build flow looks expensive. The cost of one cycle is bounded; the cost of stalling a scheduled cron waiting on a human is unbounded.

The only legitimate reasons to stop early:

• Missing project key / JQL or required configuration. Surface the missing value and exit.
• Workflow misconfigured (pre-flight check finds $CLAIMED or $DONE not reachable, or $READY status absent). Surface and exit.
• Empty ready set. Exit cleanly with "No tickets with Status=$READY. Nothing to do."

Lifecycle assumed

The JIRA workflow has these statuses (configured per project — see Workflow resolution above for how role names map to actual workflow values):

TODO → ready → claimed → done(env-keyed) → On QA → archive
       (PM/    (us claim)  (us done;        (downstream)
        human)              PR ready)

This skill ONLY transitions $READY → $CLAIMED on claim, and $CLAIMED → $DONE on completion. It never touches TODO, post-done statuses, or any blocked/closed states.

Pre-flight check: at start of each cycle, attempt the $CLAIMED and $DONE transitions against a sample ready ticket via lisa-atlassian-access operation: transition key: <K> to: "<status>" (in a probe / dry-run sense — or fetch transition metadata if the access skill exposes that). If the transitions are unreachable, stop and report the workflow misconfiguration to the caller — do not invent transitions.

Phases

Phase 1 — Resolve the query

1. Parse $ARGUMENTS into a base JQL:
   • Project key: project = <KEY> AND Status = "$READY".
   • Full JQL: use as-is. If it does not include a Status clause, append AND Status = "$READY".
2. Repo-scope pre-filter (query-time arm of repo-scope-split). A JIRA project can oversee multiple repos (frontend / backend / infrastructure), so an unscoped project = <KEY> AND Status = $READY — or an assignee = … AND Status = $READY filter forwarded by lisa-intake — pulls in every sibling repo's ready tickets and forces the claim-time gate (3a.0) to skip them one-by-one: a full wasted scan when none belong to the current repo. Narrow the candidate set at query time so other-repo tickets never enter it:
   1. Resolve the current repo per config-resolution "Repo scoping" (.repo → .github.repo → git remote get-url origin basename) — the same resolution 3a.0 uses.
   2. If the base JQL already constrains repo — it contains a repo: label term or a component = "<repo>" term — the caller has already scoped (or intentionally widened) it; leave it untouched.
   3. Else, if the current repo resolved, append (before the ORDER BY):

      AND (labels = "repo:<current>" OR labels IS EMPTY)
      

      This drops tickets explicitly stamped for a sibling repo up front, while still surfacing unlabeled tickets (labels IS EMPTY) so the claim-time gate can determine + stamp them — i.e. it pre-applies only the unambiguous "wrong-repo → skip" arm of 3a.0 and never hides work the stamping path must see. The JIRA component alias and any rarer residual cases stay with the authoritative claim-time gate in 3a.0.
   4. If the current repo cannot be resolved, skip this augmentation and fall back to the broad scan (3a.0 still enforces scoping). Do not fail the cycle solely because the pre-filter could not be built.
3. Append the ordering: ORDER BY priority DESC, created ASC.

# CURRENT_REPO resolved per config-resolution "Repo scoping" (see 3a.0).
# Append a repo pre-filter only when the JQL does not already constrain repo.
if [ -n "$CURRENT_REPO" ] && ! printf '%s' "$BASE_JQL" | grep -qiE 'repo:|component[[:space:]]*='; then
  BASE_JQL="${BASE_JQL} AND (labels = \"repo:${CURRENT_REPO}\" OR labels IS EMPTY)"
fi
JQL="${BASE_JQL} ORDER BY priority DESC, created ASC"

4. Confirm the configured Atlassian site by invoking lisa-atlassian-access operation: list-sites (it enforces connection match against .lisa.config.json).

Phase 2 — Find ready tickets

Invoke lisa-atlassian-access operation: search-issues jql: "<JQL>". Capture each ticket's: key, summary, issue type, priority, assignee, parent (epic), labels, components.

If empty, report "No tickets with Status=$READY. Nothing to do." and exit. This is the common idle case.

Phase 3 — Process the first eligible ready ticket

3a.0 Repo-scope gate (claim only current-repo tickets)

A JIRA project can oversee multiple repos (frontend / backend / infrastructure). This skill claims only tickets for the repo it is running in. Run this gate before the leaf-only gate (3a) and the claim (3b), per the repo-scope-split rule's "Claim-time repo scoping" section (cite it by slug; do not restate its decision table).

1. Resolve the current repo per config-resolution "Repo scoping" (.repo → .github.repo → git remote get-url origin basename). If unresolvable, stop and report — do not claim tickets you cannot scope.
2. Cheap path first. Phase 1's query-time pre-filter has already dropped tickets explicitly stamped for a sibling repo, so the Phase 2 result set is current-repo-labeled + unlabeled tickets. Prefer candidates already carrying repo:<current> — a JIRA label, or a component equal to the repo name (accepted as an alias); the pre-filter is label-only, so a ticket scoped solely by a sibling-repo component can still appear and is skipped here. The result set still includes unlabeled tickets so they can be determined and stamped; this gate orders/fi

Content truncated.