A workflow combines several 100xprompt capabilities into one repeatable play. On their own, agents, commands, skills, background tasks, and the scheduler each do a job; composed, they turn a ticket into a merged pull request, keep a flaky suite green, or refactor a pattern across hundreds of files while you do something else. This page is a cookbook. Each recipe is a complete play: a short intro, a diagram of how the pieces fit, and a <Steps> procedure you can adapt to your own repository. Read them top to bottom, or jump to the one that matches the job in front of you.

​
Learn the building blocks

Every recipe leans on a small set of reusable parts. Knowing the vocabulary makes the rest of the page click into place.

Agents

Focused personas with their own instructions, tools, and model. Delegate scoped work to a subagent to keep the main thread clean.

Commands

Reusable slash commands that package a prompt (and optional arguments) into a repeatable one-liner.

Skills

On-demand expertise - 100xprompt loads a skill’s playbook only when the task calls for it.

Background tasks

Long-running work that keeps going while you keep working, then reports back when it’s done.
Throughout this cookbook, 100xprompt opens an interactive session and 100xprompt run "…" executes a single prompt non-interactively - ideal for scripts, hooks, and scheduled jobs. Both accept the same building blocks: --agent, --model, --continue, and --session.

​
Understand the composition model

Most workflows follow the same shape. A primary thread orchestrates, delegates isolated chunks to subagents, offloads slow steps to the background, and - when the work should repeat - hands the whole thing to the scheduler.
Keep that picture in mind and every recipe below is just a specific arrangement of the same parts.

​
The recipes

Suppose you’ve been handed a ticket and want a reviewed, tested change without hand-holding every step. Let 100xprompt plan before it edits, verify continuously, and widen its checks only once the core change is green.
1

Give it the ticket verbatim

Paste the full ticket - acceptance criteria and all. Ask for a plan first, not code.
100xprompt
Here’s ticket PROJ-482. Before writing any code, explore the relevant modules and give me a short implementation plan with the files you’ll touch.
2

Review and lock the plan

Read the plan the way you’d read a design doc. Correct assumptions, point it at the right module, or add a constraint (“reuse the existing validation helper - don’t add a new one”). A good plan here saves ten corrections later.
3

Let it implement and self-verify

Approve the plan and let it edit. Point it at your real verification commands so it holds itself to your bar:
Implement the plan. Run npm test -- feature-flags.spec.ts after each change and don’t tell me it’s done until it’s green.
4

Widen the checks

Once the targeted test passes, have it run the broader net to prove nothing else broke.
npm test && npm run lint && npm run typecheck
5

Branch, commit, and open the PR

Ask it to create a branch, commit with a clear message, and open the pull request. It uses git and gh the way you would.
Create a branch, commit this, and open a PR that summarizes the change and links PROJ-482.
If your team follows a fixed feature checklist (changelog entry, migration note, test coverage), capture it as a command like /feature so every new feature starts from the same rails. See Commands.
Suppose your suite is red and you want it green. This is the ideal job for 100xprompt because the failure output is the specification. It reproduces the failure, reads the real error, patches, and re-runs - closing the loop until the suite passes.
1

Reproduce before touching anything

Start by having it run the suite so it sees the exact failures, not a description of them.
Run the test suite and show me which tests fail and why. Don’t fix anything yet - I want to see the failures first.
2

Decide code-bug vs. test-bug

Ask it to classify each failure: is the code wrong, or has the test drifted from intended behavior? This one question prevents it from “fixing” a test that was correctly catching a regression.
Be explicit that it should not weaken or delete assertions to make tests pass. Tell it: “If a test is correct, fix the code - never the test.”
3

Fix and re-run in a loop

Let it work through the failures one cluster at a time, re-running after each fix so it always knows where it stands.
npm test -- --reporter=dot
4

Confirm a clean full run

Once individual failures are handled, run the entire suite from scratch to catch order-dependent or cross-cutting breakage.
5

Offload slow suites to the background

If the full run is slow (an e2e or integration matrix), send it to the background and keep reviewing the diff while it runs. 100xprompt reports back the moment it finishes.
Long or never-ending commands are first-class background citizens - see Background Tasks for starting, monitoring, and collecting results.
Suppose you need to rename an API, migrate a pattern, or swap a library across dozens or hundreds of files - too many to hold in one head. The strategy: map first, change in reviewable batches, verify after each batch.
1

Map the blast radius

Before any edit, have it find every site the refactor will touch and report the count. This becomes your checklist.
Find every place we call the old formatDate helper across the repo and list the files grouped by directory. Don’t change anything yet.
2

Agree on the transformation rule

Nail down the exact before/after so the change is mechanical and consistent. Ambiguity at scale multiplies into hundreds of tiny inconsistencies.
For each site, replace formatDate(x) with dates.format(x) and add the import if missing. Leave commented-out code untouched.
3

Refactor in reviewable batches

Ask it to work directory-by-directory (or a fixed number of files at a time), running the build after each batch so failures surface early and stay small.
npm run build && npm test -- src/billing
4

Isolate risky work in a worktree or branch

For a sprawling change, keep it on a dedicated branch so main stays clean and the whole refactor lands as one coherent, reviewable unit.
5

Verify the whole tree, then summarize

Run the complete build, suite, and type-check. Then ask for a summary of what changed and any sites it deliberately skipped, so your reviewers know exactly what to look at.
For a truly massive migration, split the map into independent slices and hand each to a subagent running in parallel - see recipe 6. Each subagent owns one slice and reports its batch back to the primary thread.
Suppose your branch is ready and you want a first pass before a human reviews it. A dedicated review subagent reads the diff with fresh eyes and a critical mandate - surfacing bugs, dead code, and missed edge cases while your main thread stays focused on shipping.
1

