Practical workflow in Claude Dispatch: Code & Development

Code evaluation from the training stage

Quick summary : In Lesson 3 , we mapped out what Dispatch can access—your entire file system, Global instructions, and (some) connectors. Now, let's use that access for practical development work.

Saturday morning. You're on a train visiting family. Your phone rings – a colleague has pushed a PR request that needs approval before deployment on Monday. The changes involve the authentication module. Normally you'd need your laptop for this.

With Claude Dispatch , you don't need to.

The key takeaway from Dispatch's developer workflow is that it works surprisingly well for read-intensive tasks and surprisingly poorly for write-intensive tasks. The key is to know which is which and structure your tasks accordingly.

Workflow 1: Review Pull Requests (PR)

PR review is a strong point of Dispatch for developers. It mainly involves reading, analyzing, and providing feedback—exactly what Dispatch handles well.

Step 1: View the summary

Hãy xem PR mới nhất trong ~/projects/my-app. Cho tôi biết những file nào đã thay đổi, có bao nhiêu dòng được thêm/xóa và tóm tắt bằng một đoạn văn về những gì PR này thực hiện.

This is a read operation. It will be successful in most cases.

Step 2: Go into detail

Based on the summary, ask about the most important files:

Cho tôi xem những thay đổi trong src/auth/login.ts từ PR mới nhất. Tập ​​trung vào các thay đổi liên quan đến bảo mật.

 

Step 3: Check for suspicious signs.

Trong các file được thay đổi bởi PR này, có bất kỳ: - Thông tin đăng nhập hoặc API key được hardcode - Truy vấn SQL không có tham số hóa - Thiếu xử lý lỗi trong các hàm bất đồng bộ - Các câu lệnh Console.log cần được xóa

Step 4: Provide feedback

Dựa trên đánh giá của bạn, hãy viết phản hồi về PR. Hãy cụ thể về số dòng và đề xuất sửa lỗi code khi thích hợp. Định dạng theo kiểu bình luận của GitHub.

Pay attention to the model: 4 simple, focused steps. Not one big command like "review this PR and give me feedback." Each step succeeds independently, and if step 3 fails, you still get results from steps 1 and 2.

Quick check : Can you describe your own PR review process in 3-5 simple steps? If each step is a single read or analysis operation, it will work well in Dispatch. If any step requires complex operations with multiple files, save that step for your own work.

Workflow 2: Searching for the codebase

You're at a conference. Someone mentions a design template that you think you implemented last month but can't remember where. Pull out your phone:

Tìm kiếm trong codebase ~/projects/api-server của tôi các file triển khai mẫu thử lại với độ trễ theo cấp số nhân. Cho tôi xem đường dẫn file và các code snippet liên quan.

Or more specifically:

Tìm tất cả các file trong ~/projects/api-server/src nhập lớp RateLimiter. Liệt kê từng file và chỉ ra cách chúng được sử dụng.

Searching the codebase is simply a matter of reading. Dispatch handles this reliably. And it's really useful when you're not at your desk and need a quick reference to something.

A helpful tip for search tasks: Be specific about the folder. Searching your entire home folder will be slow and may time out. Show Claude the project folder instead.

Workflow 3: Build and CI/CD Status

If your project has a build system that Claude can activate via connectors or terminal commands:

Kiểm tra 3 lần chạy CI/CD gần nhất cho nhánh chính trong ~/projects/my-app. Cho tôi xem trạng thái và bất kỳ lỗi nào.

 

For repositories connected to GitHub:

Trạng thái của các lần chạy Workflow GitHub Actions gần đây nhất cho kho lưu trữ my-app là gì?

A word of caution : Activating builds via Dispatch works, but you're relying on both the reliability of Dispatch and the reliability of CI/CD. If an error occurs, diagnosing the cause from the phone will be more difficult than when you're sitting at a computer. Use Dispatch to check build status (read operation) more confidently than to activate builds (write operation).

If you activate a build:

Chạy lệnh `npm test` trong thư mục `~/projects/my-app` và cho tôi xem kết quả.

This command will require approval as it's a terminal command. Please approve it, and you will receive the test results on your phone.

Workflow 4: Analyzing the log

An error has occurred in the production environment, and you need to check the logs. You're not near the computer. This is where Dispatch really comes in handy:

Đọc 100 dòng cuối cùng của file `~/projects/my-app/logs/error.log` và tóm tắt các loại lỗi phổ biến nhất. Có bất kỳ mẫu lỗi mới nào trong giờ qua không?

Or search more specifically:

Tìm kiếm trong thư mục ~/projects/my-app/logs/ bất kỳ nhật ký nào chứa từ khóa "timeout" hoặc "connection refused" từ hôm nay. Hãy cho tôi xem timestamp và toàn bộ mục nhật ký.

Log analysis is resource-intensive to read, but Claude excels at summarizing, and the results fit neatly into chat responses. This workflow has a high success rate and real value when you're troubleshooting remotely.

Workflow 5: Quick Code Changes

Dispatch can handle small, focused code changes. The keyword is "small".

Good for Dispatch:

Trong ~/projects/my-app/src/config.ts, hãy thay đổi giá trị API_TIMEOUT từ 5000 thành 10000 mili giây

Thêm chú thích TODO phía trên hàm processPayment trong ~/projects/my-app/src/billing.ts với nội dung "// TODO: Thêm logic thử lại cho các khoản thanh toán thất bại"

Not good for Dispatch:

