Built-in workflows

Rusty ships 12 profiles and 15 workflows, available in every project without any setup. The built-in ones are read-only: choose Customize a copy in the Behaviors tab to change one. For how workflows work in general, see Workflows.

On this page a step's profile is described by what it can do:

• Reads only. Reads the workspace (some also search the web). Cannot write files or run commands.
• Runs checks, never edits. Cannot write files. May run approved, non-destructive commands.
• Can change files.

Built-in profiles

Each profile has one responsibility, so a workflow can give each step only what it needs. A step's profile, not the chat's skill, sets its tools.

Profile	What it does	What it can do
Research	Investigates external sources and workspace context to produce sourced options and recommendations.	Reads only. Reads the workspace and searches the web.
Analyze	Explains how the current code works, where a change belongs, and what it may affect.	Reads only. Workspace only.
Plan	Turns requirements and code findings into an ordered implementation plan.	Reads only. Reads the workspace and searches the web.
Architect	Designs components, contracts, data flow and failure handling with explicit trade-offs.	Reads only. Reads the workspace and searches the web.
Debug	Reproduces failures, tests hypotheses and identifies the root cause.	Runs checks, never edits. May run approved commands to reproduce.
Build	Implements an approved change and checks the result before reporting.	Can change files. An edit must be followed by a check.
Verify	Independently checks completed work against the request, plan and actual workspace.	Runs checks, never edits. May run approved checks.
Review	Finds correctness and maintainability issues and returns prioritized, actionable feedback.	Reads only. Cannot run commands.
Security	Audits trust boundaries, data handling, dependencies and configuration for exploitable risks.	Reads only. Reads the workspace and searches the web.
Document	Creates accurate documentation and examples grounded in the current implementation.	Can write files; cannot run commands. Its instructions limit writing to documentation files.
Refactor	Improves internal structure while preserving observable behavior.	Can change files. An edit must be followed by a check.
Optimize	Improves measurable performance using baseline and after-change evidence.	Can change files. An edit must be followed by a check.

The read-only profiles that use an allow list are never even offered write_file. Verify, Debug and Document keep the session's tools and have a rule that denies the ones they must not use, so such a call is refused with a reason the agent sees. Every profile also has a completion check: the read-only and reporting profiles must have inspected the workspace before they can finish, and the editing profiles must check an edit before they do.

Stages

Stages are short runs of two steps that stop at a written result. Run the next stage in the same chat and it builds on that result. Auto can choose any of them. See Auto flows.

Research & analyze

Research → Analyze. Reads only.

Use it to understand how some existing functionality works, or to compare options, before deciding anything. Research gathers sourced options, trade-offs and a recommendation. Analyze then ties them to how your code actually works.

You get a research brief with sources, then an analysis with file and symbol references, the flow of data and control, risks, and the likely change surface.

Try: How does sync work, and what are my options for making retries safer?

With flow switching on, it can hand over to Debug & plan a fix or Security audit & fix plan.

Architect & plan

Architect → Plan. Reads only.

Use it to turn findings, or a clear requirement, into a design and then an ordered plan, before any code is written. Architect compares at least two alternatives and recommends the simplest design that fits. Plan turns the design into steps another session can carry out.

You get a design (components, contracts, data flow, failure behavior, alternatives rejected) and a plan of numbered steps, each naming the files and symbols to change and an observable acceptance check.

Try: Design the retry fix: one policy in the queue worker.

Hands over to: Research & analyze, Debug & plan a fix.

Debug & plan a fix

Debug → Plan. Cannot edit files.

Use it when something is broken: an error, a failing test, wrong behavior or a regression. Debug establishes expected versus actual behavior, finds the smallest reliable reproduction and names the root cause. Plan turns the recommended fix into steps. Nothing is edited.

You get a diagnosis (reproduction, evidence, hypotheses tested, root cause, the smallest safe fix, the regression test that should cover it) and a fix plan.

Try: Saving a file twice sometimes duplicates it. Find out why.

Hands over to: Research & analyze, Security audit & fix plan.

Security audit & fix plan

Security → Plan. Reads only.

