scan-repo

name	scan-repo
description	Weekly repo activity scan — new discussions, issues, and PRs, ordered by effort into an action list
argument-hint	["since","e.g. 14d or 2026-07-01"]
allowed-tools	Bash, Read, Write, Glob, mcp__github__list_issues, mcp__github__search_issues, mcp__github__list_pull_requests, mcp__github__get_pull_request_reviews

Scan Repo

Scan all activity on gittower/git-flow-next since the last scan and produce a prioritized action list: what came in (discussions, issues, PRs), what needs a reaction from us, and in which order to tackle it — quick wins first, deeper work later, each item with the command that handles it.

Read-only: the scan never posts, labels, or replies. It only reports. Meant to be run manually about once per week.

Arguments

/scan-repo [since]

• since — optional lookback: a duration (7d, 14d) or a date (2026-07-01). Default: the date of the most recent scan report in .ai/scans/, or 7 days if none exists.

Instructions

1. Determine the Window

ls .ai/scans/scan-*.md 2>/dev/null | sort | tail -1

Use the date in the newest filename as SINCE unless an argument was given. Fall back to 7 days ago. Get today's date with date +%Y-%m-%d.

2. Gather Activity

Collect in parallel where possible:

Discussions (GraphQL):

gh api graphql -f query='query { repository(owner: "gittower", name: "git-flow-next") {
  discussions(first: 30, orderBy: {field: UPDATED_AT, direction: DESC}) {
    nodes { number title category { name } isAnswered updatedAt createdAt
      author { login } comments(last: 3) { nodes { author { login } createdAt } } } } } }'

Flag: new discussions since SINCE; unanswered questions; threads where the last comment is not ours.

Issues:

• New since the window: gh issue list --state open --search "created:>SINCE" --json number,title,labels,author,createdAt
• Updated with external activity: gh issue list --state open --search "updated:>SINCE" --json number,title,labels,comments,updatedAt — for each, check whether the last comment is from an external user (awaiting our reply) or from us (awaiting theirs; no action)
• Open needs info-type situations where the reporter has now responded

Pull requests:

• Assess every open PR exactly as /check-prs does (read .claude/skills/check-prs/SKILL.md, steps 1–2) — status vs the review response window, days waiting, whose move it is
• Additionally flag PRs opened since SINCE as new

Housekeeping signals (cheap checks, include only if noteworthy):

• CI status on main: gh run list --branch main --limit 5 --json conclusion,name
• Open spec issues (label:spec) with no linked PR — accepted work nobody started

Treat comments by repo collaborators and bots as "ours"; everyone else is external.

3. Classify by Effort

Sort every actionable item into one of three buckets:

Quick wins — minutes each, mostly judgment-free:

• Questions we can answer directly (answer known from code/docs)
• Obvious duplicates to link and close
• Reporters who answered a needs-info request (unblock them)
• Reminder-worthy PRs approaching the response window
• Small PRs (single file, few lines, clear purpose)

One command — the autonomous pipelines do the heavy lifting; our cost is reviewing their output at the gates:

• Untriaged bug reports and feature requests → /triage
• Typical incoming PRs → /handle-pr
• Lapsed response windows → /takeover-pr
• Accepted-but-unstarted specs → /resolve-issue

Needs thinking — human design or policy judgment up front:

• Feature requests touching architecture, config semantics, or compatibility (triage will end in a design discussion)
• Bug reports that contradict the spec or expose unclear intended behavior
• Large or multi-concern PRs (scope conversation with the author)
• Anything where two pipelines conflict (e.g., PR submitted for an issue that was never accepted)

Within each bucket, order by age (oldest first) — external people are waiting.

4. Write the Report

Write .ai/scans/scan-<today>.md:

# Repo Scan <today> (since <SINCE>)

## Summary
<2-3 sentences: volume, anything urgent, overall state>

## Action List

### Quick wins
| # | Item | Waiting | Why quick | Command |
|---|------|---------|-----------|---------|
| 1 | discussion #12 — <title> | 6d | answer is in docs/gitflow-config.5.md | reply directly |
| 2 | issue #101 — <title> | 3d | duplicate of #87 | /triage 101 |

### One command
| # | Item | Waiting | Pipeline | Command |
|---|------|---------|----------|---------|
| 3 | issue #103 — <title> | 2d | bug triage | /triage 103 |
| 4 | PR #99 — <title> | 4d | review | /handle-pr 99 |

### Needs thinking
| # | Item | Waiting | What to think about |
|---|------|---------|---------------------|
| 5 | issue #104 — <title> | 5d | proposes new branch type semantics — design call needed |

## No Action Needed
<Items with recent activity that are waiting on the other side, in-window
PRs, answered discussions — one line each so nothing looks >

5. Report to User

Show the summary and the full action list in the conversation, in tackle order. End with the single most valuable next command (usually action #1).