Scope the review to your changes

Point it at the branch diff, not the whole repo, so the feedback is focused and fast.
100xprompt run --agent code-reviewer "Review the diff between this branch and main. Flag correctness bugs, missing tests, and anything I should clean up before opening a PR."
2

Ask for findings before fixes

Have the reviewer report issues first - grouped by severity - so you decide what’s in scope for this PR versus a follow-up. Not every suggestion belongs in the same change.
3

Apply the agreed cleanups

Back on the main thread, apply the fixes you accepted: remove dead code, tighten an edge case, add the missing test. Re-run the suite to confirm the cleanup didn’t regress anything.
4

Do a final self-check pass

A quick last sweep before you hand it off:
  • Debug logging and stray TODOs removed
  • New behavior actually covered by a test
  • Public-facing changes reflected in docs
  • Commit message and PR description explain the why, not just the what
5

Open the PR with a review-ready summary

Ask it to open the PR with a description that gives reviewers a map: what changed, why, how it was verified, and what to look at first.
Capture this whole play as a /pre-pr command so cleanup is one keystroke on every branch. If your organization ships a review agent as part of a plugin, it’s available to the whole team automatically.
Suppose there’s toil you do on a cadence - sweeping for outdated dependencies, triaging new issues, checking that the nightly build is green. Instead of remembering to do it, hand it to the scheduler: 100xprompt runs the job unattended and leaves you the results.
1

Write the task as a self-contained prompt

A scheduled run starts cold - no memory of a prior chat - so the prompt must stand alone. Include the goal, the commands to run, and what to produce.
Check for outdated dependencies with npm outdated. For any safe minor or patch bumps, update them, run the test suite, and if it’s green open a PR titled “chore: weekly dependency bumps.” If tests fail, open an issue with the details instead.
2

Pick the cadence

Schedules run once at a set time, on a simple recurring interval, or on a full cron expression for precise control.
CadenceUse it for
OnceA one-time reminder or a job that must run at a specific future moment.
EverySimple intervals - “every day,” “every 6 hours.”
CronPrecise timing - “8am every Monday,” “top of each hour on weekdays.”
3

Assign the right agent

Point the schedule at a purpose-built agent (for example, a maintenance agent with a tight tool set) so the unattended run has exactly the permissions it needs - and nothing more.
4

Create the schedule

Ask 100xprompt to set it up in plain language, or use the scheduling surface directly.
Schedule the dependency-bump task to run every Monday at 8am using the maintenance agent.
5

Review the output on your terms

Because the job opens a PR or files an issue, you review its work asynchronously - the automation does the toil, you keep the judgment.
Unattended runs act without you watching, so scope their permissions tightly. Give a scheduled agent only the tools it needs, keep destructive operations behind an explicit ask, and prefer “open a PR” over “push to main.” See Permissions.
The full model for creating, listing, and editing scheduled work - cadences, agents, and delivery - lives in Scheduling.
Suppose a question has several independent threads - “how does auth work, how does billing work, and how do they connect?” Running them one after another is slow. Fan the work out to subagents in the background, let them investigate in parallel, and have the primary thread synthesize their findings into one answer.
1

Split the question into independent slices

Fan-out only pays off when the slices don’t depend on each other. Have the primary thread break the question into parts that can be answered in isolation.
I need to understand three things independently: how login works, how invoicing works, and what data model both share. Investigate each in parallel and then reconcile them for me.
2

Delegate each slice to a subagent

Each subagent runs in its own context with a focused prompt, so a deep dive into one area never crowds out the others. Read-only research agents are perfect here - they explore and report without touching your code.
Use an agent whose mode is subagent for delegated work. Give it a narrow tool set (read and search, no edits) when the job is pure investigation.
3

Run them in the background

Kick the investigations off in the background so they proceed together. Your main thread stays responsive, and each subagent reports back as it finishes.
4

Collect and reconcile

The primary thread gathers every subagent’s findings and reconciles them - resolving contradictions and drawing the connections no single slice could see on its own.
5

Turn the synthesis into next steps

A good research pass ends as an action plan. Ask it to convert the combined findings into a plan you can feed straight into recipe 1.
Parallel research works because each subagent has its own context window. Ten focused investigations stay crisp where one giant conversation would blur. This is the same principle behind large refactors (recipe 3): isolate, run in parallel, then reconcile.

​
Compose your own recipes

Once the patterns click, you’ll see them everywhere. The reusable moves:

Plan before you edit

For anything non-trivial, get a plan and approve it. A corrected plan is cheaper than ten corrected edits.

Verify continuously

Point 100xprompt at your real test, lint, and type-check commands. “Done” should mean “a command I ran proves it.”

Delegate to stay focused

Push isolated or noisy work to a subagent so the main thread keeps a clean, sharp context.

Package what repeats

A prompt you type twice should be a command; a workflow you run weekly should be a schedule.
The fastest way to institutionalize a good workflow is to capture it once. Turn it into a command for your keyboard, a skill for on-demand expertise, or a schedule for unattended runs - then share it with your team as a plugin.
  • Best Practices: the habits that make every recipe here land more reliably.
  • Agents: build the reviewers, researchers, and maintainers these recipes delegate to.
  • Scheduling: put recurring maintenance on a cadence and let it run unattended.

Best Practices

The habits that make every workflow above land more reliably.

Agents

Build the focused personas - reviewers, researchers, maintainers - these recipes delegate to.

Scheduling

Put recurring maintenance on a cadence and let it run unattended.