Use it when you want to know whether code is secure. Security identifies the assets and trust boundaries, then inspects input handling, authentication and authorization, secrets, filesystem, network and command boundaries, dependencies and configuration. Plan orders the fixes by severity.

You get findings ranked by likelihood and impact, each with evidence, an attack scenario and a remediation, then a remediation plan.

Try: Audit the upload endpoint.

Hands over to: Debug & plan a fix.

Verify & review changes

Verify → Review. Cannot edit files.

Use it to independently check work that is already done, yours or an earlier run's. Verify inspects the workspace, runs appropriate checks and reports what it verified and what it could not. Review then looks for correctness problems, edge cases, regressions and missing tests.

You get a verdict and prioritized findings, each with a severity, the exact file and symbol, the impact and a concrete fix.

Try: Check the changes I just made to the sync queue.

Hands over to: Debug & plan a fix, Security audit & fix plan.

Build & verify

Build → Verify. Can change files.

Use it to carry out an approved plan, or a clearly scoped request, and have the result independently verified. If an earlier stage left a plan in the chat, Build treats its steps as a checklist. Otherwise it inspects the code and makes the focused change you asked for. Verify then checks the real workspace instead of trusting Build's summary.

You get a handoff that accounts for every step, the files changed and the checks that actually ran, and then a verdict.

Try: Go ahead and build it.

Because it can change files, Auto only suggests it and always asks first. It hands over to Debug & plan a fix or Security audit & fix plan.

Pipelines

Pipelines run a whole job. Auto never starts one by itself: choose one from the Mode menu.

Plan, build, verify

Plan → Build → Verify. The everyday default, for when the path is clear. Plan investigates read-only and writes a plan, Build implements it and checks its own edits, and Verify checks the result against the real workspace. It is the only built-in workflow that does not read the last result in the chat.

Hands over to: Research & analyze, Debug & plan a fix, Security audit & fix plan.

Analyze, plan & build

Analyze → Plan → Build → Verify. For changes to existing code, where understanding the current behavior matters most. Analyze explains how it works and where the change belongs.

Hands over to: Debug & plan a fix, Architect & plan.

Research, design & build

Research → Architect → Plan → Build → Verify. For features that rest on unfamiliar libraries, standards or architectural choices. Research provides sourced options, Architect turns the recommendation into a design, and Plan orders the work.

Hands over to: Debug & plan a fix, Security audit & fix plan.

Fix a bug

Debug → Plan → Build → Verify. Reproduces and diagnoses a failure, plans the smallest fix, implements it and verifies it.

Hands over to: Research & analyze, Security audit & fix plan.

High-risk change

Analyze → Plan → Build → Verify → Review. For security-sensitive code, shared utilities and broad changes. The independent Review at the end looks at the result after Verify has checked it.

Hands over to: Debug & plan a fix, Security audit & fix plan.

Security remediation

Security → Plan → Build → Verify → Security. Audit, fix, then re-audit. The first Security step finds and ranks the issues. The last one revisits each original finding and says whether it is resolved, partly resolved or still open, and looks for new issues the fix introduced.

Hands over to: Debug & plan a fix.

Refactor safely

Analyze → Plan → Refactor → Verify → Review. Improves structure without changing behavior. Refactor starts by stating the behavior that must not change and establishing a baseline, then works in small edits and re-runs the checks after them. Verify's main question is whether any observable behavior or public API changed.

Hands over to: Debug & plan a fix, Security audit & fix plan.

Optimize performance

Analyze → Optimize → Verify. Measured work. Analyze identifies the candidate bottlenecks and the metric worth measuring. Optimize captures a baseline, changes one thing and measures again. Verify re-runs the measurement and the correctness checks.

Hands over to: Research & analyze, Debug & plan a fix.

Write documentation

Analyze → Document → Review. Analyze understands what exists, Document writes documentation grounded in the code, and Review checks every claim, command and example against the implementation.

Hands over to: Research & analyze.

Where they live

The built-in workflows and profiles are part of the app, not files in your workspace, and appear in the Behaviors tab tagged Built-in. Their IDs start with rusty-ide.builtin.. A copy you customize is saved in .rusty/workflows/ and .rusty/profiles/. See Profiles & workflows for the format.