Prompts

Prompts

Every session starts with instructions for its item and trigger. Fast Lane has a built-in one for each kind and for the triggers that need their own; you can replace any of them.

Built-in prompts

Key	Claude is asked to
pull_request	Review the PR: read it, check CI, run the build or tests if useful, and submit a review
pull_request:changes_requested	Read every review comment, make the changes on the PR branch, push, and reply to each comment
pull_request:checks_failed	Read the failing logs, fix the cause on the PR branch and push, or say the failure is unrelated
pull_request:conflict	Merge the base branch in, resolve the conflicts, test, and push (merging, so no force-push)
pull_request:commented	Respond to the comment: make the change asked for, or answer it
pull_request:mentioned	Reply to what the mention asks; make the change if the PR is yours
pull_request:pushed	Review what the new commits changed
issue	Triage: reproduce bugs, fix small ones on a branch with a test and open a PR, otherwise label and reply
issue:commented	Respond to the comment
issue:mentioned	Reply to what the mention asks
issue:assigned	Fix the issue on a new branch with a test and open a PR that closes it, or ask what's unclear
dependabot_alert	Upgrade the dependency on a new branch, run the tests, and open a PR (unless Dependabot already did)
code_scanning_alert	Decide whether the finding is real; fix it with a test and open a PR, or explain and dismiss it

Triggers without a prompt of their own (review_requested, ready_for_review, labeled, PR assigned) use their kind's, with a first line saying what triggered it, such as Triggered by: review requested. The full text is in internal/prompt/prompt.go.

The prompts say what to do, not what needs permission. Whether Claude may push, comment or merge without asking comes from the session's allowed actions, which Fast Lane adds to Claude's system prompt.

Changing them

• For one rule: the rule's Prompt field on the Rules tab, or prompt in the rule. Applies to the sessions that rule governs.

• For a kind or trigger everywhere: Settings tab → Prompts, or prompts in config.json, keyed like rules:

  "prompts": {
    "issue": "Triage issue #{{.Number}} in {{.Repo}}: {{.Title}}\n\n{{.Body}}",
    "pull_request:checks_failed": "CI failed on {{.HeadSHA}}. Fix it on the PR branch."
  }

The first one set wins: the rule's prompt, then prompts for the kind and trigger, then the built-in one for it, then prompts for the kind, then the built-in one for the kind. Both editors open on the template that currently applies; saving it unchanged stores nothing, so you keep getting improvements to the built-in one. ctrl+r in the rule's prompt editor, or r in the Prompts list, goes back to the built-in.

When you start a session by hand, you see the rendered prompt and can edit it just for that session.

Template fields

Prompts are Go text/templates. Fields that don't apply to an item are empty.

Field	Is
.Repo, .Number, .Title, .URL, .Body	The item
.Kind	pull_request, issue, dependabot_alert or code_scanning_alert
.Author, .Bot	Who opened it, and whether that's a bot
.Labels	Its labels
.CreatedAt, .UpdatedAt	When it was opened and last updated
.Severity	Alert severity
.Branch, .Draft	PR branch, and whether it's a draft
.HeadSHA, .HeadAuthor	PR head commit and its author
.Checks	CI on the head commit: SUCCESS, FAILURE, ERROR or PENDING
.Mergeable	MERGEABLE, CONFLICTING or UNKNOWN
.ReviewDecision, .ReviewRequests	APPROVED, CHANGES_REQUESTED or REVIEW_REQUIRED, and who's asked to review
.Trigger	What started the session, such as checks_failed
.Actor	Who caused it, such as the reviewer or commenter
.Detail	The comment or review text, the labels added, or the commit

Text such as {{if .Draft}}…{{end}} and {{range .Labels}}…{{end}} works as in any Go template. A template that doesn't parse is refused when you save it.