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. */}

Phát triển theo định hướng của đại lý phụ

Thực hiện kế hoạch thông qua các tác nhân phụ delegate_task (đánh giá 2 giai đoạn).

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/software-development/subagent-driven-development ` | | Phiên bản |

1.1.0 ` | | Tác giả | Đặc vụ Hermes (chuyển thể từ obra/siêu năng lực) | | Giấy phép | MIT | | Nền tảng | Linux, macOS, Windows | | Thẻ |

delegation

, `subagent

, `implementation

, `workflow

, parallel | | Kỹ năng liên quan | XPROTECTX16XPROTECTX, XPROTECTX17XPROTECTX, XPROTECTX18XPROTECTX |

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.

Phát triển theo hướng tiểu đại lý

Tổng quan

Thực hiện các kế hoạch thực hiện bằng cách cử các đại lý phụ mới theo nhiệm vụ với quá trình xem xét hai giai đoạn có hệ thống.

Nguyên tắc cốt lõi: Tác nhân phụ mới cho mỗi nhiệm vụ + đánh giá hai giai đoạn (thông số kỹ thuật rồi đến chất lượng) = chất lượng cao, lặp lại nhanh.

Khi nào nên sử dụng

Hãy sử dụng kỹ năng này khi:

  • Bạn có kế hoạch thực hiện (từ kỹ năng viết kế hoạch hoặc yêu cầu người dùng)
  • Nhiệm vụ chủ yếu là độc lập
  • Chất lượng và tuân thủ thông số kỹ thuật là quan trọng
  • Bạn muốn xem xét tự động giữa các nhiệm vụ`vs. thực hiện thủ công:
  • Bối cảnh mới cho mỗi nhiệm vụ (không nhầm lẫn từ trạng thái tích lũy)
  • Quá trình xem xét tự động phát hiện vấn đề sớm
  • Kiểm tra chất lượng nhất quán trong tất cả các nhiệm vụ
  • Subagent có thể đặt câu hỏi trước khi bắt đầu công việc`##Quy trình

1. Đọc và phân tích kế hoạch

Đọc hồ sơ kế hoạch. Trích xuất TẤT CẢ các tác vụ có đầy đủ văn bản và ngữ cảnh trả trước. Tạo danh sách việc cần làm:


# Read the plan
read_file("docs/plans/feature-plan.md")

# Create todo list with all tasks
todo([
\{"id": "task-1", "content": "Create User model with email field", "status": "pending"},
\{"id": "task-2", "content": "Add password hashing utility", "status": "pending"},
\{"id": "task-3", "content": "Create login endpoint", "status": "pending"},
])

`
``**Key:** Đọc kế hoạch MỘT LẦN. Trích xuất mọi thứ. Đừng yêu cầu các tác nhân phụ đọc tệp kế hoạch — hãy cung cấp toàn bộ văn bản nhiệm vụ trực tiếp trong ngữ cảnh.

### 2. Quy trình làm việc theo từng nhiệm vụ

Đối với MỖI nhiệm vụ trong kế hoạch:

#### Bước 1: Điều động Tiểu đại diện Người thực hiện

Sử dụng
`delegate_task
` với ngữ cảnh hoàn chỉnh:

``` python
delegate_task(
goal="Implement Task 1: Create User model with email and password_hash fields",
context="""
TASK FROM PLAN:

- Create: src/models/user.py
- Add User class with email (str) and password_hash (str) fields
- Use bcrypt for password hashing
- Include __repr__ for debugging

FOLLOW TDD:
1. Write failing test in tests/models/test_user.py
2. Run: pytest tests/models/test_user.py -v (verify FAIL)
3. Write minimal implementation
4. Run: pytest tests/models/test_user.py -v (verify PASS)
5. Run: pytest tests/ -q (verify no regressions)
6. Commit: git add -A && git commit -m "feat: add User model with password hashing"

PROJECT CONTEXT:
- Python 3.11, Flask app in src/app.py
- Existing models in src/models/
- Tests use pytest, run from project root
- bcrypt already in requirements.txt
""",
toolsets=['terminal', 'file']
)

`

#### Bước 2: Người đánh giá tuân thủ thông số kỹ thuật gửi đi

Sau khi người triển khai hoàn tất, hãy xác minh dựa trên thông số ban đầu:

``` python
delegate_task(
goal="Review if implementation matches the spec from the plan",
context="""
ORIGINAL TASK SPEC:

- Create src/models/user.py with User class
- Fields: email (str), password_hash (str)
- Use bcrypt for password hashing
- Include __repr__

CHECK:
- [ ] All requirements from spec implemented?
- [ ] File paths match spec?
- [ ] Function signatures match spec?
- [ ] Behavior matches expected?
- [ ] Nothing extra added (no scope creep)?

OUTPUT: PASS or list of specific spec gaps to fix.
""",
toolsets=['file']
)

`
``**Nếu tìm thấy vấn đề về thông số kỹ thuật:** Hãy khắc phục các khoảng trống, sau đó chạy lại quá trình đánh giá thông số kỹ thuật. Chỉ tiếp tục khi tuân thủ thông số kỹ thuật.

