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

gai

Các thử nghiệm đơn giản để xác thực ý tưởng trước khi xây dựng.

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/spike ` | | Phiên bản |

spike

, `prototype

, `experiment

, `feasibility

, `throwaway

, `exploration

, `research

, `planning

, `mvp

, proof-of-concept | | Kỹ năng liên quan | XPROTECTX18XPROTECTX, XPROTECTX19XPROTECTX, XPROTECTX20XPROTECTX, XPROTECTX21XPROTECTX |

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.

gai

Sử dụng kỹ năng này khi người dùng muốn tìm ra ý tưởng trước khi cam kết thực hiện một công trình thực sự - xác thực tính khả thi, so sánh các phương pháp tiếp cận hoặc nêu ra những ẩn số mà không có lượng nghiên cứu nào giải đáp được. Spike được thiết kế dùng một lần. Vứt chúng đi sau khi chúng đã trả xong nợ.

Tải nội dung này khi người dùng nói những câu như "để tôi thử cái này", "Tôi muốn xem X có hoạt động không", "tăng đột biến cái này", "trước khi tôi cam kết với Y", "nguyên mẫu nhanh của Z", "điều này thậm chí có thể thực hiện được không?" hoặc "so sánh A với B".

Khi nào KHÔNG nên sử dụng cái này

Câu trả lời có thể biết được từ tài liệu hoặc đọc mã - chỉ cần nghiên cứu, không xây dựng
Công việc là đường dẫn sản xuất — thay vào đó hãy sử dụng writing-plans / `plan
Ý tưởng đã được xác thực — chuyển ngay sang giai đoạn thực hiện

Nếu người dùng đã cài đặt hệ thống GSD đầy đủ

