Collecting data for Trust at Work

You work with our Jira via MCP. Task: collect the list of features that were
built together with team "{TEAM NAME}" and are already implemented/closed
(shipped to production), within the period {DATE FROM — DATE TO}.

Project(s): {PROJECT KEY, e.g. TMS}

IMPORTANT: do not guess the Jira schema — discover it first, then filter.

Step 0. Schema discovery (mandatory, before any queries):
- Determine the cloudId / accessible projects.
- Find out which issue types exist in the project and which of them we use for
  features (Story, Improvement, Epic, New Feature, Feature, Task — the set
  differs per team). Do not rely on a single type.
- Find out the actual workflow statuses and the values of the resolution field
  in this project. "Done / on prod" is named differently everywhere: Done,
  Released, Closed, Resolved, Shipped — and it may be expressed via resolution
  rather than status. Pick values that actually exist.
- Determine how "together with team X" is expressed in our Jira: it could be a
  Team field, a component, a label, an epic/parent, an assignee from the team's
  members, or a separate project. Ask me if it's ambiguous.

Step 1. Build JQL against the discovered schema. Template (adapt it):
  project = {PROJ}
  AND issuetype in ({FEATURE_TYPES})
  AND (status in ({DONE_STATUSES}) OR resolution in ({DONE_RESOLUTIONS}))
  AND ({TEAM_FILTER})
  AND resolved >= "{DATE FROM}" AND resolved <= "{DATE TO}"
  ORDER BY resolved DESC
(if "shipped to prod" = a transition into a specific status, use
 status CHANGED TO ({STATUS}) DURING ("{DATE FROM}","{DATE TO}") instead.)

Step 2. Fetch ALL results with pagination (don't stop at the first page).
Request only the fields you need: key, summary, issuetype, status, resolution,
resolved, team/component/labels.

Step 3. Before showing the final result:
- show which schema you chose (types, statuses/resolution, team filter, why)
  so I can correct it;
- if something doesn't exist (e.g. there is no "Resolved" status) — don't stay
  silent and don't return emptiness as a fact; say so and propose the closest
  correct option.

Output: a table of key | type | status | close date | summary, with links,
grouped by sub-theme/epic. End with a short summary: how many features and the
major themes.

project = {PROJECT}
AND issuetype in (Story, Improvement, Epic)         -- your feature types
AND statusCategory = Done                      -- catches Done / Released / Closed
AND resolved >= "{YYYY/MM/DD}" AND resolved <= "{YYYY/MM/DD}"
-- team filter: keep the ONE line that matches your Jira
AND "Team[Team]" = "{TEAM}"              -- Jira "Team" field
-- AND component = "{TEAM}"                        -- or by component
-- AND labels = "{TEAM}"                           -- or by label
ORDER BY resolved DESC

You work with our Jira via MCP. Task: count how many times a feature's issues
were sent BACKWARD in the workflow (rework loops / ping-pong) — not forward
progress.

Feature: "{FEATURE — key or title}"
Project(s): {PROJECT KEY}
Related issues (optional): {EPIC / LINKS / LABEL that group the work}
Forward status order: {ORDERED list, or leave blank and let me confirm yours}
  e.g. Backlog > Analysis > Next > In progress > Ready for review
       > Ready for test > Ready for merge > Released

IMPORTANT: ping-pong = BACKWARD moves only. Going forward through the order
above (Analysis -> Next -> In progress) is normal progress and counts as ZERO.
The count comes from the changelog, and depends on the status order below.

Step 0. Scope + confirm the status order:
- Collect ALL issues of the feature: sub-tasks, epic children, linked issues.
- List every workflow status these issues actually used, and PROPOSE the
  forward order (happy path). Show it to me and let me correct it — the count
  depends on it. Mark the gates we care about: Ready for review, Ready for test.
- Fetch the FULL changelog (expand=changelog) for each issue.

Step 1. Count backward jumps — the headline number:
- Walk the status transitions in time order. A jump is BACKWARD when the target
  status sits EARLIER in the confirmed order than the source status
  (e.g. Ready for test -> In progress, Ready for review -> In progress).
- Count every backward jump. That total = how many times the issue was sent
  back.
- Ignore: forward moves, bot/automation transitions (e.g. Automation for Jira),
  and resolution-only changes.

Step 2. Break the number down:
- By gate: how many jumps came back FROM "Ready for test" (failed QA) vs FROM
  "Ready for review" (review rejected) vs from any other later status.
- Per issue, then summed for the whole feature.

Step 3. Report:
- THE number: N backward jumps across the feature.
- Per-issue table: key | backward jumps | from-test | from-review | other.
- One line per jump: date · from -> to · who · reason from comments, if any.
- Secondary, listed separately (NOT part of the number): assignee reassignments
  between developers — a hand-off, not a status jump.

-- 1) every issue that makes up the feature
(issuekey = {FEATURE}
  OR parent = {FEATURE}
  OR "Epic Link" = {FEATURE}
  OR issuekey in linkedIssues("{FEATURE}"))

