Every prompt, one page

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.

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.

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.

/security-review

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.

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.

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.

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.

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.

/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.

/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.

Turn on agent merge for this pull request. Address review comments, fix failing checks and resolve merge conflicts. Do not merge until I confirm.

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>

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.

/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.

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.

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.

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.

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>

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.

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.

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.

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.

Turn the notes below into a one-page product spec with these sections: problem, target users, goals, non-goals, proposed solution, success metrics, risks, and open questions. Flag any claim in the notes that lacks evidence.

<paste notes here>

Using the connected work data source, collect the last two weeks of discussion about <topic> from our team channel and meeting notes. Summarize decisions, open questions and customer evidence with names removed. Then draft a one-page spec as a Word document and a five-slide summary deck. Show me the outline first.

Build a quick prototype of the following change so I can try it in the browser: <describe the change>. Keep it on this branch only, favor speed over polish and use fake data where real data would slow you down. Start the dev server when done, open the page in the browser canvas and list what is stubbed.

Review issues opened in the last 24 hours. For each one, suggest a label from our existing labels, flag likely duplicates with links, and note any that are missing reproduction steps. End with a three-line summary of themes.

Collect feedback from the last 30 days: open issues labeled feedback, repository discussions and <connected channel, if approved>. Remove customer and personal names. Group items into themes with a count, two representative quotes with links and a suggested next step. Match each theme to an existing issue where one exists. Show me the table, then open issues only for the themes I approve.

I have a launch review on Friday. Start three child chats that run at the same time. (1) Triage the attached feedback export into themes with counts and the top five issues. (2) Research how teams in our space describe <problem>, with cited sources. (3) Draft a six-slide review deck outline. When the first two finish, fold their findings into the deck and show me one summary with links to all three.

Open the attached CSV in an Excel canvas. It is <describe the data, for example weekly active users by feature and plan>. Answer: <your question>. Show the formulas or pivot you used, chart the result, and tell me which caveats in the data could change the answer.

Create a PowerPoint deck for <audience> about <topic> from the spec and data below. Use 8 slides or fewer, one message per slide, with the message as the slide title. Add speaker notes. Then review the deck as a skeptical <audience member>: list weak claims, missing data and slides to cut, and fix them.

<paste or attach spec and data>

From the meeting notes below, propose a list of issues to create. Use the feature request template for new work and the bug template for defects. Show me the list for approval before creating anything.

<paste notes here>

Summarize the pull requests merged into main since the last release tag. Group them into New, Improved, and Fixed. Write each entry for customers rather than engineers, and skip internal refactors and test-only changes.

Draft this week's team status update. Include shipped work from merged pull requests, notable issues opened or closed, anything blocked for more than five days, and next week's focus based on open milestones. Keep it under 250 words.

Build a variant of the <page or component> that follows this direction: <describe direction>. Reuse our existing design tokens and components. Do not change shared components. Start the dev server when done so I can compare it in the browser.

On the <page>, align spacing to our 4px scale, add hover, focus and disabled states to every interactive element, and make empty and loading states match our design system. Show me each change in the browser before moving on.

Audit <page> for WCAG 2.2 AA issues. Check color contrast in light and dark modes, labels on form controls and icon buttons, heading order, focus visibility and keyboard traps. Fix what you can, and list anything that needs a design decision.

Search the codebase for hard-coded colors, font sizes and spacing values that should use design tokens, and for components that duplicate ones in our design system. Group findings by area and propose a migration plan. Do not change code until I approve.

Open an editor canvas with a draft interaction spec for <feature>. Cover entry points, states, error handling and copy. I will edit alongside you, so reread the document before each change.

Read the pull requests merged since <date or tag> that touch <area>. Write a launch brief with the audience, the problem, three messaging pillars with proof points linked to the PRs, and anything that is not ready to talk about yet.

Draft an 800-word blog post announcing <feature> for <audience>. Base every technical statement on the code and docs in this repository. Include a short getting-started snippet that you have run. Outline first and wait for my approval.

Create a PowerPoint deck from the launch brief above: title slide, problem, three pillar slides with proof points, a demo slide and a call to action. Keep text to three bullets per slide and add speaker notes.

Update the copy on <page> to match this message: <message>. Keep the existing layout and components. Start the dev server and open the page so I can review the change before you commit.

Create a minimal demo app in a new folder that shows <feature> in under two minutes of screen time. Seed realistic sample data, make the happy path work end to end, and write a numbered demo script in DEMO.md.

Draft changelog entries for pull requests merged in the last 7 days that change user-facing behavior. Write one or two sentences each in plain language and link the PR. Skip internal and test-only changes.

Open the attached CSV of customer reviews in an Excel canvas. Add columns for sentiment and theme, build a pivot of themes by month, and chart the top five themes. Tell me which rows you could not classify and why.

Using the attached data, build a workbook with a monthly forecast for the next two quarters, a tab that explains the method in plain language, and a dashboard sheet with charts. Then wait for my changes.

From the notes below, create a one-page Word memo, a three-slide PowerPoint summary and an Excel tracker of action items with owner, due date and status columns.

<paste notes here>

Help me set up a project that answers questions about <data source>. Draft project instructions that describe the tables, define our key metrics and require every answer to cite the table and query it used. Add a README with five example questions.

Using the connected work data source, collect the last two weeks of discussion about <topic> from our team channel and meeting notes. Summarize decisions, open questions and owners, then draft a Word document. Show me the outline first.