Tái cấu trúc toàn bộ mô-đun xác thực để sử dụng code thông báo JWT thay vì cookie phiên. Cập nhật tất cả 15 file tham chiếu đến hệ thống xác thực.

The first example involves single-file operations, a single change. These will work. The second example is restructuring multiple files—exactly the kind of task that typically fails about half the time. If the restructuring fails on the 8th file out of 15, you have a faulty codebase.

General rule : If the change affects more than 2-3 files, leave it for later.

Workflow 6: Git Operations

Basic git operations work well through Dispatch:

Trạng thái git của ~/projects/my-app là gì? Cho tôi xem bất kỳ thay đổi nào chưa được commit.

 

Cho tôi xem 5 commit gần nhất trên nhánh chính của ~/projects/my-app cùng với thông báo commit và các file đã thay đổi.

Những nhánh nào tồn tại trong ~/projects/my-app và nhánh nào hiện đang được kiểm tra?

Git read operations are very reliable. Git write operations (commit, merge, rebase) trigger approval ports and sometimes work – but they are the kind that "need careful checking." If you're going to commit from Dispatch, review the diff first:

Cho tôi xem chính xác những gì sẽ được commit nếu tôi chạy git commit ngay bây giờ trong ~/projects/my-app

Then, only when it seems right:

Commit các thay đổi hiện tại trong ~/projects/my-app với thông báo "Sửa cấu hình timeout cho API thanh toán"

"Dispatch-friendly" prompt template

After working with Dispatch for a while, a pattern will emerge. Tasks that work effectively typically have the following characteristics:

1. Focus on one thing at a time - do only one thing at a time.
2. Demonstrates various reading operations - searching, summarizing, analyzing
3. Specific path - an exact reference to a file or folder.
4. Clear criteria for success - you can verify the results.
5. Independent - not dependent on the result of the previous order in the same message

Template for Dispatch tasks for developers:

[Động từ hành động] [mục tiêu cụ thể] trong [đường dẫn chính xác]. [Những gì cần hiển thị / Những gì cần thay đổi].

For example:

1. "Search for [pattern] in [path]. Show me [results]."
2. "Read [file] and tell me [question]."
3. "Change [value] in [file] to [new value]."

Maintaining this structure helps make your Dispatch tasks predictable and reliable.

Exercise: Build your development workflow

Create your own Dispatch workflow diagram:

1. List five development tasks you frequently perform that can be done through Dispatch.
2. For each task, write the specific prompt you will send.
3. Mark each task as "read" (high reliability) or "written" (pre-checked).
4. For write tasks, write a verification prompt (e.g., "Show me the file after changes").

Try out your prompts in Dispatch this week. Note which prompts work and which don't. That data will become a guide to your personal reliability.

Key points to remember

1. Considering PR is Dispatch's strength, let's break it down into 3-5 simple reading/analysis steps.
2. Search the codebase and analyze activity logs for reliable results, as these are read-only operations.
3. Small code changes, within a single file, work well; restructuring multiple files is unnecessary (leave that to your desk).
4. Reading data using Git is reliable, but writing data using Git needs careful testing.
5. Structure prompts into tasks focused on a specific path, and prioritize data reading for optimal results.
6. A reliability of around 50% for complex tasks means that breaking things down into simpler steps isn't an option—it's a strategy.

1. Question 1:

   When is Dispatch NOT suitable for development tasks?

   1. A. When you need to read log files
   2. B. When you need to search for function names throughout the entire codebase
   3. C. When you need to perform a complete multi-file restructuring, affecting more than 15 files simultaneously.
   4. D. When you need to check the Git status

   EXPLAIN:

   Complete multi-file restructuring is the kind of complex, multi-step operation where Dispatch's reliability of around 50% becomes problematic. If the restructuring process fails midway, you might end up with a codebase that's only partially modified. Save complex restructuring for when you're working at your desk. Dispatch is more efficient at reading, searching, and modifying individual files.

2. Question 2:

   What is the best approach to reviewing pull requests through Dispatch?

   1. A. Ask Claude to review and consolidate PRs with a single order – this might be applicable under very specific conditions, but is generally inefficient.
   2. B. Wait until you're sitting at your desk to review the code.
   3. C. First, ask Claude to summarize the changes, then review the specific files, and then provide feedback—step by step.
   4. D. Let Claude automatically approve all PRs.

   EXPLAIN:

   A step-by-step PR review process works best with Dispatch: first, get a summary of what has changed, then delve into specific files that seem interesting or potentially risky, and then provide feedback. This approach aligns with Dispatch's strengths (simple queries) and avoids its weaknesses (complex multi-step operations).

3. Question 3:

   Why should you break down complex development tasks into smaller steps when using Dispatch?

   1. A. Dispatch has character limits for prompts.
   2. B. Claude can only process one file at a time.
   3. C. Smaller tasks have a much higher success rate (~80-90%) than multi-step tasks (~50%), and if one step fails, you won't lose all your progress.
   4. D. Typing short text messages on a phone is faster – this would be great if true, but the evidence suggests a more complex story.

   EXPLAIN:

   Complex, multi-step tasks succeed about 50% of the time in Dispatch, while simpler, focused tasks succeed 80-90% of the time. Breaking down the work into steps also means that if step 3 fails, you still get results from steps 1 and 2. Never submit a 5-step task when you can submit 5 one-step tasks.

Submit your work

 

Cho tôi xem những thay đổi trong src/auth/login.ts từ PR mới nhất. Tập ​​trung vào các thay đổi liên quan đến bảo mật.