-- 2) that jumped BACK out of a review/test gate at least once
--    set the gate statuses and the dev status to match your workflow
AND (
  status CHANGED FROM "Ready for test"   TO ("In progress", "Ready for review")
  OR status CHANGED FROM "Ready for review" TO "In progress"
)
ORDER BY updated DESC

You work with our Jira via MCP. Task: count how many bugs were created in total,
over a period, in the project where a feature shipped, within a team's area of
responsibility.

Project: {PROJECT KEY}
Period: {DATE FROM — DATE TO}   (by issue creation date)
Team's area: {TEAM — how its ownership is scoped}

IMPORTANT: discover two things before counting.

Step 0. Discover:
- Which issue type(s) represent bugs here (Bug, Defect, Bug Sub-task — some
  projects use more than one). Include all of them.
- How the team's "area of responsibility" is scoped: usually one or more
  components, sometimes a Team field, a label, or a set of assignees. Confirm
  the exact component/label names with me if unclear.

Step 1. Count bugs created in the period, scoped to the team:
  project = {PROJECT}
  AND issuetype in ({BUG_TYPES})
  AND created >= "{FROM}" AND created <= "{TO}"
  AND ({TEAM_SCOPE})
Use a count query (total only) — no need to page every issue.

Step 2. Report:
- The total number.
- The exact filter you used (bug types, team scope, dates) so I can verify.
- Optional if I ask: breakdown by month, by component, or by current status
  (still open vs resolved).

project = {PROJECT}
AND issuetype = Bug                          -- add Defect / Bug Sub-task if used
AND created >= "{YYYY/MM/DD}" AND created <= "{YYYY/MM/DD}"
AND component in ("{COMPONENT A}", "{COMPONENT B}")    -- team's area
-- AND "Team[Team]" = "{TEAM}"                 -- or by Team field
-- AND labels = "{TEAM}"                       -- or by label

You work with our Jira via MCP. Task: count the bugs/defects found for one
specific feature (not the whole project).

Feature: "{FEATURE NAME + any aliases}"
Epic / key: {EPIC KEY the feature is tracked under}
Project(s): {PROJECT KEY}

IMPORTANT: bugs attach to a feature in several ways and no single one is
complete. Gather every channel, then dedupe and rate confidence.

Step 0. Discover:
- Which issue type(s) are bugs here (Bug, Defect, Bug Sub-task).
- How bugs are usually tied to a feature in our Jira: issue links to the epic,
  membership under the epic, a shared label/component, or just a text mention.
  Confirm the exact label/component names with me.
- Confirm the feature's actual production RELEASE DATE. Only use a resolved
  date if the team confirms it represents the production release.
- Discover how the environment or "found in" field records where a defect was
  detected. If no field exists, ask me to confirm evidence from the issue.

Step 1. Collect candidate bugs from EACH channel:
- Linked to the feature/epic (issue links: relates to, caused by, blocks).
- Under the epic (Epic Link / parent = the epic).
- Sharing the feature's label or component.
- Text mention: summary/description/comments contain the feature name or an
  alias.

Step 2. Merge & judge:
- Union all channels and DEDUPE by issue key.
- Rate confidence: strong = explicit link or epic membership; weak = text
  mention or shared label only. Show me the weak ones so I can confirm/reject.

Step 3. Report — split by PHASE (the key breakdown):
- Found during testing: evidence identifies a test or pre-production environment.
- Escaped production defects: evidence confirms the defect was found in production.
- Unknown: insufficient evidence of where the defect was found. Do not infer
  production exposure from the issue creation date alone.
- Report creation before vs on/after release separately as a timing breakdown,
  if the release date is known.
- Give all three counts, plus totals (strong-only and strong+weak).
- Also break down by channel and by current status (open vs resolved).
- The list: key | phase | confidence | channel | status | summary.
- State what was ambiguous and any alias you searched.

project = {PROJECT}
AND issuetype in (Bug, Defect)
AND (
      issuekey in linkedIssues("{EPIC}")      -- linked to the epic
   OR "Epic Link" = {EPIC}                  -- under the epic
   OR parent = {EPIC}
   OR labels = "{FEATURE_LABEL}"              -- shared label
   OR component = "{FEATURE_COMPONENT}"       -- shared component
   OR text ~ "{FEATURE NAME}"                -- mention in summary/desc/comments
)
ORDER BY created DESC