drive-pr
Can you now check the PR for coderabbit or other comments, check if they are valid and address them, if valid then do the fix and push, if not then reply to the comment and mark it as resolved
Also check the CI jobs, fix any failures, if failures are like unit, lint, typecheck or even integration, try running it locally to make sure its fixed first before pushing and waiting again on the CI
If a failure is pre-existing on main and not related to our code, it doesn't matter, fix it all the same, unless you're spending too much time trying to fix it and the scope creep would be too large, just fix it, a good boy scout always leaves the place cleaner than they found
Then, after any push, wait 4.5 min (just below your cache expiration) and check for new comments by coderabbit or CI issues to be addressed, if nothing new twice, then just relax
More from rogeriochaves/skills
browser-qa
Drive a real browser to QA a feature end-to-end as a user would. Loads the right mix of Playwright MCP, Claude-in-Chrome, and computer-use, plus the failure modes to avoid. Use whenever you need to verify a UI feature works in a browser, capture PR screenshots, repro a customer bug visually, or do end-of-task dogfooding before declaring something "done". This is the QA stage of orchestrate mode.
18orchestrate
Loads orchestrate mode — a disciplined delivery loop that enforces BDD specs in specs/, real integration tests (no mocks), PR CI and CodeRabbit babysitting, and mandatory end-user QA via computer-use or CLI dogfooding before anything is considered done. Use when starting any non-trivial implementation task, feature build, or delivery where you want the work driven from spec to proven-shipped state rather than stopping at "tests pass".
17