Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add makifbaysal/tasktrooper --skill board-comment-stylegit clone --depth 1 https://github.com/makifbaysal/tasktrooperWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/makifbaysal/tasktrooper/board-comment-style)<a href="https://agentmods.dev/skills/makifbaysal/tasktrooper/board-comment-style"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/board-comment-style/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/makifbaysal/tasktrooper/board-comment-style"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/board-comment-style.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00054 | $0.01152 |
| Opus 5.5 | $0.00022 | $0.00461 |
| Sonnet 5.5 | $0.00011 | $0.00230 |
| Haiku 4.5 | $0.00005 | $0.00115 |
Grade A, and why
board-comment-style scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Board comment style
Write task comments the way a colleague writes them: short, specific, done.
A board comment is read by a teammate scrolling a card, not by a grader. Nobody reads the second screen. A long comment does not prove more work happened — it buries the one line that mattered.
Your run's final message is not a comment: it becomes the run summary and,
for a developer, the commit message. The rules below are about add_task_comment
and comment_on_pull_request, not that message.
First: is this a comment at all?
Nothing that went WELL needs a comment. A passed review, a green build, an approved criterion, a merged pull request, a successful deploy, "moving this to pm_uat" — the board already shows every one of those, in the column, the criteria, the PR field, the pipeline panel and the task history. Writing them down again is the noise that makes the comments nobody can skip impossible to find.
Comment when something needs a person or the next agent to act:
- a rejection, and exactly why (expected vs actual, file:line, the failing step);
- a failure, a blocker, a refusal you could not work around;
- a question you cannot answer from the code, numbered;
- work you did NOT do, and why;
- a risk or a follow-up somebody has to pick up.
So: verdict is "pass" → move the card and say nothing. Verdict is "fail" → the comment IS the deliverable, and it has to be precise enough to act on without a second round trip.
Never paste the pull request link or number. It is a field on the task and the board renders it next to the card; repeating it in a comment on every hand- off is the same fact three times. The same goes for the merge commit — the task records it — and for the branch name.
Length
Three to six lines is normal. Fifteen is the ceiling, and hitting it should feel wrong. A hand-off, a verdict, a status note — each is a few sentences.
If the detail genuinely doesn't fit, it isn't a comment. Put it in a task
document if your role can attach one (add_task_document); otherwise cut it to
the actionable lines — the evidence stays. QA: your review_criterion note on
the rejected criterion already carries the per-criterion evidence; a comment
repeats it only when something needs a person's decision beyond the verdict
itself.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 113 lines · 54 tokens per session scan A 128ce2be3aab
board-comment-style is a skill published in the GitHub repository makifbaysal/tasktrooper (113 stars, last pushed yesterday), licensed Apache-2.0. It adds 54 tokens to every session and 1,152 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-05.
Other skills, from other repositories
paperclip
Use for Paperclip-managed tasks and heartbeats: reading task context, delivering task documents or files, updating completion or blockers, coordinating or delegating work, and following company governance. Includes control plane API operations for assignments, comments, approvals, and routines.
paperclip-board
Manage a Paperclip company as a board member via chat. Use when the user wants onboarding, company or agent management, approvals, task monitoring, cost oversight, or work product review in the Paperclip control plane.
paperclip-distill
Use when an operation issue is a Paperclip cursor-window, distill, or backfill. Turn source-bundled Paperclip activity into wiki-insightful project standups, durable project pages, decisions, and history without asset dereferencing.
summarize-status
Write a short, colloquial summary for a Paperclip summary slot: open with the 1–3 specific, concrete actions the reader needs to take right now to unblock the work, then a brief plain-language status, streaming progress as it works.
github-pr-workflow
Prepare a GitHub pull request from a feature branch — branch hygiene, commit shape, title/body, verification notes, screenshots for UI work, and replies to review comments.
paperclip-task-bridge
Create, comment on, update, and list Paperclip tasks from Hermes using scoped Paperclip API credentials.