Skip to main content

Workflows

What is the Workflows feature?​

The Workflows feature allows you to save repeated prompts and manually use them when appropriate. A workflow is a simple Markdown file that you add to your prompt via the input area. This allows you to reuse effective pipelines and boost your productivity.

A workflow can be either global or local:

  • Global workflows are stored in the .explyt folder in your home directory and shared across all projects on your local machine.
  • Local workflows are stored in the .explyt folder in your project directory and visible only in that project. You can commit some of the project workflows via VCS if you want to share effective solutions with your colleagues.

To create a workflow, follow these steps:

  • Open a new chat
  • Open the workflow creation dialog
  • Enter a filename, choose whether the workflow is local or global, and press OK
  • In the opened file, add the Markdown content of your workflow

To add a workflow, start typing #workflow in the input area — a hint with available options will appear.

Interface for working with workflows​

When you open a new chat you will see a list of all system workflows. You can launch any workflow from the list by clicking the run button to the left of its name.

If you click a workflow name, the full workflows window opens. You can also open it at any time by clicking the Workflows icon at the top of the agent chat.

Filtering and searching workflows​

On the left side of the workflows window you will find both standard workflows and the ones you created, along with their tags. Use the filter on the left to select workflows with the tags you need. You can also filter workflows by name at the top of the panel.

Running a workflow from the panel​

To start a workflow, click the run button on the right side of the panel.

Creating your own workflow based on an existing one​

To create your own copy of a workflow and adjust it to your needs, click Copy and Modify Workflow on the right side of the panel.

Learn more about workflows in the documentation here.

Recommendations​

A few tips to make your workflows even more effective:

  • Ask the agent to clarify the goal before moving to implementation
  • Describe how the agent should gather context for the request
  • Specify the expected steps the agent should follow
  • Attach files to the request and reference them in the workflow when needed
  • Keep workflows reusable with placeholders (for example {goal}, {files}) and fill them in at launch time

Examples​

A workflow that asks the agent to find all TODOs in the attached files and implement them.

---
title: "Find and implement TODOs in the attached files (and in the currently open file, if relevant)"
tags: [todo, implementation]
---

Scope:
- Operate only on the attached files and the currently open file. If broader changes are needed, ask first.

Steps:
1) Analyze the provided files and list all TODOs with file path and line number.
2) Group TODOs by file/subsystem and identify dependencies or ordering.
3) Ask clarifying questions for ambiguous TODOs (author intent, constraints, acceptance criteria).
4) Propose a minimal, safe implementation plan with a file-by-file edit list and request approval.
5) Implement TODOs, keeping changes small and focused. Avoid unrelated refactoring.
6) After edits, summarize changes (files touched, key decisions, potential follow-ups).

Output:
- TODO inventory: table/bullets with file:line and short description.
- Questions (if any): bullets.
- Plan (awaiting approval): numbered steps.
- Edits: apply once approved, then provide a brief summary.

A workflow that asks the agent to add comments to the currently open file.

---
title: "Improve code readability by adding concise, precise comments without changing behavior"
tags: [readability, comments]
---

Scope:
- Modify only the currently open file unless the user approves changes elsewhere.

Steps:
1) Read the entire file to understand its purpose, public API, and complex logic.
2) Draft a commenting plan: file/header comment (if missing), doc comments for functions/classes, and inline comments for non-trivial logic or invariants.
3) Clarify style preferences if needed; otherwise follow the project conventions.
4) Add comments, keeping them precise and avoiding restating obvious code.
5) Provide a short summary: what was commented and why.

Constraints:
- Avoid changing program logic or formatting beyond what is necessary for the comments.
- Keep comments brief (typically 1–3 lines) and maintain a consistent tone.

Output:
- Comment plan (brief)
- Summary of comments added with rationale