/build-automation #### Trigger: Scheduled - Run every Monday at 9am #### Action: Send this prompt to the "Jira Work Agent" ````text # Weekly team and workstream report Research the teams and workstreams connected to one seed user, publish a Confluence status page, then return an HTML email announcing it. The seed user is a discovery seed, not the subject. Never put their name in the page title, headings, or executive summary. This is a scheduled run with no active Jira work item; never pass an identity ARI to **Get work item**. **Reporting window:** the 7 days ending now. Compute both bounds in UTC and use the same pair everywhere. **Empty results:** an empty or near-empty tool result is an answer, not a failure. Never repeat a call with the same arguments, and never chase the same object through a different tool. Record it as a coverage gap and move on. Research is never a reason to skip publishing. ## Stage 1 — Inventory Call each of these exactly once, with `startTime` and `endTime` set to the reporting window: - **Get Work Summary For Given User in Twg** — `userId = {{SEED_USER_ARI}}` - **Get Ranked Work Summary for User** — `person = {{SEED_USER_ARI}}` Treat the first as the inventory and the second as the ranking. Inspect every facet, count, timestamp, status, URL, and pagination marker. Classify each returned item: **Strong** — authored PR created or materially updated in window; Confluence page created in window; Loom created in window; Atlas project or goal returned directly. **Conditional** — contributed Confluence page (needs a native page read confirming relevance); assigned Jira issue (needs current activity or a linked strong artifact); reviewed PR (only to reinforce an anchor already established by strong evidence). **Ineligible** — anything outside the window, archived content, previously generated weekly reports, Automation test output, personal account requests, dependency-bot activity, mechanical notifications. Record for each eligible item: exact URL or ARI, product, source host, timestamp, container, and candidate anchor. Atlas projects arrive here already carrying state, start and due dates, last-updated time, update and watcher counts, and linked goals. That is reportable evidence on its own — keep it, and do not treat a project as thin just because a later hydration call adds nothing. ## Stage 2 — Anchors Cluster eligible artifacts by workstream, not by product. Pick **at most 5** anchors, preferring: Atlas project or goal > Jira epic/initiative/parent > repository or service with authored PRs > current Confluence planning or decision page > named program with two independent current signals. Each anchor needs either one strong artifact or two independent current signals joined by an exact key, URL, repository, project, or explicit link. Never anchor on an isolated review, comment, feature flag, or cleanup ticket when a stable parent exists. ## Stage 3 — Owning teams Call **Get user's teams** once with the seed user ARI. Membership is a candidate list only, never proof of ownership. Discard teams whose name or description signals test data, generated data, scorecards, samples, or "ignore me". Discard any team you cannot connect to a selected anchor. For **at most 3** survivors call **Get team information** with the exact team ARI, requesting members, active projects and spaces. A team is reportable only when its canonical metadata or explicit anchor ownership ties it to a selected anchor. ## Stage 4 — Hydrate Finish Stage 3 before you begin Stage 4. The rows below depend on identifiers that Stage 3 returns, and running them early is why a hydration call comes back empty. Hydrate only what could change an anchor's status, ownership, progress, decisions, milestones, risks, dependencies, or confidence. Skip any row below whose artifact type did not appear in Stage 1 — do not go looking for it. | Anchor artifact | Tool and constraint | | --- | --- | | Jira issue or epic | **Get work item** with an exact key, ARI or URL from a verified result, read against the site that result came from. Plus **Get Work-Item Context in Teamwork Graph** for at most 2 central Jira anchors. **Get Related Repos for Work-Item in TwG** only if a Jira anchor still needs repository resolution. | | Pull request or repo | Use the PR and repo metadata already returned by Stage 1. There is no provider-native PR-detail tool; do not invent one. | | Confluence page | **Get page** with the exact numeric content ID, for at most 3 evidence pages. Verify title, author, created date, version, relevance. | | Atlas project or goal | **Get project context**, but only with an ARI you have literally seen in an `ari=` field of a tool result — in practice the `active_projects` entries returned by **Get team information** in Stage 3. A valid Atlas project ARI ends in a UUID, as in `ari:cloud:townsquare::project/f5138818-0875-42aa-a890-e79333564598`. The `ATLAS-nnnnn` at the end of a project URL is a display key, not an ARI segment: never paste it into an ARI, and never assemble an ARI from a URL. No `ari=` field for a project means no call — report it from its Stage 1 fields instead. | | Loom | Use only videos returned in the window, and only when they explain a selected anchor. | Never call **Get work item** for an identity ARI, for a key inferred from a PR title or branch name, or for a key whose Jira site is unknown. A failed cross-site read is a coverage gap — do not retry elsewhere or substitute a similar key. An empty typed result is a coverage gap. Never use raw Teamwork Graph Cypher. If contributor context is still missing, call **Get Ranked Collaboration Summary Between Users in Twg, V2** at most once, with the seed user, one already-verified collaborator, and the same window. ## Stage 5 — Search fallback If a selected anchor returned empty from Stage 4 and still lacks one named fact that would change the report, you **must** attempt exactly one **Search** call for it. Otherwise make no Search calls. Hard cap: 1 call for the whole run, and it belongs to report evidence only — never spend it locating a destination, a parent, or a previous report. The query must carry an exact full URL, repository name, canonical project name, exact Confluence title, or distinctive workstream name, plus the reporting dates. Never search a bare Jira key. Reject hits that match only on an acronym or keyword, and reject the parent page and any previously generated summary. Open an accepted hit with its product-native tool before using it. If Search also comes back empty, record a coverage gap and move on. ## Stage 6 — Gate Do not draft until all of these hold: every Stage 1 facet and pagination marker inspected; timestamps rechecked against the window; ineligible items removed; every anchor meets the evidence threshold; every reportable team has ownership evidence beyond membership; every Jira read used its source site; Confluence evidence pages read natively and none of them generated reports; Atlas ARIs copied not constructed; Search candidates hydrated or discarded; every claim, status, owner, milestone, decision, risk and URL traceable to a named source; coverage gaps stated honestly. Resolve any check that fails by dropping the anchor or recording a coverage gap, never by making more tool calls. Then stop gathering and go to Stage 7. ## Report content Every item must trace: eligible seed-user artifact → selected anchor → verified owning team. Once an anchor is selected, include material work by other contributors that advances it, but do not go mining their unrelated activity. Build only the sections you have evidence for. Never invent metrics, owners, statuses, dates, relationships, or URLs, and never force an empty section. Never emit a placeholder. No `[Add Owner]`, no `TBD`, no `TODO`, no square-bracketed prompt to fill something in later. A field you have a verified value for gets that value; a field you do not gets its line dropped entirely. **Owners:** the owner or DRI of an Atlas project is in that project's `Get project context` result. Extract the name during Stage 4 and carry it through to the page. 1. **Executive summary** — information panel: selected teams and anchors, momentum, milestones and decisions, material risks. 2. **Evidence coverage** — the window dates and only the source categories that returned usable evidence. Name every gap; never claim complete coverage. 3. **Teams at a glance** — wide table: Team, Relevant anchors, Current status, What changed, Evidence. Canonical team names, status lozenges. 4. **Workstream updates** — one section per anchor: canonical name and link, status, verified owner or DRI, progress across contributors, decisions and milestones, dependencies and risks, sources. 5. **Completed work and decisions** — source-backed outcomes closed inside the window only. Do not promote a review, comment, or cleanup ticket into a team outcome. 6. **Risks and blockers** — warning panels, verified current risks only: affected anchor, consequence, sourced mitigation, evidence. Every link must be copied verbatim from a tool result. Never build a URL from a title, key, ARI, or content ID. Never link to the publishing destination `{{PARENT_PAGE_ID}}`, to anything already filed under it, or to a previously generated summary. ## Visual specification Executive status report, not a chat transcript or a bullet dump. - Full-width information panel for the executive summary. - Clear heading levels for each section and each workstream. - Wide table for the team overview so it spans the content area. - Native status lozenges for every status value: green on track or shipped, yellow at risk, red blocked, blue in progress, grey unknown. - Two-column layout only where two short blocks genuinely sit side by side. - Warning panels for risks, note panel for coverage caveats. - Dividers between major sections. - Short paragraphs, scannable bullets, bold leading label on each bullet. - Evidence as inline Smart Links, never a raw URL or a raw ARI in body text. ARIs are tool arguments and must never be visible to a reader; cite the thing by its name, linked. - No emoji, decorative icons, prose in code blocks, or nested tables. ## Stage 7 — Publish Publishing is the point of this run. You must reach 7.1 and you must call it exactly once. Never abandon the run with no page created. **7.1** Call **Create content** exactly once, with exactly these arguments: - `spaceId` = `{{OUTPUT_SPACE_ID}}` - `parentId` = `{{PARENT_PAGE_ID}}` - `semanticQuery` = the text described below All three are required. A call missing `parentId` is malformed and publishes to the wrong place; if you are about to send this call without `parentId`, add it. If the tool exposes `title`, `contentType` or `shouldAutoExecute`, also pass `title` verbatim as specified, `contentType` = `page`, `shouldAutoExecute` = `true`. `{{PARENT_PAGE_ID}}` is the destination parent. Pass the value exactly as given and let the tool resolve what kind of content it is: do not reason about whether it is a page, a folder or anything else, do not add a parent-type argument, and do not vary any other argument based on it. Otherwise leave it alone entirely — never call **Get page**, **Search** or any read tool on it, never treat it as evidence, and never mention it inside `semanticQuery` or in the report body. The `semanticQuery` must be self-contained and must begin with exactly these two lines: ``` Use this exact page title, verbatim, unchanged: Weekly Team and Workstream Status Update — {{now.format("MMM d, yyyy")}} Preserve every fact and URL below exactly as given. Do not rediscover, re-research, re-word, or re-title anything. ``` Then, in this order: the visual specification restated in full; the reporting window dates; the executive summary; the selected teams with ARIs; each anchor with its status, verified owner or DRI, progress, decisions, milestones and risks; contributor attribution; and every allowed source URL. `semanticQuery` is the only thing the page generator can see. Anything the report is supposed to contain but that you leave out here will be missing from the page or filled in with an invented placeholder. Walk the six report sections and confirm every field each one requires is present before you send the call. Use native Confluence markup for status lozenges, panels and inline Smart Links so the formatting survives. These IDs belong in the tool's arguments only, so keep them out of the prose. Do not emit literal ADF JSON. Do not call the legacy Create page or Edit page actions, Copy page, Rename page, or any move action. **7.2** Read the result of 7.1. It returns the new page's URL, title and content ID. Record all three verbatim — these are the only values Stage 8 may use. Publishing is now final. Whatever 7.1 returned, do not call it again, and never move, copy, rename, reparent, delete or recreate the page. If the returned title differs from the title you specified, leave the page alone and say so in the email. ## Stage 8 — Email Your entire final response is the email body and nothing else. No preamble, no "I have created", no coverage notes, no closing question, no generated-by footer, no code fences. Emit exactly this HTML, substituting the real title, URL and one-sentence summary: ```html

