Do one lesson a day. Each one adds a habit you will use for the rest of the rollout. Use real work where you can, and test data where you can’t.
1. Run two sessions in parallel
Keep one session open. Click + next to Sessions and start a second session in the same repository, in a new working tree. Give it an independent task. Switch between the two in the sidebar and review each one on its own. Each session gets its own branch and its own pull request.
Add missing unit tests for the module I am about to name. Do not change production code. Run the tests and report coverage before and after.
2. Ask the agent to split the work
Now let the agent start sessions for you. Pick a job with two or three parts that don’t touch the same files. Ask for one child session per part, or type /spawn with a single side task. Nested sessions show up under their parent in the sidebar. Review each one on its own, then ask the parent for a summary. Run work in parallel covers /fleet, /orchestrate and when not to split.
Split this into separate child sessions that run at the same time: (1) <first task>, (2) <second task>, (3) <third task>. Tell me as each one finishes, with a one-line summary and a link.
3. Work in a canvas without a repository
Start a chat, which has no branch or working tree. Attach a test CSV or a page of notes and ask for a result in a canvas. Canvases are shared artifacts that you and the agent edit together. Find the canvases you have under Canvas in Customize. If the Office canvases aren’t there for your account yet, ask the agent to write the file with a script instead.
Turn the attached notes into a one-page brief in a Word canvas with a summary, three decisions we need and open questions. Then build a five-slide PowerPoint outline from the same brief.
The starter prompt library has one prompt for each canvas.
4. Fix review comments and failing checks
Open My work and find one of your pull requests with review comments or a red check. Start a session from it, so the pull request context comes along.
Read the open review comments and the failing checks on this pull request. For each one, tell me what you will change, make the change, run the relevant tests and reply to the comment with a short summary.
5. Make your repository agent-ready
Add .github/github-app.yml so every new session starts with dependencies installed and knows how to run your project:
instructions: |
Use pnpm. Run `pnpm test` before proposing a pull request.
scripts:
- name: Setup
command: pnpm install
triggers:
- session.create
- name: Run
command: pnpm dev
server_ready_pattern: '(?i)Local:\s+(https?://\S+)'The app asks you to review and accept the file before it applies it. Scripts run with GitHub credentials, so read every command first. See repository configuration for every option.
Look at how this repository installs dependencies, runs tests and starts a dev server. Propose a .github/github-app.yml with setup and run scripts and short instructions. Explain each line and do not include secrets.
6. Get a second opinion before you merge
The rubber duck agent reviews your plan, code or tests on a different model and returns concrete feedback. Ask for it on your next real change, then run a security check.
/rubber-duck Critique the current implementation and tests. List the three riskiest assumptions and what would prove each one wrong.
/security-review
7. Save your first automation
Open Automations in the sidebar and click New automation. Choose the Manual trigger for now, write the prompt, pick the project and click Create and run. Next month you will put it on a schedule.
List my open pull requests in this repository. For each one, show review status, failing checks and how long it has waited. Suggest the one I should unblock first.
See using automations for triggers and cloud options.