Founder Pulse

View saved version →

---
name: infer-product-operations
description: "Analyze GitHub or GitLab Issue flow for a requested period, focusing on two populations: Issues that changed from open to closed during the period and Issues that were still open at period end. Break both populations into mutually exclusive creation-age buckets of 0–7 days, 8–14 days, 15–30 days, and over 30 days; preserve labels and inspect delivery links for closures. Use for lightweight project progress reports, closure-flow reviews, open-backlog aging, weekly or monthly Issue summaries, and requests asking what was resolved versus what remains open."
---

# Analyze Issue Flow

Turn GitHub or GitLab Issue activity into a concise, evidence-backed progress report. Keep all access strictly read-only.

## 1. Fix scope

- Resolve the platform, instance hostname when self-managed, project namespace/name, requested time window, and reporting timezone.
- Support GitHub.com, GitLab.com, and self-managed GitLab instances.
- Default to the most recent 30 days when no window is given.
- State exact start and end dates.
- Analyze remote platform state only. Ignore local worktrees and local-only branches.

## 2. Establish access

Determine visibility before requesting authentication.

- For a public project, begin without authentication. Use public platform APIs and pages or public remote Git data.
- For a private project, request authorization only when no existing authenticated connector, platform CLI (`gh` or `glab`), signed-in browser session, or suitable read-only token can provide access.
- Treat `404`, `403`, sign-in redirects, and empty results as ambiguous until visibility and authentication are resolved.
- Never expose credentials in commands, logs, reports, or URLs.

Prefer sources in this order:

1. Applicable authenticated connector or platform API.
2. Existing authenticated `gh` or `glab` CLI.
3. Existing signed-in browser session.
4. Public platform pages or APIs for public projects.
5. Ask the user to connect or authenticate only when necessary.

## 3. Collect complete Issue data

Collect and paginate all Issues needed to construct both status populations:

- Every Issue that transitioned from open to closed inside the time window, including Issues created before the window.
- Every Issue that is open at the end of the time window, including Issues created before the window.
- Issue number, title, stable URL, author, created time, closed time, current state, and all labels.
- Closing actor or reason when available.
- Timeline/system events, linked branches, commits, pull/merge requests, cross-references, commit authors, and pull/merge request authors for closed Issues.

Do not count pull/merge requests as Issues on GitHub endpoints that return both. On GitLab, include Issue-type work items and exclude tasks, incidents, epics, and other work-item types unless the user asks to include them.

Use state-transition events when available. If the platform exposes only the current state and `closed_at`, treat a `closed_at` timestamp inside the period as the best available evidence of an open-to-closed transition and disclose the limitation. If an Issue was closed and then reopened before period end, include it in the closed population because the transition occurred and also in the open-at-end population; flag this overlap explicitly.

Report incomplete pagination, disabled Issue features, inaccessible timelines, missing transition history, or permission-limited fields. Never describe inaccessible data as empty.

## 4. Calculate the counts

Use these two primary populations consistently:

- **Open → Closed:** Issues with an open-to-closed transition inside the reporting period, regardless of creation date.
- **Still Open:** Issues whose state is open at the reporting period end, regardless of creation date.

Break each population into mutually exclusive creation-age buckets measured from the period-end timestamp:

- **近 1 周:** created 0–7 elapsed days before period end.
- **近 2 周:*

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.