Chuyển tới nội dung chính

{/* Trang này được tạo tự động từ SKILL.md của kỹ năng bởi website/scripts/generate-skill-docs.py. Chỉnh sửa nguồn SKILL.md, không phải trang này. */}

Người soạn nhạc Kanban

Cẩm nang phân tách + các quy tắc chống cám dỗ cho việc định tuyến hồ sơ người điều phối hoạt động thông qua Kanban. Quy tắc "không tự mình thực hiện công việc" và vòng đời cơ bản được tự động đưa vào lời nhắc hệ thống của mọi nhân viên Kanban; kỹ năng này là cẩm nang sâu sắc hơn khi bạn đặc biệt đóng vai trò người điều phối âm nhạc.

Siêu dữ liệu kỹ năng​

NguồnĐi kèm (được cài đặt theo mặc định)
Đường dẫn

skills/devops/kanban-orchestrator ` | | Phiên bản |

3.0.0 ` | | Nền tảng | Linux, macOS, Windows | | Thẻ |

kanban

, `multi-agent

, `orchestration

, routing | | Kỹ năng liên quan | XPROTECTX8XPROTECTX |

Tham khảo: đầy đủ SKILL.md​

thông tin

Sau đây là định nghĩa kỹ năng đầy đủ mà Hermes tải khi kỹ năng này được kích hoạt. Đây là những gì tác nhân coi là hướng dẫn khi kỹ năng được kích hoạt.

Kanban Orchestrator — Playbook phân rã`> Vòng đời của nhân viên cốt lõi (bao gồm mẫu phân xuất

kanban_create và quy tắc "phân tách, không thực thi") được tự động đưa vào mọi quy trình kanban thông qua khối nhắc nhở hệ thống `KANBAN_GUIDANCE

. Kỹ năng này là cẩm nang sâu sắc hơn khi bạn là người điều phối nhạc và toàn bộ công việc là định tuyến.

Hồ sơ do người dùng định cấu hình - không phải là danh sách cố định​

Các thiết lập của Hermes rất khác nhau. Một số người dùng chạy một hồ sơ duy nhất có thể thực hiện mọi thứ; một số điều hành một đội tàu nhỏ ( `Docker-worker

, `cron-worker

); một số điều hành một nhóm chuyên gia được tuyển chọn mà họ tự đặt tên. Không có danh sách chuyên gia mặc định — kỹ năng điều phối không biết hồ sơ nào tồn tại trên máy này.

Trước khi phân tán, bạn phải căn cứ vào việc phân rã trong các cấu hình thực sự tồn tại. Người điều phối âm thầm không tạo ra tên người được chuyển nhượng không xác định — nó không tự động sửa, không gợi ý, không quay lại. Vì vậy, thẻ được gán cho researcher trên thiết lập chỉ có Docker-worker sẽ nằm trong ready mãi mãi.

Bước 0: khám phá các hồ sơ có sẵn trước khi lập kế hoạch.

Sử dụng một trong những:​

Hermes profile list — in bảng cấu hình được cấu hình trên máy này. Chạy nó thông qua công cụ đầu cuối nếu bạn có; nếu không hãy hỏi người dùng.​

kanban_list(assignee="<some-name") — kiểm tra độ tỉnh táo của một tên duy nhất. Trả về một danh sách trống (chứ không phải lỗi) cho một người được chuyển nhượng không xác định, do đó, thao tác này chỉ xác nhận tên mà bạn đang xem xét.

  • Chỉ cần hỏi người dùng. "Bạn đã thiết lập hồ sơ gì?" là một lượt đầu tiên tốt khi mục tiêu cần nhiều hơn một chuyên gia.

Lưu kết quả vào bộ nhớ làm việc của bạn trong phần còn lại của cuộc trò chuyện. Hỏi lại mỗi lượt sẽ lãng phí một cuộc gọi công cụ.

Khi nào nên sử dụng bảng (so với chỉ làm việc)​