#### Bước 3: Người đánh giá chất lượng mã công văn

Sau khi tuân thủ thông số kỹ thuật:

``` python
delegate_task(
goal="Review code quality for Task 1 implementation",
context="""
FILES TO REVIEW:

- src/models/user.py
- tests/models/test_user.py

CHECK:
- [ ] Follows project conventions and style?
- [ ] Proper error handling?
- [ ] Clear variable/function names?
- [ ] Adequate test coverage?
- [ ] No obvious bugs or missed edge cases?
- [ ] No security issues?

OUTPUT FORMAT:
- Critical Issues: [must fix before proceeding]
- Important Issues: [should fix]
- Minor Issues: [optional]
- Verdict: APPROVED or REQUEST_CHANGES
""",
toolsets=['file']
)

`
``**Nếu phát hiện vấn đề về chất lượng:** Khắc phục vấn đề, xem xét lại. Chỉ tiếp tục khi được phê duyệt.

#### Bước 4: Đánh dấu là hoàn thành

``` python
todo([\{"id": "task-1", "content": "Create User model with email field", "status": "completed"}], merge=True)

`

### 3. Đánh giá cuối cùng

Sau khi TẤT CẢ nhiệm vụ hoàn tất, hãy cử người đánh giá tích hợp cuối cùng:

`Python
delegate_task(
goal="Review the entire implementation for consistency and integration issues",
context="""
All tasks from the plan are complete. Review the full implementation:

- Do all components work together?
- Any inconsistencies between tasks?
- All tests passing?
- Ready for merge?
""",
toolsets=['terminal', 'file']
)

`

### 4. Xác minh và cam kết

``` bash

# Run full test suite
pytest tests/ -q

# Review all changes
git diff --stat

# Final commit if needed
git add -A && git commit -m "feat: complete [feature name] implementation"

`

## Mức độ chi tiết của nhiệm vụ`**Mỗi nhiệm vụ = 2-5 phút tập trung làm việc.**`**Quá lớn:**
- "Triển khai hệ thống xác thực người dùng"`**Kích thước phù hợp:**
- "Tạo mô hình Người dùng với các trường email và mật khẩu"
- "Thêm chức năng băm mật khẩu"
- "Tạo điểm cuối đăng nhập"
- "Thêm tính năng tạo mã thông báo JWT"
- "Tạo điểm cuối đăng ký"

## Cờ đỏ - Đừng bao giờ làm những điều này
- Bắt đầu thực hiện mà không có kế hoạch
- Bỏ qua đánh giá (tuân thủ thông số kỹ thuật HOẶC chất lượng mã)
- Tiến hành giải quyết các vấn đề quan trọng/quan trọng chưa được khắc phục
- Gửi nhiều tác nhân phụ triển khai cho các tác vụ chạm vào cùng một tệp
- Yêu cầu tác nhân phụ đọc tệp kế hoạch (thay vào đó hãy cung cấp toàn văn trong ngữ cảnh)
- Bỏ qua bối cảnh thiết lập cảnh (subgent cần hiểu nhiệm vụ phù hợp ở đâu)
- Bỏ qua các câu hỏi của tác nhân phụ (trả lời trước khi để chúng tiếp tục)
- Chấp nhận “đủ gần” về tuân thủ thông số kỹ thuật
- Bỏ qua các vòng đánh giá (người đánh giá tìm thấy vấn đề → bản sửa lỗi của người triển khai → đánh giá lại)
- Để người thực hiện tự đánh giá thay thế đánh giá thực tế (cả hai đều cần thiết)
- **Bắt đầu đánh giá chất lượng mã trước khi tuân thủ thông số kỹ thuật là ĐẠT** (sai thứ tự)
- Chuyển sang nhiệm vụ tiếp theo trong khi một trong hai bài đánh giá có vấn đề mở

## Xử lý vấn đề

### Nếu đại lý phụ đặt câu hỏi
- Trả lời rõ ràng, đầy đủ
- Cung cấp thêm ngữ cảnh nếu cần
- Đừng vội vàng thực hiện

### Nếu người đánh giá tìm thấy vấn đề
- Tác nhân phụ của người triển khai (hoặc tác nhân mới) sửa chúng
- Người nhận xét đánh giá lại
- Lặp lại cho đến khi được phê duyệt
- Đừng bỏ qua việc xem xét lại

### Nếu đại lý phụ thất bại trong một nhiệm vụ
- Gửi một đại diện phụ sửa chữa mới kèm theo hướng dẫn cụ thể về những sai sót
- Đừng cố gắng khắc phục thủ công trong phiên điều khiển (ô nhiễm ngữ cảnh)

## Lưu ý về hiệu quả**Tại sao phải có đại lý phụ mới cho mỗi nhiệm vụ:**
- Ngăn chặn ô nhiễm bối cảnh từ trạng thái tích lũy
- Mỗi tác nhân phụ có bối cảnh rõ ràng, tập trung
- Không nhầm lẫn với mã hoặc lý luận của nhiệm vụ trước`**Tại sao phải đánh giá hai giai đoạn:**
- Đánh giá thông số kỹ thuật bắt dưới/quá mức xây dựng sớm
- Đánh giá chất lượng đảm bảo việc thực hiện được xây dựng tốt
- Nắm bắt các vấn đề trước khi chúng kết hợp với các nhiệm vụ`**Sự cân bằng chi phí:**
- Nhiều lệnh gọi tác nhân phụ hơn (người triển khai + 2 người đánh giá cho mỗi nhiệm vụ)
- Nhưng phát hiện vấn đề sớm (rẻ hơn so với việc gỡ lỗi các vấn đề phức tạp sau này)

## Tích hợp với các kỹ năng khác

### Có kế hoạch viết

Kỹ năng này THỰC HIỆN các kế hoạch được tạo ra bởi kỹ năng viết kế hoạch:
1. Yêu cầu của người dùng → kế hoạch viết → kế hoạch thực hiện
2. Kế hoạch triển khai → phát triển theo hướng tác nhân phụ → mã hoạt động

### Với sự phát triển dựa trên thử nghiệm

Các tác nhân phụ của người triển khai phải tuân theo TDD:
1. Viết bài kiểm tra thất bại trước
2. Triển khai mã tối thiểu
3. Xác minh các lần vượt qua bài kiểm tra
4. Cam kết

Bao gồm các hướng dẫn TDD trong mọi ngữ cảnh của người triển khai.

### Với yêu cầu xem xét mã

Quá trình xem xét hai giai đoạn LÀ xem xét mã. Để xem xét tích hợp lần cuối, hãy sử dụng các thứ nguyên đánh giá của kỹ năng yêu cầu xem xét mã.

### Với tính năng gỡ lỗi hệ thống

Nếu tác nhân phụ gặp lỗi trong quá trình triển khai:
1. Thực hiện theo quy trình gỡ lỗi hệ thống
2. Tìm nguyên nhân gốc rễ trước khi khắc phục
3. Viết bài kiểm tra hồi quy
4. Tiếp tục thực hiện

## Ví dụ về quy trình làm việc

`
[Read plan: docs/plans/auth-feature.md]
[Create todo list with 5 tasks]

