Why use it: when the text is already in the repo (README, docs, blog post, release note) or when you want another task to call Humanizer as the final step before writing out the PR body / commit message.
What it produces: the file is overwritten only in the prose parts, along with a short summary in chat (file mode); or just the final text, without draft and review parts (embedded mode).
The commands in this file are typed in the agent's chat box. Humanizer itself has no CLI to call from the shell.
File mode
Just give it the path:
Humanize phần văn xuôi trong docs/launch-post.md
/humanizer
Rewrite the "Getting started" section of README.md, write directly to the file.
Hành vi theo `SKILL.md` → "How to return the result", mục **File mode**: chạy đủ quy trình viết lại nhưng **chỉ ghi bản cuối vào file**, rồi đưa bạn một tóm tắt ngắn. Bạn không thấy bản nháp và phần soi như ở chế độ dán (workflow `03`).
### Cái nó không được đụng
Nguyên văn: *"Change prose only. Keep code blocks, YAML metadata, data, and link targets unchanged."*
| Được sửa | Giữ nguyên |
|---|---|
| Câu văn, đoạn văn, tiêu đề | Code block |
| Câu dẫn trong bảng | YAML frontmatter |
| Chú thích dạng văn xuôi | Dữ liệu, bảng số |
| | Đích của link (`](...)`) |
### Nên làm trước khi chạy
Vì đây là ghi đè tại chỗ, hãy để git làm mạng lưới an toàn:
```bash
git status --porcelain # phải sạch trước khi chạy
After running:
git diff -- docs/launch-post.md
Specifically check three things in the diff: (1) whether any claim disappeared, (2) whether any code block was touched, (3) whether any link target changed. These are the three most fragile spots and are also the three boundaries the skill sets for itself.
Embedded mode
When another task uses Humanizer as the final step — writing a PR description, commit message, a documentation paragraph — the skill returns only the final text, no draft, no review part.
The way to trigger it is to state the embedding context clearly:
Soạn PR description cho diff này, rồi dùng humanizer làm bước cuối. Chỉ trả về văn bản cuối.
Usable when you want to slot Humanizer into a long pipeline without intermediate output getting in the way.
Running on many files in bulk
There is no flag --batch. Just list them:
Humanize phần văn xuôi trong các file này, mỗi file ghi tại chỗ:
- docs/intro.md
- docs/faq.md
- README.md
Tip for limiting scope in a large repo — filter first with the shell then paste the list into chat:
git diff --name-only main...HEAD -- '*.md'
Only fix the files you just changed, don't scan the whole repo.
There is no CI gate on the user side
Humanizer does not ship a binary, has no command check, returns no exit code for CI to hook into. Its product is a prompt. .github/workflows/validate.yml in the repo only checks the skill package itself (see workflow 06) — don't copy that file into your project's CI, it doesn't check your text.
If you want an automatic style gate in CI, you need a separate text linter (vale, textlint...). Humanizer is a step where a human presses the button, running inside the agent.