Twg Status Rollups

twg-status-rollups

Use together with the root twg skill. Exact command grammar must come from live twg help, twg help <terms>, or twg help describe <path>.

Use When

• "What did I/person/team/org work on?"
• "Status of project/goal/topic/focus area"
• "Leadership readout"
• "Weekly/monthly/quarterly review"
• "APEX/performance appraisal evidence"
• "Goal alignment audit"
• "Org bottlenecks, priorities, stale goals, project risks"

First Move

Resolve the reporting scope before broad retrieval:

• Person: resolve email, name, or account ID, then user/activity/context as needed.
• Team: resolve the team and member roster.
• Org: use org-tree deep enough to reach useful manager or team groups.
• Project, goal, or focus area: resolve the native key, ARI, URL, or name first.
• Topic: resolve/search once, then select concrete project, goal, page, or workitem anchors.

Establish the time window from the prompt. If absent, ask when precision matters; otherwise use a small recent window such as 7d or 30d and state that choice.

Route Selection

• Start from typed command families named in the root twg skill: users,

org-tree, teams, projects, goals, focus areas, work activity, search, Jira, Confluence/docs, meetings/videos, and Bitbucket.

• Pull planning state first for project, goal, and org reports: owners, latest

updates, status, target dates, linked goals, and linked projects.

• For engineering output, use pull-request or work-activity surfaces before broad

text search.

• For large orgs, use aggregate team/project/goal/work signals first, then

hydrate representative people, leaders, or outliers.

• Use context user only for the manager, explicit review subject, or another

central collaborator whose graph changes the answer.

• Do not apply projection flags to every evidence surface. Native/federated

commands should use only flags advertised by their own help contracts.

Evidence Policy

• Balance quantitative activity signals with representative qualitative

evidence: docs, comments, blockers, project/goal updates, PRs, and stakeholder interactions.

• Distinguish authored delivery from review, coordination, and influence.
• Sample when the scope is broad. State the sample boundary instead of trying to

exhaust every person and every product surface.

• Treat search/Rovo results as candidate anchors only; hydrate central candidates

before using them as evidence.

• For PR load, start count-first. If a rollup warns that full fetch is too broad,

narrow once or switch to count-only.

Recipe Cards

Person Or Personal Update

Resolve the person, then pull recent authored/assigned Jira work, authored/reviewed PRs, docs/pages, meetings, and project/goal involvement. Separate delivery, review, docs/strategy, coordination, and influence.

Team Or Org Leadership Readout

Resolve org-tree first. Group by manager, team, or workstream before per-person details. Use org-level PR/project/goal/work signals, then hydrate people or outliers that explain momentum, blockers, review load, or ownership.

Project Or Goal Status

Fetch the native project or goal first. Include owner, state, latest update, linked goals/projects, target dates, and status recency. Hydrate only Jira, docs, PRs, or meetings that explain risk, progress, or dependency.

Topic Status

Resolve/search once, select central project, goal, page, or workitem anchors, then hydrate those before using broad work/activity queries.

Appraisal / Performance Evidence

Resolve the person and time horizon. Separate authored delivery, review, collaboration, docs/strategy, project/goal impact, and stakeholder signals. Avoid ranking solely by counts; add calibration caveats when evidence is weak or biased.

Output Shape

• Executive summary first, with 3-6 high-signal observations.
• Table with owner/team/workstream, positive signals, risk signals, current focus,

confidence, and evidence.

• Risks and leadership attention ranked by impact and owner.
• Confidence and gaps, including stale updates, missing product coverage, ACL

gaps, or sampled evidence boundaries.

Anti-Patterns

• Do not make a status report a list of every artifact.
• Do not infer goal/project health from issue counts alone.
• Do not fan out across every org member if manager/team-level grouping answers

the prompt.

• Do not use search snippets as final evidence for status or risk.