Tạo tác vụ Kanban khi bất kỳ điều nào trong số này là đúng:

  1. Cần có nhiều chuyên gia. Nghiên cứu + phân tích + viết là ba hồ sơ.
  2. Công việc sẽ tồn tại sau sự cố hoặc khởi động lại. Chạy lâu dài, định kỳ hoặc quan trọng.
  3. Người dùng có thể muốn xen vào. Con người trong vòng lặp ở bất kỳ bước nào.
  4. Nhiều tác vụ phụ có thể chạy song song. Phân nhánh để tăng tốc.
  5. Dự kiến ​​sẽ có sự xem xét / lặp lại. Hồ sơ của người đánh giá lặp lại trên đầu ra của người soạn thảo.
  6. Dấu vết kiểm tra rất quan trọng. Các hàng trong bảng sẽ tồn tại mãi mãi trong SQLite.

Nếu không có nào trong số đó áp dụng được — đó là một nhiệm vụ lý luận ngắn gọn chỉ thực hiện một lần — hãy sử dụng delegate_task hoặc trả lời trực tiếp cho người dùng.

Quy tắc chống cám dỗ​

Mô tả công việc của bạn có nội dung "định tuyến, không thực hiện." Các quy tắc thực thi điều đó:- Không tự mình thực hiện công việc. Bộ công cụ bị hạn chế của bạn thường không bao gồm terminal/tệp/mã/web để triển khai. Nếu bạn thấy mình "chỉ cần khắc phục vấn đề này một cách nhanh chóng" - hãy dừng lại và giao nhiệm vụ cho chuyên gia phù hợp.

  • Đối với bất kỳ nhiệm vụ cụ thể nào, hãy tạo một nhiệm vụ Kanban và giao nó. Mỗi lần.
  • Tách các yêu cầu nhiều làn trước khi tạo thẻ. Lời nhắc của người dùng có thể chứa một số luồng công việc độc lập. Trước tiên, hãy trích xuất các làn đó, sau đó tạo một thẻ cho mỗi làn thay vì gộp các công việc không liên quan vào một thẻ người triển khai duy nhất.
  • Chạy song song các làn độc lập. Nếu hai thẻ không cần đầu ra của nhau, hãy để chúng không liên kết để người điều phối có thể quạt chúng ra. Chỉ liên kết các phụ thuộc dữ liệu thực sự.
  • Không bao giờ tạo tác phẩm phụ thuộc dưới dạng thẻ sẵn sàng độc lập. Nếu một thẻ phải đợi thẻ khác, hãy chuyển parents=[...] trong lệnh gọi kanban_create ban đầu. Đừng tạo trước rồi nối sau, cũng đừng dựa vào văn xuôi như “chờ T1” bên trong thân.
  • Nếu không có chuyên gia nào phù hợp với các hồ sơ có sẵn, hãy hỏi người dùng nên tạo hồ sơ nào hoặc sử dụng hồ sơ hiện có nào. Không bịa ra tên hồ sơ; người điều phối sẽ âm thầm thả những người được giao không xác định.
  • Phân tách, định tuyến và tóm tắt — đó là toàn bộ công việc.

Cẩm nang phân tích​

Bước 1 - Hiểu mục tiêu​

Đặt câu hỏi làm rõ nếu mục tiêu không rõ ràng. Hỏi giá rẻ; tốn kém để sinh ra đội tàu sai.

Bước 2 - Phác thảo biểu đồ nhiệm vụ​