The weekly team and workstream status update has been published.

ONE_SENTENCE_SUMMARY

``` `PAGE_URL` and `PAGE_TITLE` must be copied verbatim from the Stage 7.1 result and from nowhere else. A URL that came from a work summary, a search hit, an evidence page, or the parent page is never valid here. If you did not create a page, you have no URL, and you must not supply one. `ONE_SENTENCE_SUMMARY` is a single plain sentence naming the teams covered and the headline of the week. If the title came back different from the one you specified, append one further `

` stating that plainly. If Stage 7.1 did not return a page, emit exactly this instead, with no link: ```html

The weekly team and workstream status update could not be published this week.

REASON

``` ```` #### Action: Send email - To: {{USER_EMAIL}} - Subject: Weekly Team and Workstream Status Update - Body: Use the output from the Rovo agent - BodyType: HTML

Term	https://aci-standards.atlassian.net/wiki/pages/resumedraft.action?draftId=180879361&draftShareId=874ba722-2f39-4b76-b7cf-76dc24cada03
Business term	Duty Traveler
Definition	An Airline employee traveling on company business as a SeatAllocatedPassenger.
Allowed values
Comments	Considered as part of regular Passengers, and typically an AdultPassenger.
Status	Approved
XML type	NA, Concept
AIRM equivalent	N/A
AIDM equivalent

DutyTraveler