Using SprintFlow#

Sign in to the console (your company SSO). What you can do depends on your role:

Keyboard: Ctrl/⌘ K search and commands · n new run · g then d / r / c / s / m go to Dashboard, Runs, Connections, Settings, Memory · ? all shortcuts.

Developers#

Let AI SprintFlow implement your sprint stories#

1. Account → Jira account → Connect Jira with your own Jira account: your Jira email and an API token (create one at id.atlassian.com → Security → API tokens), or a personal access token on Jira Data Center. The token is stored encrypted and used only to read your projects, sprints and stories — comments and status changes are still made by the AI SprintFlow bot account. Tick Implement my stories automatically when a sprint starts if you want that (operators and above).
2. Your projects lists only the projects your Jira account can access that this installation works on. Keep All my projects or pick some → Save.
3. Dashboard → My sprint stories lists the active sprints of those projects with the stories assigned to you, in board order, with their Jira status and AI SprintFlow status. Issue types that are not automated (e.g. Bugs, if only Stories are) show as manual — you can still Queue them. Implement all my stories queues every open one.
4. When a sprint starts, your stories are queued in board order and implemented one at a time, each ending as a draft PR for you to review; stories added to the sprint later are picked up too. Watch progress on Sprint.
5. If your token expires or is revoked, the card and the Account page say so: reconnect with a new token. Disconnect deletes the token and turns automatic runs off.

Run one ticket#

New run (or press n) → ticket key (e.g. PAY-123) → Start run. Tick Dry run to get the patch without a branch or PR.

Follow a run#

The run page shows a stage bar (prepare → … → publish) and tabs: - Overview: outcome, PR link, cost, each step, self-healing actions. - Timeline: when each step ran and how long it took. - Changes: the diff. - Proof: the browser recording and step screenshots (also attached to the Jira ticket). - Report / Events / Files: the full report, live event log, logs and patch.

When SprintFlow needs you#

• Questions: if a story is unclear, SprintFlow asks on the Jira ticket. Answer there, then click Check for answers now (or wait for the poller).
• Approval: if your team uses checkpoints, or the change touches risky code, the run page shows Approval needed with the plan or the risky files → Approve or Reject (with a reason).
• Stopped: the banner says why in plain words (e.g. tests that were already failing, a vague story, the budget). The work so far is kept as a patch.

Review the draft PR/MR — SprintFlow acts on your comments#

Review it like any PR. SprintFlow watches it and, for line comments, "request changes" reviews and comments starting with @sprintflow or /sprintflow, fixes the code, re-verifies, re-reviews, pushes a new commit to the same branch and replies "Addressed in abc1234: …". It does the same when CI fails on the PR. It never merges — you do.

Managers#

• Team page: sprint completion, per-person progress (expand a person to see their stories), statistics per Jira project and per person (runs, draft PRs, success rate, time to PR, follow-ups, cost), date range, project filter, Export CSV.
• Health → Automation: Pause all automation in an incident or release freeze (with a reason); Resume after.

Admins#

• Connections: Jira, your Git host, and Claude (API key, Amazon Bedrock, Vertex AI, or Use Claude Code settings.json). Use Test connection on each; it tests what is on screen, so you can test before saving.
• Jira sign-in: paste any Jira link; Cloud or Data Center is detected and the sign-in type and API version are set for you. Then either
• Sign in with Atlassian (OAuth) — no tokens to copy. One-time setup: register an OAuth 2.0 app (Cloud: developer.atlassian.com; Data Center 8.22+: an incoming application link) with the callback URL and scopes shown in the card, enter its client ID and secret, and sign in as the account SprintFlow should comment as. Access tokens refresh automatically; if the sign-in is revoked, sign in again. Personal Connect Jira still uses tokens.
• Token — the card links straight to the page where the bot account creates its API token (Cloud) or personal access token (Data Center).
• Source code host sign-in: paste the repository's address (web page, pull request, HTTPS or SSH clone URL). GitHub, GitLab, Bitbucket and Azure DevOps are recognised by name; for a self-hosted server SprintFlow asks it whether it is GitLab, Gitea/Forgejo, GitHub Enterprise or Bitbucket Data Center. Provider, repository and URLs are filled in (check or change them under Advanced settings). Then:
• GitHub.com, GitLab.com, Azure DevOps — just sign in. Click Sign in with GitHub (…), enter the code shown on the page that opens, approve, done: the token is collected, the repository is checked and everything is saved. Sign in as the account that should push and open pull requests. This uses AI SprintFlow's own apps (device sign-in, like gh auth login), so there is nothing to register and no callback URL — it works on localhost and internal networks too.
• Self-hosted servers, Bitbucket, Gitea — the card links to the page where that host creates the right kind of token and says which permissions it needs. Or register your own OAuth app once (the steps, callback URL and permissions are in the card) and enter its client ID and secret under Advanced settings; then Sign in works there too. GitLab self-managed 17.2+ can use device sign-in with a non-confidential application (client ID only).
• Short-lived tokens are refreshed for API calls and for every git command, so long runs keep working.
• Settings: sprint automation (boards, scope, and allowed projects — the Jira projects this installation works on, which narrows what people see after connecting their own Jira), Jira status updates, PR follow-up, alerts (Slack/Teams/email), budgets, data guard, risk approvals, single sign-on, webhooks, model routing, limits, browser proof, memory, sandbox/isolation, checkpoints, shadow mode.
• Users: add people and roles (with SSO, roles come from groups). Audit log: every sign-in, change and action.
• Health: readiness, toolchain, budgets, recent alerts, supervisor status.

Teams: teach SprintFlow your repository (optional)#

Commit a .sprintflow/ folder to the repository. Everything is optional; SprintFlow detects the rest.

# .sprintflow/config.yml
test: dotnet test CPH.sln --logger trx --results-directory "$SPRINTFLOW_REPORTS"   # override detection
image: registry.company.com/cph-build:8.0        # container image for isolated builds
components:                                        # monorepo: build/test only what changed
  - {name: payroll, path: src/Payroll, test: "dotnet test tests/Payroll.Tests", depends_on: [shared]}
  - {name: shared, path: src/Shared, test: "dotnet test tests/Shared.Tests"}

Plus rules/*.md (coding rules), guides/*.md (how the codebase works), prompts/*.md (extra instructions per step, e.g. e2e.md for how to log in to the app for browser proof). See examples/team-knowledge/.

Command line#

sprintflow run PAY-123 [--dry-run]         sprintflow resume|approve|reject <run_id>
sprintflow status [run_id]                 sprintflow poll            # answers, approvals, PR follow-ups
sprintflow pilot check [--baseline]        sprintflow eval harvest|run|compare
sprintflow worker                          sprintflow supervise [--once]
sprintflow backup create|verify|restore    sprintflow memory show|consolidate|forget
sprintflow auth status|aws-login           sprintflow console serve|user add|init-key|rotate-key|import

FAQ#

• Will it merge or push to main? No. It pushes only to its own branch and opens a draft PR/MR.
• Does it see personal data? Personal data and secrets are replaced with placeholders before anything reaches the model; credential files are never shown.
• What if it's wrong? Review catches it, the PR is a draft, and you can reject at any checkpoint. Your review comments become lessons for future runs.