Investigate why the test suite is flaky on CI. Run the failing tests repeatedly to reproduce the failure, identify the root cause, and fix it without disabling or skipping any tests. Summarize the cause and the fix when you are done.
Outcome: A root-cause summary and a fix, produced while you focus on other sessions.
Read the linked issue and the code it touches. Propose a plan that lists the files you will change, the approach, and the tests you will add or update. Wait for my approval before writing code. After approval, implement the change, run the relevant tests, and open a pull request that follows the repository template.
Outcome: A reviewed plan, a passing change on its own branch and a pull request linked to the issue.
Address every unresolved review comment on this pull request. For each comment, make the change or explain why you disagree. Then fix any failing CI checks, run the affected tests locally, and push the updates.
Outcome: Review threads answered, checks green and a short summary of what changed.
Before implementing, ask the rubber duck agent to review your plan for logic errors, missed edge cases, and simpler alternatives. Incorporate its feedback and show me the revised plan.
Outcome: A plan that has already been challenged once, with risks called out.
Create .github/github-app.yml for this repository. Add short instructions that capture our conventions, a Setup script that runs on session.create, a Run script that starts the dev server, and a server_ready_pattern that matches the dev server URL. Read the README and package scripts to choose the right commands.
Outcome: A reviewed config file that makes new sessions start ready to build, test and preview.
List my open pull requests in this repository. For each one, report CI status, unresolved review threads, and whether it has merge conflicts. Put anything that needs my action first.
Outcome: A prioritized briefing waiting in the app each morning.
Upgrade the project to the latest major version of our test framework. Follow the official migration guide, update configuration and affected tests, run the full test suite until it passes, and summarize any behavior changes reviewers should know about.
Outcome: A completed upgrade branch built and tested off your machine.
Check for outdated dependencies, upgrade patch and minor versions, run the full test suite and open one pull request with the upgrades that pass. List any upgrade that failed and why.
Outcome: An upgrade pull request waiting each morning, built and tested in the cloud.
/orchestrate Rename getUserProfile to fetchUserProfile in <library repo> and release it as a minor version. Then update every caller in <service repo A> and <service repo B>. Use one child session per repository. Finish the library first, since the services depend on it. Open one pull request per repository, link them to each other and give me a table with each pull request and its CI status.
Outcome: Linked pull requests across repositories, made in the right order, with one table to review them from.
/fleet Implement the approved plan. Run the steps that do not depend on each other in parallel and keep the dependent ones in order. When everything is done, run the full test suite and summarize what each subagent changed.
Outcome: A multi-part plan done faster, with a per-subagent summary to review.
Investigations, reviews, research, design docs, triage, incident follow-up, planning, status updates, decks and data. Run them next to your coding sessions.
Investigate a bug before anyone writes a fix
Get a root cause and fix options first, so the fix you pick is the right one.
Here is a bug report and the error output. Reproduce the bug locally, trace the code path and find the root cause. Do not change any code yet. Report the steps to reproduce, the root cause with file and line references, two fix options with their trade-offs, and the test that would catch it.
<paste bug report and error output>
Outcome: A reproduced bug, a root cause you can check and a fix you choose on purpose.
Read this pull request and the code it touches. List problems in order of severity: correctness bugs, missing tests, risky changes, then readability. Give the file and line for each and a suggested review comment I can post. Do not push any changes.
Outcome: A severity-ordered list of review comments, ready for you to check and post.
/research Compare <option A> and <option B> for <what we need it to do>. Cover maintenance activity, license, performance, security history and migration cost from our current setup. Cite every claim and finish with a recommendation.
Outcome: A cited comparison and a recommendation you can paste into a design doc.
Draft a design doc for <change>. Read the code it touches first. Use these sections: context, goals and non-goals, current design with file references, proposed design, alternatives considered, rollout and migration, risks and open questions. Save it as docs/design/<name>.md and do not change any other files.
Outcome: A design doc draft with real file references, ready for review.
Compare the README and the docs folder against the current code. List every command, flag, configuration option or API the docs describe wrong or leave out. Fix them in one pull request, and run each command you document to make sure it works.
Outcome: One pull request that makes the docs match the code, with every command tested.
List open issues in <owner/repo> with the label <area> and no assignee. For each one, check whether the code still has the problem, suggest a label and a priority, flag likely duplicates with links and note missing reproduction steps. Do not edit any issues. Give me a table.
Outcome: A triage table you can act on in a few minutes.
Using the incident notes below and the pull requests merged in <owner/repo> between <start> and <end>, draft a post-incident review: timeline, impact, root cause, what went well, what did not and action items. Then draft one issue per action item with an owner placeholder. Do not create the issues until I approve them.
<paste incident notes>
Outcome: A post-incident review draft and a set of follow-up issues waiting for your approval.
Read <epic issue link> and the code it touches. Break the work into issues small enough for one pull request each. For each issue give a title, a description, acceptance criteria, the files it will likely touch and what it depends on. Mark which issues can run in parallel. Show me the list before you create anything.
Outcome: A reviewed set of issues, with the ones that can run side by side marked.
Draft my weekly update from the pull requests I opened, reviewed or merged in the last seven days and the issues I closed. Group them by project, one line each with a link. Keep it under 200 words and put anything blocked first.
Outcome: A status draft built from real activity, ready to edit and send.
Build the sprint review deck from merged pull requests in a PowerPoint canvas.
Office canvases: Availability variesCanvases
Office canvases: The Word, Excel and PowerPoint canvases may not be on for your account yet. If they are not in the Canvas view in Customize, ask the agent to write the .docx, .xlsx or .pptx file with a script and open it in Office.
Build a six-slide sprint review deck in a PowerPoint canvas from the pull requests merged in <owner/repo> in the last two weeks. Include one slide of highlights, one slide for each major change with what it does for users, one slide with the number of pull requests merged and one slide on what comes next. Keep each slide under 40 words.
Outcome: A sprint review deck drawn from what shipped.
Analyze a CSV of CI runs in an Excel canvas and get the changes that save the most time.
Office canvases: Availability variesCanvases
Office canvases: The Word, Excel and PowerPoint canvases may not be on for your account yet. If they are not in the Canvas view in Customize, ask the agent to write the .docx, .xlsx or .pptx file with a script and open it in Office.
Open the attached CSV of CI runs in an Excel canvas. Find the slowest jobs, the trend over the last 30 days and the tests that fail most often. Add a summary sheet and a chart, then suggest the three changes that would save the most time.
Outcome: A summary sheet, a chart and a short list of fixes ranked by time saved.
Vague prompts produce vague plans. Name the files, the constraint and how you will judge success.
Autopilot is great for well-scoped tasks. Use Plan mode when the approach is still open.
Check in when CI fails twice on the same check. Agents can loop on a red build, so read the failure yourself and give a concrete hint or take over.
Accept a repository configuration only after reading every script it runs.
Keep one task per session. Long, wandering sessions are harder to review.
Don't split work that touches the same files. Two parallel sessions editing one module will conflict at merge, so keep those in one session or run them in order.