Nếu gsd-spike hiển thị dưới dạng kỹ năng anh em (được cài đặt qua `npx get-shit-done-cc --Hermes

), hãy ưu tiên ** `gsd-spike

** khi người dùng muốn có quy trình làm việc GSD đầy đủ: trạng thái

.planning/spikes/ ` liên tục, theo dõi MANIFEST qua các phiên, định dạng phán quyết Đưa ra/Khi/Sau đó và các mẫu cam kết tích hợp với phần còn lại của GSD. Kỹ năng này là phiên bản độc lập nhẹ dành cho người dùng không có (hoặc không muốn) toàn bộ hệ thống.

Phương pháp cốt lõi

Bất kể quy mô, mọi mức tăng đột biến đều tuân theo vòng lặp này:

` decompose → research → build → verdict ↑__________________________________________↓ iterate on findings

1. Phân hủy

Chia ý tưởng của người dùng thành 2-5 câu hỏi khả thi độc lập. Mỗi câu hỏi là một mũi nhọn. Trình bày chúng dưới dạng bảng với khung Cho trước/Khi nào/Sau đó:

#	Tăng đột biến	Xác thực (Cho/Khi/Sau đó)	Rủi ro
001	phát trực tuyến websocket	Với kết nối WS, khi LLM truyền phát mã thông báo thì máy khách sẽ nhận được các đoạn < 100 mili giây	Cao
002a	pdf-parse-pdfjs	Với một tệp PDF nhiều trang, khi được phân tích cú pháp bằng pdfjs, thì văn bản có cấu trúc có thể được trích xuất	Trung bình
002b	pdf-phân tích-lạc đà	Với một tệp PDF nhiều trang, khi được phân tích cú pháp bằng Camelot, thì văn bản có cấu trúc có thể được trích xuất	Trung bình

Các loại gai:

tiêu chuẩn — một cách tiếp cận để trả lời một câu hỏi
so sánh — cùng một câu hỏi, các cách tiếp cận khác nhau (số chung, hậu tố chữ cái `a

/ `b

/ `c

)

Câu hỏi tăng đột biến hay: tính khả thi cụ thể với kết quả đầu ra có thể quan sát được. Câu hỏi tăng đột biến không tốt: quá rộng, không thể quan sát được kết quả hoặc chỉ "đọc tài liệu về X".

Sắp xếp theo rủi ro. Mức tăng đột biến có nhiều khả năng giết chết ý tưởng nhất sẽ xuất hiện trước tiên. Việc tạo mẫu những phần dễ dàng sẽ không có ý nghĩa gì nếu phần khó không hoạt động được.

Bỏ qua việc phân tách chỉ khi người dùng đã biết chính xác những gì họ muốn tăng đột biến và nói như vậy. Sau đó coi ý tưởng của họ như một mũi nhọn duy nhất.

2. Căn chỉnh (đối với ý tưởng có nhiều đột biến)

Trình bày bảng tăng đột biến. Hỏi: “Xây dựng tất cả theo thứ tự này, hay điều chỉnh?” Hãy để người dùng thả, sắp xếp lại hoặc sắp xếp lại khung trước khi bạn viết bất kỳ mã nào.

3. Nghiên cứu (trên mỗi cành, trước khi xây dựng)

Sự tăng đột biến không phải là không cần nghiên cứu — bạn nghiên cứu đủ để chọn cách tiếp cận phù hợp, sau đó bạn xây dựng. Mỗi lần tăng đột biến:

Tóm tắt. 2-3 câu: mức tăng đột biến này là gì, tại sao nó quan trọng, rủi ro chính.
Các phương pháp cạnh tranh bề mặt nếu có sự lựa chọn thực sự:

Tiếp cận	Công cụ/Thư viện	Ưu điểm	Nhược điểm	Trạng thái
...	...	...	...	duy trì/bỏ rơi/beta

Chọn một. Nêu rõ lý do. Nếu 2+ là đáng tin cậy, hãy tạo các biến thể nhanh chóng trong mức tăng đột biến.
Bỏ qua nghiên cứu để có logic thuần túy không có sự phụ thuộc bên ngoài.Sử dụng công cụ Hermes cho bước nghiên cứu:

`web_search("Python websocket streaming libraries 2025")` — tìm ứng viên

`web_extract(urls=["https://websockets.readthedocs.io/..."])` — đọc tài liệu thực tế (trả về mức giảm giá)

`terminal("pip show websockets | grep Version")

kiểm tra những gì đã được cài đặt trong venv của dự án

Đối với các thư viện không có trang tài liệu, hãy sao chép và đọc README.md / examples/ của chúng thông qua `read_file

. Context7 MCP (nếu người dùng đã định cấu hình) cũng là một nguồn tốt - MCP_*_resolve-library-id rồi đến `MCP_*_query-docs

4. Xây dựng

Một thư mục cho mỗi cành. Giữ nó độc lập.`

spikes/ ├── 001-websocket-streaming/ │ ├── README.md │ └── main.py ├── 002a-pdf-parse-pdfjs/ │ ├── README.md │ └── parse.js └── 002b-pdf-parse-camelot/ ├── README.md └── parse.py

Thành kiến đối với thứ gì đó mà người dùng có thể tương tác. Đột biến không thành công khi đầu ra duy nhất là dòng nhật ký có nội dung "nó hoạt động". Người dùng muốn cảm nhận cành đang hoạt động. Các lựa chọn mặc định, theo thứ tự ưu tiên:

CLI có thể chạy được, nhận đầu vào và in đầu ra có thể quan sát được
Một trang HTML tối thiểu thể hiện hành vi
Một máy chủ web nhỏ có một điểm cuối
Bài kiểm tra đơn vị thực hiện câu hỏi với các khẳng định dễ nhận biết`Độ sâu vượt quá tốc độ. Không bao giờ tuyên bố "nó hoạt động" sau một lần chạy đường dẫn hạnh phúc. Kiểm tra các trường hợp cạnh. Theo dõi những phát hiện đáng ngạc nhiên. Phán quyết chỉ đáng tin cậy khi cuộc điều tra trung thực.

Tránh trừ khi đợt tăng đột biến yêu cầu cụ thể: quản lý gói phức tạp, công cụ/gói xây dựng, Docker, tệp env, hệ thống cấu hình. Mã hóa cứng mọi thứ - đó là một sự tăng đột biến.

Xây dựng một cành — một chuỗi công cụ điển hình:

` terminal("mkdir -p spikes/001-websocket-streaming") write_file("spikes/001-websocket-streaming/README.md", "# 001: websocket-streaming\n\n...") write_file("spikes/001-websocket-streaming/main.py", "...") terminal("cd spikes/001-websocket-streaming && Python3 main.py")

Observe output, iterate.

``**Các đột biến so sánh song song (002a / 002b) — đại biểu.** Khi hai phương pháp có thể chạy song song và cả hai đều cần kỹ thuật thực sự (không phải nguyên mẫu 10 dòng), hãy sử dụng delegate_task

` delegate_task(tasks=[ {"goal": "Build 002a-pdf-parse-pdfjs: ...", "toolsets": ["terminal", "file", "web"]}, {"goal": "Build 002b-pdf-parse-camelot: ...", "toolsets": ["terminal", "file", "web"]}, ])

` ``Mỗi đại lý phụ trả về phán quyết riêng của mình; bạn viết đối đầu.

5. Phán quyết``README.md

` của mỗi cành đóng lại bằng:

`markdown

Verdict: VALIDATED | PARTIAL | INVALIDATED

What worked

What didn't

Surprises

Recommendation for the real build

` ``XÁC NHẬN = câu hỏi cốt lõi đã được trả lời là có, kèm theo bằng chứng. PARTIAL = nó hoạt động dưới các ràng buộc X, Y, Z — ghi lại chúng. INVALIDATED = không hoạt động, vì lý do này. Đây là một đột biến thành công.

Mức tăng đột biến so sánh

Khi hai cách tiếp cận trả lời cùng một câu hỏi (002a / 002b), hãy xây dựng chúng trở lại, sau đó thực hiện so sánh trực tiếp ở cuối:

`markdown

Head-to-head: pdfjs vs camelot

Dimension	pdfjs (002a)	camelot (002b)
Extraction quality	9/10 structured	7/10 table-only
Setup complexity	npm install, 1 line	pip + ghostscript
Perf on 100-page PDF	3s	18s
Handles rotated text	no	yes

Winner: pdfjs for our use case. Camelot if we need table-first extraction later.

Chế độ biên giới (chọn nội dung cần tăng đột biến tiếp theo)

Nếu mức tăng đột biến đã tồn tại và người dùng nói "tiếp theo tôi nên làm gì tiếp theo?", hãy duyệt qua các thư mục hiện có và tìm kiếm:

Rủi ro tích hợp — hai đột biến đã được xác thực có liên quan đến cùng một tài nguyên nhưng được kiểm tra độc lập
Bàn giao dữ liệu — đầu ra của Spike A được cho là tương thích với đầu vào của Spike B; chưa bao giờ được chứng minh
Khoảng trống trong tầm nhìn — những khả năng được giả định nhưng chưa được chứng minh
Các phương pháp thay thế — các góc khác nhau cho các mức tăng đột biến MỘT PHẦN hoặc KHÔNG HỢP LỆ

Đề xuất 2-4 ứng viên theo kiểu Cho trước/Khi nào/Sau đó. Hãy để người dùng chọn.

Đầu ra

Tạo spikes/ (hoặc

.planning/spikes/ ` nếu người dùng đang sử dụng quy ước GSD) trong repo root

Một thư mục trên mỗi cành: `NNN-descriptive-name/

README.md mỗi lần tăng đột biến ghi lại câu hỏi, cách tiếp cận, kết quả, phán quyết

Hãy vứt mã đi — một đợt tăng đột biến phải mất 2 ngày để "dọn dẹp để đưa vào sản xuất" là một đợt tăng đột biến tồi tệ

Ghi công

Được điều chỉnh từ quy trình làm việc

/gsd-spike của dự án GSD (Get Shit Done) — MIT © 2025 Lex Christopherson ([gsd-build/get-shit-done](https://GitHub.com/gsd-build/get-shit-done)). Hệ thống GSD đầy đủ cung cấp trạng thái tăng đột biến liên tục, theo dõi MANIFEST và tích hợp với quy trình phát triển dựa trên thông số kỹ thuật rộng hơn; cài đặt với npx get-shit-done-cc --Hermes --global

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

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

gai

Khi nào KHÔNG nên sử dụng cái này​

Nếu người dùng đã cài đặt hệ thống GSD đầy đủ​

Phương pháp cốt lõi​

1. Phân hủy​

2. Căn chỉnh (đối với ý tưởng có nhiều đột biến)​

3. Nghiên cứu (trên mỗi cành, trước khi xây dựng)​

web_search("Python websocket streaming libraries 2025") — tìm ứng viên​

web_extract(urls=["https://websockets.readthedocs.io/..."]) — đọc tài liệu thực tế (trả về mức giảm giá)​

4. Xây dựng​

Observe output, iterate.

5. Phán quyết``README.md​

Verdict: VALIDATED | PARTIAL | INVALIDATED​

What worked​

What didn't​

Surprises​

Recommendation for the real build​

Mức tăng đột biến so sánh​

Head-to-head: pdfjs vs camelot​

Chế độ biên giới (chọn nội dung cần tăng đột biến tiếp theo)​

Đầu ra​

Ghi công​