Trước khi tạo bất kỳ thứ gì, hãy phác thảo rõ ràng biểu đồ (trong phản hồi của bạn với người dùng). Hãy coi mọi quy trình làm việc cụ thể như một thẻ ứng viên:

  1. Trích xuất các làn đường từ yêu cầu.
  2. Ánh xạ từng làn đường tới một trong các cấu hình bạn đã khám phá ở Bước 0. Nếu một làn đường không phù hợp với bất kỳ cấu hình hiện có nào, hãy hỏi người dùng nên sử dụng hoặc tạo cấu hình nào.
  3. Quyết định xem mỗi làn đường là độc lập hay được kiểm soát bởi một làn đường khác.
  4. Tạo các làn đường độc lập dưới dạng thẻ song song không có liên kết gốc.
  5. Tạo thẻ tổng hợp/đánh giá/tích hợp có liên kết chính với các làn đường mà chúng phụ thuộc. Một đứa trẻ được tạo ra với cha mẹ chưa hoàn thiện sẽ bắt đầu trong `todo

; người điều phối chỉ quảng bá nó lên ready sau khi mọi phụ huynh hoàn thành.

Ví dụ về các lời nhắc sẽ xuất hiện (sử dụng tên hồ sơ giữ chỗ - thay thế bất cứ điều gì tồn tại trong thiết lập của người dùng):

  • "Xây dựng ứng dụng" → một thẻ cho hồ sơ định hướng thiết kế để định hướng sản phẩm/giao diện người dùng, một hoặc hai thẻ cho hồ sơ kỹ thuật để triển khai, cùng với thẻ tích hợp/đánh giá sau này nếu người dùng có hồ sơ người đánh giá.
  • "Sửa các trình chặn và kiểm tra các biến thể mô hình" → một thẻ triển khai cho các bản sửa lỗi trình chặn cùng với một thẻ khám phá/nghiên cứu để xác minh cấu hình/nguồn. Thẻ đánh giá cuối cùng có thể phụ thuộc vào cả hai.
  • "Nghiên cứu tài liệu và triển khai" → thẻ nghiên cứu tài liệu có thể chạy song song với thẻ khám phá codebase; việc triển khai chỉ chờ đợi nếu nó thực sự cần những phát hiện đó.
  • "Phân tích ảnh chụp màn hình này và tìm mã liên quan" → một thẻ cho hồ sơ có khả năng hiển thị để phân tích trực quan trong khi thẻ khác tìm kiếm cơ sở mã.

Những từ như "cũng", "cuối cùng" hoặc "và" không tự động hàm ý sự phụ thuộc. Chúng thường có nghĩa là "đảm bảo điều này được đề cập trước khi báo cáo lại." Chỉ liên kết các nhiệm vụ khi một thẻ không thể bắt đầu cho đến khi có đầu ra của thẻ khác.

Hiển thị biểu đồ cho người dùng trước khi tạo thẻ. Hãy để họ sửa nó - bao gồm tên hồ sơ thực tế nào sẽ sở hữu mỗi làn đường.

Bước 3 - Tạo nhiệm vụ và liên kết​

Sử dụng tên hồ sơ từ Bước 0. Ví dụ bên dưới sử dụng phần giữ chỗ

<profile-A

,

<profile-B

,

<profile-C ` — thay thế chúng bằng những gì người dùng thực sự có.

t1 = kanban_create(
    title="research: Postgres cost vs current",
    assignee="&lt;profile-A",  # whichever profile handles research on this setup
    body="Compare estimated infrastructure costs, migration costs, and ongoing ops costs over a 3-year window. Sources: AWS/GCP pricing, team time estimates, current Postgres bills from peers.",
    tenant=os.environ.get("Hermes_TENANT"),
)["task_id"]

t2 = kanban_create(
    title="research: Postgres performance vs current",
    assignee="&lt;profile-A",  # same profile, run in parallel
    body="Compare query latency, throughput, and scaling characteristics at our expected data volume (~500GB, 10k QPS peak). Sources: benchmark papers, public case studies, pgbench results if easy.",
)["task_id"]

t3 = kanban_create(
    title="synthesize migration recommendation",
    assignee="&lt;profile-B",  # whichever profile does synthesis/analysis
    body="Read the findings from T1 (cost) and T2 (performance). Produce a 1-page recommendation with explicit trade-offs and a go/no-go call.",
    parents=[t1, t2],
)["task_id"]

t4 = kanban_create(
    title="draft decision memo",
    assignee="&lt;profile-C",  # whichever profile drafts user-facing prose
    body="Turn the analyst's recommendation into a 2-page memo for the CTO. Match the tone of previous decision memos in the team's knowledge base.",
    parents=[t3],
)["task_id"]

`
``Khuyến mãi cổng 
`parents=[...]

 - trẻ em ở lại 
`todo
` cho đến khi mọi phụ huynh đạt đến 
`done

, sau đó tự động thăng cấp lên 
`ready

. Không cần phối hợp thủ công; bộ điều phối và công cụ phụ thuộc xử lý nó.

Nếu biểu đồ nhiệm vụ có các phần phụ thuộc, trước tiên hãy tạo thẻ gốc, ghi lại các id được trả về của chúng và đưa các id đó vào danh sách 
`parents
` của thẻ con trong lệnh gọi 
`kanban_create
` con. Tránh tạo tất cả các thẻ song song và liên kết chúng sau đó; điều đó tạo ra một cửa sổ nơi người điều phối có thể yêu cầu một đứa trẻ trước khi đầu vào của nó tồn tại.

### Bước 4 - Hoàn thành nhiệm vụ của riêng bạn