Using the connected CRM, give me a one-page brief on <account>: open opportunities with stage, amount and close date, the last three activities, key contacts by role and any risks noted in the record. Flag fields that look out of date. Do not change any records.

I have meetings tomorrow with <account A>, <account B>, <account C> and <account D>. Start one child session per account and run them at the same time. Each one writes a one-page brief: open opportunities, recent activity, key contacts by role and risks, from the attached exports or the connected CRM. Do not change any records. When all four are done, give me a table with each account, its biggest risk and a link to its brief.

From the attached opportunity export (or the connected CRM), open an Excel canvas with my open opportunities this quarter. Add columns for days in stage and days since last activity. Highlight deals with no next step, a close date in the past or no activity in 14 days, and chart pipeline by stage.

Create a PowerPoint deck for <account type, for example a mid-size retailer> from the discovery notes and approved product material below. Use 8 slides or fewer: their goals in their words, current challenges, how we help, proof points, rollout plan and next steps. Add speaker notes. Use only claims from the approved material and list any you could not support.

<paste notes and material>

Using the connected CRM, collect feedback for <account> from the last 6 months: cases, call notes and activity comments. Group it into themes with dates and one short quote each. Separate product gaps from service issues, and list any feedback that already has a linked product issue.

Turn the call notes below into a short recap email: what we heard, what we agreed and next steps with owners and dates. Keep it under 150 words and match a friendly, direct tone. Then list the CRM fields I should update.

<paste notes>

List open pull requests in this repository that have waited more than 24 hours for a first review or more than 48 hours since the last update. Group by author, show requested reviewers, and suggest who could review based on recent changes to the same files.

Collect feedback from <Teams or Slack channel> and errors from <error tracker> for the last 24 hours. Group them into distinct problems, match each to an existing issue or open a new one, and investigate the top three. For any with a clear fix, open a pull request with a test and confirm CI passes. Report what you did and what needs a human.

Read the design doc below and the code it affects. Propose a breakdown into issues of one to three days each, with acceptance criteria, dependencies and a suggested order. Show me the list before creating anything.

<paste design doc>

Look at issues and pull requests from the last 60 days and find recurring manual chores, such as dependency bumps, flaky test reruns or release checklists. Rank them by how often they happen and propose an automation prompt for the top one.

Write an onboarding guide for a new engineer joining this repository. Cover the architecture, how to build and test, the five most important directories, common pitfalls from recent bug fixes and three good first issues that are open now.

Draft my weekly team update. Include work shipped, work in review, anything blocked, risks to the current milestone and one highlight per person based on their merged pull requests. Keep it under 300 words.

Reproduce the bug in the linked issue. Follow the reported steps, then try likely variations. If you reproduce it, write a minimal failing test and stop. If you cannot, list what you tried and the information to ask the reporter for.

Create a sample in <language> that shows how to <task> with our SDK. Keep it under 60 lines, add comments only where the API is surprising, run it against the test environment and add a README with setup steps.

Write a developer blog post about <topic> for <audience>. Build the sample first in a samples/<slug> folder and run it. Pull every code snippet in the post from that sample, so nothing is untested. Include prerequisites, the steps, the expected output and a "what to try next" section. Keep it under 1,200 words.

Read the release notes for <version>. Create three child sessions that run at the same time. (1) Build and run a sample in samples/<slug> that shows the headline feature. (2) Draft a blog post that pulls every snippet from that sample once it passes. (3) Write a five-post social thread with alt text for any images. Open one pull request for the sample and the post, and put the thread in a Markdown file for me to review.

Plan a 90-second video that shows <feature>. First write the script with timings and a shot-by-shot storyboard, and wait for my approval. Then build it as a Remotion project in videos/<slug>: title card, screen captures I provide in assets/, captions from the script and an end card. Render it to MP4 and use ffmpeg to make a 30-second cut for social.

Open the attached export of social posts that mention <product> from the last 7 days. Remove usernames. Group posts into themes with a count, overall sentiment and two representative quotes each. Flag bug reports and link any that match an existing issue. Draft a reply for the three posts that most need one, for me to review and post myself.

Compare the docs page <path> with the current implementation. List every place where the docs are wrong, missing or out of date. Then update the page, and preview it if the docs site has a dev server.

Read the last 24 hours of <Slack or Teams channel> and recent errors from <error tracker>. Group reports that describe the same problem, link each group to an existing issue or open a new one with steps and quotes, and post a short summary of what you filed.

Summarize the support and discussion threads from the last 7 days. List the top five questions by volume with links, the docs or product change that would remove each one, and any quotes worth sharing with customer details removed.

/security-review

Review .github/github-app.yml in this repository. For each script, explain what it runs, what network and credential access it needs, and whether it downloads and executes remote code. Flag anything that should require security sign-off and propose safer alternatives.

Based on this repository's build, test and dev server needs, recommend whether sessions should default to a local sandbox or a cloud sandbox. List the network hosts and file paths the agent needs, and anything that should stay blocked.

Review this automation prompt and list the minimum tools it needs to succeed. Mark each tool as read or write, explain why it is needed, and suggest how to split the automation if write access is only needed for one step.

<paste automation prompt>

A team wants to add the <name> connector. Summarize what data it can read and write, how it authenticates, where data leaves our network and what a misused prompt could do with it. Recommend approve, approve with limits or reject.

Find dependencies in this repository with known vulnerabilities. Upgrade each to the lowest fixed version, run the test suite after each upgrade, and stop to report if an upgrade needs code changes beyond a few lines.