Agent Workflows

Review product analytics, investigate runtime evidence, and connect DebugBundle automation to repository-owned agent workflows.

Product Analytics Review

Agents can answer usage and journey questions through the same member-authenticated surface as humans. The efficient path is to use direct aggregate reads first, narrow to funnels or bounded journey samples only when needed, and generate an analytics bundle only when a specific analysis should be retained and shared.

Start with aggregate evidence

Read visits, active users, routes, devices, referrers, semantic actions, and funnel conversion without generating a bundle.

Explain journey friction

Compare funnel drop-off and journey patterns, then inspect a small redacted structured sample only when aggregates need supporting evidence.

Preserve bounded analysis

Generate an analytics bundle for a focused question that humans or agents need to revisit, not for every visit.

A typical review uses get_usage_summary, get_route_metrics, get_action_metrics, get_funnel_analysis, and get_journey_patterns. Agents can correlate a runtime failure with get_incident_impact, review deterministic opportunities, and retrieve existing analytics bundles before asking to generate another one.

Analytics settings, saved-funnel changes, and bundle generation are explicit mutations. Agents should read current settings and definitions first, explain the intended change, and proceed only when the user asks. Project tokens remain ingestion-only; analytics reads and management use member authentication and preserve consent, redaction, retention, and approved custom-dimension limits.

See AnalyticsBundle, AnalyticsBundle CLI, and MCP Workflows for the complete flow.

GitHub Automation

GitHub automation is available on Solo and Team plans.

repository_dispatch to GitHub Actions

Connect a project repo in the dedicated GitHub project tab, let DebugBundle emit repository_dispatch, and start triage inside GitHub Actions.

Reference action for full context

Use debugbundle/action to fetch the full bundle and reproduction into the canonical .debugbundle/bundles/cloud layout.

Repository-owned automation

After the fetch step, let your workflow decide whether to open an issue, invoke an agent, create a PR, or stop.

DebugBundle's GitHub automation path is intentionally narrow:

Open the project's GitHub tab and connect GitHub.
Assign one primary repository to the project.
Create dispatch rules that select which lifecycle events should trigger automation.
Receive repository_dispatch in GitHub Actions. Incident dispatches can fetch full incident context with debugbundle/action; hosted improvement dispatches include improvement_id plus a bundle link for repository-owned workflows that want to fetch the improvement bundle directly. Incident-backed improvement opportunities do not emit improvement_bundle.created; agents should fetch the related incident bundle instead.

DebugBundle owns the dispatch. Your repository owns the policy after the workflow starts.

Example flow

$ debugbundle github status --project-id proj_123
$ debugbundle github rules --project-id proj_123
$ gh workflow view .github/workflows/debugbundle.yml

The action and workflow examples live alongside the product docs:

examples/github-actions/basic.yml
examples/github-actions/agent-capable.yml
examples/github-actions/issue-creation.yml

The fetch action itself is published separately at debugbundle/action@v1.