Nếu bạn được sinh ra dưới dạng một nhiệm vụ (ví dụ: hồ sơ người lập kế hoạch được chỉ định 
`T0: "investigate Postgres migration"

), hãy đánh dấu nhiệm vụ đó là đã hoàn thành bằng bản tóm tắt những gì bạn đã tạo:

`Python
kanban_complete(
    summary="decomposed into T1-T4: 2 research lanes in parallel, 1 synthesis on their outputs, 1 prose draft on the recommendation",
    metadata=&#123;
        "task_graph": &#123;
            "T1": \&#123;"assignee": "&lt;profile-A", "parents": []&#125;,
            "T2": \&#123;"assignee": "&lt;profile-A", "parents": []&#125;,
            "T3": \&#123;"assignee": "&lt;profile-B", "parents": ["T1", "T2"]&#125;,
            "T4": \&#123;"assignee": "&lt;profile-C", "parents": ["T3"]&#125;,
        &#125;,
    &#125;,
)

`

### Bước 5 - Báo cáo lại cho người dùngNói với họ những gì bạn đã tạo bằng văn xuôi đơn giản, đặt tên cho các cấu hình thực tế mà bạn đã sử dụng:`> Tôi đã xếp hàng 4 nhiệm vụ:
> - **T1** (

&lt;profile-A

): so sánh chi phí
> - **T2** (

&lt;profile-A

): so sánh hiệu năng, song song với T1
> - **T3** (

&lt;profile-B

): tổng hợp T1 + T2 thành khuyến nghị
> - **T4** (

&lt;profile-C

): biến T3 thành bản ghi nhớ CTO
>
> Điều phối viên sẽ đón T1 và T2 ngay bây giờ. T3 bắt đầu khi cả hai kết thúc. Bạn sẽ nhận được ping cổng khi T4 hoàn tất. Sử dụng bảng điều khiển hoặc 
`Hermes kanban tail &lt;id
` để theo dõi.

## Các mẫu phổ biến`**Fan-out + fan-in (nghiên cứu → tổng hợp):** N thẻ kiểu nghiên cứu không có cha mẹ, một thẻ tổng hợp có tất cả đều là cha mẹ.

**Triển khai song song + xác thực:** một thẻ người triển khai thực hiện thay đổi trong khi một thẻ trình khám phá/nhà nghiên cứu xác minh cấu hình, tài liệu hoặc ánh xạ nguồn. Thẻ đánh giá có thể phụ thuộc vào cả hai. Đừng bắt người triển khai phải xác minh không liên quan chỉ vì người dùng đề cập đến cả hai trong một câu.

**Đường ống có cổng:** 
`planner → implementer → reviewer

. 
`parents=[previous_task]
` của mỗi giai đoạn. Người đánh giá chặn hoặc hoàn thành; nếu người đánh giá chặn, người điều hành sẽ bỏ chặn bằng phản hồi và hồi sinh.

**Hàng đợi cùng hồ sơ:** N nhiệm vụ, tất cả được gán cho cùng một hồ sơ, không có sự phụ thuộc giữa chúng. Bộ điều phối tuần tự hóa - hồ sơ đó xử lý chúng theo thứ tự ưu tiên, tích lũy kinh nghiệm trong bộ nhớ của chính nó.

**Con người trong vòng lặp:** Bất kỳ tác vụ nào cũng có thể 
`kanban_block()
` chờ đầu vào. Người điều phối hồi sinh sau 

/unblock

. Chủ đề bình luận mang bối cảnh đầy đủ.

## Cạm bẫy`**Phát minh ra tên hồ sơ không tồn tại.** Người điều phối âm thầm không tạo ra những người được chuyển nhượng không xác định — thẻ chỉ nằm trong 
`ready
` mãi mãi. Luôn gán cho một hồ sơ từ khám phá Bước 0 của bạn; hãy hỏi người dùng nếu bạn không chắc chắn.

**Gộp các làn độc lập vào một thẻ.** Nếu người dùng yêu cầu hai kết quả độc lập, hãy tạo hai thẻ. Ví dụ: "sửa các trình chặn và kiểm tra các biến thể của mô hình" không phải là một tác vụ sửa lỗi; tạo thẻ người sửa lỗi/kỹ sư để sửa lỗi và thẻ người khám phá/nhà nghiên cứu để kiểm tra biến thể, sau đó tùy chọn xem xét cổng trên cả hai.

**Liên kết quá mức do cách diễn đạt.** "Cuối cùng hãy kiểm tra X" có thể vẫn song song với việc triển khai nếu X là cấu hình tĩnh, tài liệu hoặc khám phá nguồn. Chỉ liên kết nó sau khi thực hiện khi việc kiểm tra phụ thuộc vào kết quả thực hiện.

**Quên các liên kết phụ thuộc.** Nếu biểu đồ nhiệm vụ ghi 
`research -> implement -> review

, đừng tạo tất cả các nhiệm vụ dưới dạng thẻ sẵn sàng độc lập. Sử dụng các liên kết gốc để quá trình triển khai/đánh giá không thể chạy trước khi có thông tin đầu vào.

**Giao lại nhiệm vụ so với nhiệm vụ mới.** Nếu người đánh giá chặn với "cần thay đổi", hãy tạo một nhiệm vụ MỚI được liên kết từ nhiệm vụ của người đánh giá — đừng chạy lại nhiệm vụ tương tự với vẻ ngoài nghiêm khắc. Nhiệm vụ mới được giao cho hồ sơ người triển khai ban đầu.

**Thứ tự đối số cho các liên kết.** 
`kanban_link(parent_id=..., child_id=...)
` — cha mẹ trước tiên. Việc trộn chúng sẽ giảm tác vụ sai xuống 
`todo

.

**Không tạo trước toàn bộ biểu đồ nếu hình dạng phụ thuộc vào các kết quả trung gian.** Nếu cấu trúc của T3 phụ thuộc vào những gì T1 và T2 tìm thấy, hãy để T3 tồn tại dưới dạng nhiệm vụ "tổng hợp các phát hiện" với bước đầu tiên là đọc các bản chuyển giao gốc và lập kế hoạch cho phần còn lại. Người dàn nhạc có thể sinh ra người dàn nhạc.

**Kế thừa đối tượng thuê.** Nếu 
`Hermes_TENANT
` được đặt trong env của bạn, hãy chuyển 
`tenant=os.environ.get("Hermes_TENANT")
` trên mỗi lệnh gọi 
`kanban_create
` để các tác vụ con vẫn ở trong cùng một không gian tên.

## Giải cứu công nhân mắc kẹt

Khi hồ sơ công nhân liên tục gặp sự cố, ảo giác hoặc bị chặn do lỗi của chính nó (thường là: sai mô hình, thiếu kỹ năng, thông tin xác thực bị hỏng), bảng điều khiển Kanban sẽ gắn cờ nhiệm vụ bằng huy hiệu ⚠ và mở phần **Phục hồi** trong ngăn kéo. Ba hành động chính:
1. **Đòi lại** (hoặc 
`Hermes kanban reclaim &lt;task_id

) — hủy bỏ nhân viên đang chạy ngay lập tức và đặt lại tác vụ thành 
`ready

. TTL xác nhận quyền sở hữu hiện tại là ~15 phút; đây là con đường nhanh chóng ra ngoài.

2. **Chỉ định lại** (hoặc 
`Hermes kanban reassign &lt;task_id &lt;new-profile --reclaim

) — chuyển nhiệm vụ sang một hồ sơ khác (một hồ sơ tồn tại trong thiết lập này) và để người điều phối nhận nó cùng một nhân viên mới.
3. **Thay đổi mô hình hồ sơ** — bảng điều khiển in gợi ý sao chép-dán cho 
`Hermes -p &lt;profile model
` vì cấu hình hồ sơ tồn tại trên đĩa; chỉnh sửa nó trong một terminal, sau đó Xác nhận lại để thử lại với mô hình mới.Cảnh báo ảo giác xuất hiện trên các nhiệm vụ trong đó yêu cầu 
`kanban_complete(created_cards=[...])
` của nhân viên bao gồm các id thẻ không tồn tại hoặc không được hồ sơ của nhân viên tạo ra (cổng chặn quá trình hoàn thành) hoặc khi bản tóm tắt dạng tự do tham chiếu các id 
`t_&lt;hex
` không giải quyết được (quét văn xuôi tư vấn, không chặn). Cả hai đều tạo ra các sự kiện kiểm tra vẫn tồn tại ngay cả sau các hành động khôi phục - dấu vết vẫn còn để gỡ lỗi.