/super-collect

name: super-collect
description: Find problems in one project, verify each, write one findings doc and hand it to Matt Pocock's /to-spec then /to-tickets; 1–5 tickets go to /implement-spec, 6+ to the super-board Backlog (no /to-spec or /to-tickets installed → files straight into Backlog). Source plug-ins - sentry (app errors), posthog (exceptions, rage/dead clicks, failure events, web vitals, tracking gaps), github (issues not on the board), prs (recurring problems in merged PRs and their review comments), architecture (refactor findings), plus any custom source added in onboard (an MCP server, HTTP API, CLI command or app). Each candidate is checked by one fresh verifier first. Dry-run by default. Use when the user says "super-collect", "/super-collect", "/super-collect sentry", "collect tickets", "triage errors onto the board", "what keeps breaking", or "find refactors".

super-collect — find problems, hand them to the planning chain

One job: find problems and turn them into tickets. The flow:

1. Collect candidates from the sources. 2. One fresh verifier checks each candidate. 3. Write ONE findings doc that groups what survived: `docs/super-board/findings/collect-<YYYY-MM-DD>.md`. 4. `/to-spec` turns the findings doc into a spec. 5. `/to-tickets` turns the spec into tickets. 6. Build fork: **1–5 tickets → `/implement-spec`** (one session, no QA lane). **6+ tickets → super-board**: each ticket goes to **Backlog**, then `/super-board lint` and `run`.

No `/to-spec` or `/to-tickets` in this project → file each finding straight into Backlog (today's path, "Filing" below) and print why. super-collect never edits app code and never moves a card to `Ready`. Per project only: it reads the active project's super-board config and files onto that project's board. The whole rule in plain words: [routing](../../docs/super-board/routing.md).

Invocation

| Command | Does | |---|---| | `/super-collect` | every source enabled in `collect.sources` | | `/super-collect <source> [<source>…]` | just those: `sentry`, `posthog`, `github`, `prs`, `architecture`, or a custom source's `name` | | `--since 30d` / `--since 2026-09-01` | window; default `collect.window_days`, else 14 days | | `--yes` | write and file without the confirm step (never skips verify or dedupe) | | `--direct` | skip the planning chain: file each finding straight into Backlog |

Default is **dry-run**: show the findings doc and the route, write nothing, go on only on confirm.

Scheduler integration

For periodic intake, use [scheduled-intake.md](references/scheduled-intake.md): let the owner's scheduler invoke this existing skill, retain source verification and holding-column-only filing, and notify only on meaningful changes or failures. No job, cadence or scheduler is created by this skill.

Setup

1. Resolve the config: `.claude/super-board/active` → `.claude/super-board/configs/<slug>.json` (shape: `../super-board/references/config-schema.json`). No config, or no `collect` block for a requested source → stop and point at `/super-board onboard` (its collect step sets sources up). 2. Secrets come only from `.env` (nearest walking up): `SENTRY_AUTH_TOKEN`, `POSTHOG_PERSONAL_API_KEY`. Never print, echo or paste them. 3. Source `.claude/bin/super-board-gh-guard.sh`; `sb_gh_guard_check 200` before each gh burst. 4. Snapshot the board through `.claude/bin/super-board-github-read.py --kind items -- project item-list <number> --owner <owner> --format json --limit 500`. A count mismatch or read failure halts; never treat a partial board as complete. It is the dedupe set for verification and the "not on the board" set for `github`.

Scripts live in `.claude/skills/super-collect/scripts/` (`S=` below). Every fetcher takes `--since` and prints JSON; a fetcher that cannot reach its source prints `{"status":"unavailable","error":…}` and exits 2. Record each source as `read (n)`, `empty`, `unavailable` or `truncated` — never report an unreachable source as empty.

Sources

| Source | Fetch | Candidate → ticket | |---|---|---| | `sentry` | `python3 $S/collect_sentry.py list --since <w>` — Sentry REST, Bearer token (scopes `event:read project:read`): org issues list, then `event <id>` / `tags <id>` for evidence | one unresolved issue → `bug`, fp `err|sentry|<id>` | | `posthog` | `python3 $S/collect_posthog.py list --since <w>` — HogQL `POST {host}/api/projects/{id}/query/` | one signal group → see table below | | `github` | Read open candidates with `gh issue list --state open --json number,title,body,labels,url --limit 300` (a full 300 is capped coverage, not a complete repo inventory), minus issues on the board and `source:*` labels | real work → **adopt** (`--adopt <n>`), never copied | | `prs` | `python3 $S/collect_prs.py list --since <w>` — one GraphQL search `is:pr is:merged merged:>=DATE`, paginated, with comments, reviews and review threads (human and bot), super-review reports flagged (`<!-- super-review:report -->`) | one recurring root cause → `fix` / `refactor` / `feature`, fp `prs|<boundary>|<cause>` | | `architecture` | read-only finder sub-agent (below) | one finding → `refactor`, fp `arch|<module>|<problem>` | | custom (`collect.custom[]`) | `python3 $S/collect_custom.py list --since <w>` — http and cli sources run in the script; an `mcp` source comes back `status: agent`: call that server's read/list tool yourself (read-only), then pipe its JSON into `collect_custom.py normalize --name <n>` | one candidate → `bug` (errors, incidents) or `feature` (requests), `--source custom`, fp `custom|<name>|<key>` (the script emits it) |

custom sources

Added in onboard's "➕ Add another source" (`super-board onboard` → 📥 Bug sources): the user types a link, an app name, an API URL, an MCP server or a command; `collect_custom.py classify` decides which, `ping` proves it can be read (read-only) and `add` saves `{name, kind, target, auth_env?, map?}` to this project's config and its `name` to `collect.sourc