--- Task 1: Create User model ---
[Dispatch implementer subagent]
Implementer: "Should email be unique?"
You: "Yes, email must be unique"
Implementer: Implemented, 3/3 tests passing, committed.

[Dispatch spec reviewer]
Spec reviewer: ✅ PASS — all requirements met`[Dispatch quality reviewer]
Quality reviewer: ✅ APPROVED — clean code, good tests`[Mark Task 1 complete]

--- Task 2: Password hashing ---
[Dispatch implementer subagent]
Implementer: No questions, implemented, 5/5 tests passing.

[Dispatch spec reviewer]
Spec reviewer: ❌ Missing: password strength validation (spec says "min 8 chars")

[Implementer fixes]
Implementer: Added validation, 7/7 tests passing.

[Dispatch spec reviewer again]
Spec reviewer: ✅ PASS`[Dispatch quality reviewer]
Quality reviewer: Important: Magic number 8, extract to constant
Implementer: Extracted MIN_PASSWORD_LENGTH constant
Quality reviewer: ✅ APPROVED`[Mark Task 2 complete]`... (Continue for all tasks)

[After all tasks: dispatch final integration reviewer]
[Run full test suite: all passing]
[Done!]

`

## Ghi nhớ

`
Fresh subagent per task
Two-stage review every time
Spec compliance FIRST
Code quality SECOND
Never skip reviews
Catch issues early

`
``**Chất lượng không phải là ngẫu nhiên. Đó là kết quả của một quá trình có tính hệ thống.**

## Đọc thêm (tải khi thích hợp)

Khi việc điều phối liên quan đến việc sử dụng ngữ cảnh quan trọng, vòng xem xét dài hoặc điểm kiểm tra xác thực phức tạp, hãy tải các tài liệu tham khảo này cho chuyên ngành cụ thể:
- **
`references/context-budget-discipline.md

** — Mô hình suy giảm ngữ cảnh bốn tầng (PEAK / GOOD / DEGRADING / POOR), các quy tắc về độ sâu đọc mở rộng theo kích thước cửa sổ ngữ cảnh và các dấu hiệu cảnh báo sớm về sự xuống cấp thầm lặng. Tải khi chạy sẽ sử dụng bối cảnh quan trọng rõ ràng (kế hoạch nhiều giai đoạn, nhiều tác nhân phụ, tạo tác lớn).
- **
`references/gates-taxonomy.md

** — Bốn loại cổng chính tắc (Trước chuyến bay, Sửa đổi, Nâng cao, Hủy bỏ) với hành vi, khôi phục và ví dụ. Tải khi thiết kế hoặc xem xét bất kỳ quy trình công việc nào có điểm kiểm tra xác thực - sử dụng từ vựng một cách rõ ràng để mỗi cổng có các quy tắc nhập, hành vi lỗi và tiếp tục được xác định.

Cả hai tài liệu tham khảo đều được điều chỉnh từ gsd-build/get-shit-done (MIT © 2025 Lex Christopherson).