Prflow

PRFlow

Use atlas prflow as the authoritative interface for direct Bitbucket pull-request and pipeline work.

Tool Boundary

• PRFlow owns Bitbucket PR metadata, diffs, changed lines, comments, approvals, merge readiness, PR mutations, pipelines, failed logs, and Renovate actions.
• twg owns Jira, Confluence, people, ownership, goals, projects, and cross-product company context.
• Local git, rg, and repository-native build tools own local source changes, branches, and verification.

Use TWG to discover linked requirements or decisions, then return to PRFlow for the Bitbucket action.

Never persist private repository metadata, PR content, comments, pipeline logs, tokens, or downloaded artifacts in this skill source repository. Use the active project's ignored runtime directory or an explicit temporary directory.

CLI And Authentication

• Print the installed CLI version with atlas prflow version. Do not use atlas prflow --version.
• Use atlas prflow <command> --help before guessing current flags or a mutation contract.
• Use the configured authentication mode for routine work.
• Never provide a raw token through --token, command output, or chat.
• Do not run token setup, authentication switching, config changes, cache clearing, plugin installation, or credential repair unless the user asks.
• For requested authentication diagnosis, use auth mode, auth check, or the read-only auth smoke command before changing configuration.

Target The Repository

Prefer these target forms:

1. A full PR or pipeline URL, which identifies workspace, repository, and ID.
2. --repo-name <name> for a configured named repository.
3. --repo <workspace/repo> or an unambiguous configured repository slug.
4. The configured default only when it clearly matches the active task.

A numeric PR ID requires repository context. Never guess a repository, workspace, PR ID, branch, build number, or merge strategy.

Read And Mutation Boundary

• Listing, reviewing, checking, diagnosing, monitoring, and fetching logs are read-only.
• A request to review a PR does not authorize comments, approvals, commits, pushes, merges, retargeting, pipeline reruns, or other mutations.
• When the user explicitly requests a specific PR action, inspect current state and execute it without an extra confirmation.
• For broad, bulk, destructive, or ambiguous actions, first list or dry-run the exact candidate set. Execute directly only when the user's request clearly authorizes that set.
• Verify mutations with a follow-up PR or pipeline read and report the result.

PR Read And Review Workflow

1. Resolve the PR URL or ID and repository.
2. Start with pr review-bundle for metadata, readiness, checks, comments, changed files, and diff statistics in one read.
3. Use pr review-lines when exact destination line numbers are needed for findings or inline comments.
4. Use pr status for the concise merge-readiness view and pr checks for individual commit and compliance checks.
5. Use comment list --threads --unresolved-only or --actionable for current review work. Historical comments alone are not blockers.
6. Use agent diagnose or pr doctor when the user wants an agent-friendly diagnosis spanning checks, comments, pipeline state, and failed excerpts.
7. Hand code analysis to review-code, adding kotlin-code-reviewer for Kotlin.

Use JSON only when structured output materially reduces parsing or ambiguity. Do not collect the same PR state repeatedly through overlapping commands.

PR Actions

Use the narrow command and inspect its live help:

Before approving or merging, read pr status and pr checks. Surface failed or missing checks, open tasks, unresolved actionable threads, stale state, and destination-branch ambiguity. Do not bypass them unless the user explicitly requests the available override.

For comments:

• Use the top-level comment form for new workflows.
• Use the parent thread ID for replies and resolution.
• Anchor inline comments with pr review-lines.
• A listed historical or bot summary comment is not necessarily unresolved. Treat pr status, pr checks, and unresolved thread filters as authoritative for blockers.
• A response that a thread is already resolved is a successful final state.

Pipelines And Checks

Keep these surfaces distinct:

• pr checks is the source of truth for PR merge-blocking commit statuses.
• pipeline --pr-id <id> --repo <repo> --commit-statuses inspects PR merge-readiness.
• pipeline ... --pr-pipeline selects pull-request pipelines.
• pipeline ... --branch-pipeline selects branch or default pipelines for the PR source branch.
• pipeline --build <number> --repo <repo> identifies an exact pipeline run.
• trigger-pipeline starts an explicitly requested default or named custom pipeline on a branch.

Never pass a bare numeric target to pipeline. Use --pr-id for a pull request, --build for a build, or supply a full URL.

Use --follow-ws to wait for terminal state. It uses Bitbucket events and falls back to polling. Do not build sleep loops or JSON polling wrappers when the built-in follower is sufficient.

Starting, rerunning, pushing to retrigger, or starting a manual pipeline step is a mutation and requires an explicit request.

Failed Logs And Fix Loops

When a build fails:

1. Record the exact failed build number and intended pipeline surface.
2. Fetch that build with logs --build <number> --failed-only --summary.
3. Write logs to an explicit temporary or workspace runtime directory, never to the installed skill directory.
4. Inspect the actual failing step before proposing or making a code change.
5. Treat zero-duration pipelines with empty logs as selector, YAML, image, or setup failures until evidence points to application code.

When the user asks to fix until green:

1. Follow the current run with --follow-ws.
2. Fetch exact failed logs.
3. Apply the smallest justified change through write-code.
4. Run focused local verification.
5. Commit and push only as authorized by the request.
6. Follow the newly triggered run and repeat until green or genuinely blocked.

Stop after five consecutive code-fix cycles without convergence and report the repeated failure and evidence. Do not discard local or remote work to resolve a push rejection.

Renovate

• Use renovate list for read-only inventory and triage.
• For bulk approve, sync, decline, or repair requests, inspect the candidate set and current checks first.
• Treat conflicts, stale branches, failed checks, and dependency-specific code failures as separate conditions.
• Fix one failing dependency PR at a time unless the user explicitly requests parallel execution.
• After a fix, verify locally, push only when authorized, and follow PR checks until terminal.

Use live renovate <command> --help for the installed options. Do not preserve a static catalog of dependency-specific fixes in this skill.

Failure Handling

• Keep authentication, authorization, Bitbucket API, Git transport, PR state, and pipeline failures distinct.
• Retry only when the error is plausibly transient or the command contract was corrected.
• Stop after the same non-transient failure occurs twice and report the exact command family, target, error, and remediation.
• Never claim a PR is ready from a passing branch pipeline alone. Confirm PR checks and current commit state.