Jira team status

Skill: jira-team-status

A read-only status view of a team's Jira work. It answers where the team's work stands and what to pick up next — organized by the dimensions people actually ask about: Ready to pull, In progress, Blocked, Unassigned, and Needs detail, plus a recently-changed note. Then it offers a pick-up hand-off so a team member can start delivery on a ready item.

Read-only by default. This skill does not judge item quality in depth or rewrite weak stories — that is jira-story-triage. When the user wants to fix a weak item (draft acceptance criteria, clarify the outcome), this skill routes them to jira-story-triage by name. Its only write is a bare pass-through to the jira skill's update-issue when the user explicitly asks to set a field, with the payload confirmed first.

Cross-skill invocation — name, not path

Sibling and host skills are named by their name: field, never by path. When this skill says "route to jira-story-triage", the agent dispatches the skill registered under that name. If the skill is absent, the agent surfaces an install hint rather than stopping.

Prerequisites

jira is installed and authenticated — a hard dependency. Invoke: jira: check.

• Exit 0 → proceed.
• Exit 2 → tell the user to run credential-setup themselves and stop.

The "ready to pull" rule

"Ready to pull" is a defined rule, not a silent status = "To Do". An item is ready to pull when all four hold:

1. In the selected team scope — the project(s), board, sprint, or team field the user asked about.
2. In an eligible backlog state — default: Jira statusCategory = "To Do" (the stable category that spans Backlog / To Do / Selected for Development / Open across any instance). This deliberately excludes work already In Progress or Done. Teams override the eligible statuses/fields — name explicit statuses (e.g. "Ready for Dev") and this rule uses them instead of the default.
3. No known unresolved blocker — see the blocker signal.
4. Meets the team's story-readiness bar — the five-question readiness bar below.

When any clause cannot be determined for an item — the status doesn't map cleanly, the blocker state is unreadable, or readiness is ambiguous — the item is labelled needs confirmation. The skill never asserts an item is ready (or not ready) on a signal it could not read.

The five-question readiness bar

A story is actionable when all five are true: (Q1) it is a self-contained code/config/doc change — not discovery, design, or coordination work; (Q2) it names a reachable repo or file scope so the change can be located without a follow-up meeting; (Q3) its acceptance criteria are checkable by diff review alone — no "TBD", "coordinate with", "decide on", or "prototype"; (Q4) no human decision is needed mid-flight — no open design question, no external approval gate that cannot be confirmed before work starts; (Q5) it is right-sized for one PR — the scope is an enumerable set of files or PRs a single person or agent can produce without decomposing into sub-stories.

Q5 exists because Jira stories are a legacy delivery-capacity allocation mechanism: a story sized for a full sprint passes Q1–Q4 but cannot be handed to a single agent or engineer without decomposition.

The blocker signal

An item counts as Blocked when any of these is true:

• its Flagged / impediment field is set;
• it has an unresolved outward "is blocked by" issuelink;
• its status is in a team-declared blocked set (none by default).

When none of the three can be read from the fetched fields, the blocker state is undeterminable → the item is needs confirmation, not asserted blocked or unblocked.

Lifecycle

Stage 1 — Repo grounding

Detect git remote -v in the working directory. If a URL is found, label it Invocation repo: <URL> — the repo the agent is running from.

If not in a git repo, offer:

"Optionally supply a repo URL or name — this improves story scope verification. Enter to skip."

Proceed with "Invocation repo: unknown" if the user declines.

Stage 2 — Intake

Ask only for what's missing to set scope; don't over-elicit. Accept:

• A Jira project key (or several, across projects).
• An optional sprint (default: sprint in openSprints()), a team name, or a JQL filter to narrow.
• Whole-backlog scope: when the user asks for the entire backlog ("show me the entire ATLAS backlog"), drop the sprint in openSprints() default and query the project's open backlog (statusCategory != Done), not just the current sprint.

Fetch the fields the status dimensions need — status (and its category), assignee, last-updated, blocker signals — in one call:

jira: search "project = PROJ AND sprint in openSprints() AND statusCategory != Done"
      --fields "summary,description,issuetype,status,statusCategory,assignee,updated,priority,labels,issuelinks,customfield_*"
      --limit 100

customfield_* captures story points and the Flagged/impediment field (names vary by instance). Disclose coverage: if the result is truncated at --limit, say so and report the total.

Stage 3 — Classify each item into a status dimension

Assign each item to exactly one primary dimension, by this precedence:

1. Blocked — the blocker signal is present.
2. In progress — statusCategory = "In Progress" (and not blocked).
3. Needs detail — in an eligible backlog state but either unscoreable (empty / image-only / discovery issuetype) or it fails the readiness bar on content (Q1/Q2/Q3, or Q5 too-large, or Q4 open design question). This is the coarse "needs product attention" bucket; jira-story-triage is the tool that breaks down why per item and fixes it.
4. Ready to pull — satisfies the ready-to-pull rule (eligible state + no blocker + passes the bar).

Undeterminable clauses never default an item into Ready to pull. Route explicitly:

• Blocker clause undeterminable (Flagged field / issuelinks not readable) → surface in §3 Blocked, tagged needs confirmation.
• A readiness-bar clause undeterminable (content ambiguous) → surface in §5 Needs detail, tagged needs confirmation.
• Status doesn't map to a known category → surface in §5 Needs detail, tagged needs confirmation.

An item reaches §1 Ready to pull only when all four ready-to-pull clauses are affirmatively true — never when one is merely not known to be false.

Cross-cutting views (an item may appear here and in its primary dimension):

