# Prflow > Use for direct Bitbucket pull-request and CI operations through atlas prflow, including PR discovery and review context, comments, approvals, merges, descriptions, retargeting, checks, pipeline status and logs, custom pipelines, and Renovate workflows. Use live command help for current flags. - Skill: `ayushgoel/prflow` (Agent Skill) - Install (CLI): `npx skillmds@latest add ayushgoel/prflow` - Raw SKILL.md: https://api.skillmd.com/api/skills/ayushgoel/prflow/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: ayushgoel (https://skillmd.com/u/ayushgoel) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ayushgoel/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 --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 ` for a configured named repository. 3. `--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: | Requested action | Command family | | --- | --- | | Add, reply to, close, or resolve a comment | `comment` | | Approve or remove approval | `approve` or `unapprove` | | Merge | `merge` | | Update title or description | `update-title` or `update-description` | | Change destination branch | `retarget` | | Sync with destination | `sync` | | Create, draft, ready, or decline | `pr` | | Enroll for merge when ready | `mogin` | 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 --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 --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 --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 --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.