• Unassigned — every in-scope item with no assignee. (Ready-to-pull items are expected to be unassigned; the value is spotting in-progress or stuck items nobody owns.)
• Recently changed — items whose updated falls within the window (sprint start, or the last 7 days for a backlog scope), most-recent first — answers "what changed?".
• Stale — a ⚠ stale marker on any In-progress or Ready item whose updated is older than the staleness threshold (default 14 days; team-overridable).

Stage 4 — Complexity (Ready-to-pull items only)

Signal	Quick	Standard	Involved
Story-point field	≤ 2 pts	3–5 pts	> 5 pts
Description length (fallback)	≤ 100 words	101–200 words	> 200 words
AC count (secondary fallback)	≤ 2 ACs	3–5 ACs	> 5 ACs

Stage 5 — Output: the status snapshot

Emit these sections in order, always. If a section has no items, include its header with "None in this scope."

---

§1 — Ready to pull — grouped by complexity

Items that satisfy the ready-to-pull rule. Grouped Quick, then Standard, then Involved, so team members self-select by bandwidth.

Table columns: Key | Summary | Priority | Complexity | Updated (⚠ if stale) | Invocation repo match?

"Invocation repo match?" is Yes if Q2 found the invocation repo URL or name in the item's description, Unknown otherwise. The Updated column carries the ⚠ stale marker for a ready item untouched past the staleness threshold. Mark any needs confirmation items explicitly.

Batching note (optional): if two or more ready items have distinct repo scopes and no stated dependency between them, add: "Can run concurrently: PROJ-101, PROJ-103."

---

§2 — In progress

Table columns: Key | Summary | Assignee | Updated (⚠ if stale)

---

§3 — Blocked

Table columns: Key | Summary | Blocker (which signal) | Owner hint

---

§4 — Unassigned

Every in-scope item with no assignee. Table columns: Key | Summary | Primary dimension | Status

---

§5 — Needs detail (product attention)

Backlog items that are not ready — unscoreable or failing the bar on content. Table columns: Key | Summary | What's missing (coarse) | Fix with

The "Fix with" cell points to jira-story-triage for the item-by-item reasons and a draft fix.

---

Recently changed: a compact list — PROJ-108 (2h ago), PROJ-101 (yesterday), … — top items by updated. Omit if the scope has no recent changes.

Summary line:

Team status: <total> items.  Ready to pull: <r> (Quick <q> / Std <s> / Inv <i>).
In progress: <p>.  Blocked: <b>.  Unassigned: <u>.  Needs detail: <d>.  Stale: <st>.
Scope: <JQL>.  Coverage: <all N | truncated at limit — total M>.  Invocation repo: <URL or unknown>.

Stage 6 — Pick-up hand-off (read-only)

After the snapshot, offer a pick-up. Read-only routing — this skill starts no rewrite of its own.

Option A — Start delivery (if §1 has items):

"Ready to start delivery? Suggested: <highest-priority Quick item> — <one-line summary>. [yes / pick another / skip]"

• yes → issuetype is Bug/Defect? Route to jira-defect-flow by name. Otherwise offer to open a new-spec session scoped to this item. (Surface an install hint if the target skill is absent.)
• pick another → list §1 items by complexity group; user picks.
• skip → end gracefully.

Option B — Improve an item that needs detail (if §5 has items):

"Want to make a not-ready item actionable — draft acceptance criteria, clarify the outcome? Suggested: <highest-priority §5 item>. [yes / pick another / skip]"

• yes → route to jira-story-triage by name, scoped to that item (it explains the reason and drafts the fix with write-after-approval). Surface an install hint if jira-story-triage is absent; in the meantime give the item key.
• pick another / skip → behave as above.

Explicit update escape hatch. If the user explicitly asks to set a specific field on a specific item ("set PROJ-101's priority to High"), this skill may make a bare pass-through to jira: update-issue — show the exact payload, get a yes, then write. It never runs a multi-step collaborative rewrite; that is jira-story-triage's job.

If the user declines both options, end gracefully with a note of what they could do next.

Don't

• Don't rewrite or improve a story's content here — route improvement to jira-story-triage. This skill is a read-only status view plus routing.
• Don't run a multi-step collaborative rewrite or draft acceptance criteria yourself; the only write is the confirmed bare pass-through update-issue in stage 6.
• Don't assert an item is ready, blocked, or not — or hide uncertainty — when the signal can't be read. Label it needs confirmation.
• Don't conflate this skill with the local workspace-queue / session-orientation skill. This skill is Jira-only; it reads external Jira project data.
• Don't read or write any local project state; this skill is Jira-only.
• Don't invoke jira-story-triage, jira-defect-flow, or new-spec without checking whether they are installed (by-name dispatch probe); surface an install hint if absent.
• Don't hardcode a sibling skill by path; invoke by name.

Edge cases

• No ready-to-pull items (§1 empty). Still emit §2–§5. Pick-up offers only Option B (improve a §5 item). Note: "No items ready to pull in this scope — the fastest path is to make a §5 item actionable (jira-story-triage)."
• Everything is ready to pull. Emit §1 with full complexity grouping and offer the delivery pick-up directly; other sections show "None in this scope."
• Blocker signal unreadable. If the Flagged field and issuelinks aren't in the response, note "blocker state unverified for this scope" and mark affected items needs confirmation rather than assuming unblocked.
• jira-story-triage / jira-defect-flow / new-spec absent. Route by name; harness reports it absent; surface: "Install the <pack> pack to enable this hand-off. In the meantime, here is the item key: <KEY>."
• Truncated result. Always disclose in the summary's Coverage field; offer to narrow scope or paginate.

Examples

See references/examples.md.