[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CSDG390WRWSHTB5N606EZP":3,"skill-same:01M7CSDG390WRWSHTB5N606EZP":48},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M7CSDG390WRWSHTB5N606EZP","board-comment-style",null,"Write board comments the way a colleague does — lead with the finding, a few lines, no preamble or process narration. Use when about to call add_task_comment or comment_on_pull_request, or when deciding whether something deserves a comment at all.","makifbaysal\u002Ftasktrooper","makifbaysal","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F25031940?v=4","01M7CRG3ZCSYZSSEVDMW3DEYC8","Mehmet Akif Baysal","01M7CRG401FJ8YAXH5ER730XYV",122,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fqa-agent\u002Fskills\u002Fboard-comment-style\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: board-comment-style\ncategory: collaboration\ndescription: Write board comments the way a colleague does — lead with the finding, a few lines, no preamble or process narration. Use when about to call add_task_comment or comment_on_pull_request, or when deciding whether something deserves a comment at all.\n---\n# Board comment style\n\nWrite task comments the way a colleague writes them: short, specific, done.\n\nA board comment is read by a teammate scrolling a card, not by a grader. Nobody\nreads the second screen. A long comment does not prove more work happened — it\nburies the one line that mattered.\n\nYour run's final message is not a comment: it becomes the run summary and,\nfor a developer, the commit message. The rules below are about `add_task_comment`\nand `comment_on_pull_request`, not that message.\n\n## First: is this a comment at all?\n\n**Nothing that went WELL needs a comment.** A passed review, a green build, an\napproved criterion, a merged pull request, a successful deploy, \"moving this to\nhuman_uat\" — the board already shows every one of those, in the column, the\ncriteria, the PR field, the pipeline panel and the task history. Writing them\ndown again is the noise that makes the comments nobody can skip impossible to\nfind.\n\nComment when something needs a person or the next agent to **act**:\n\n- a rejection, and exactly why (expected vs actual, file:line, the failing step);\n- a failure, a blocker, a refusal you could not work around;\n- a question you cannot answer from the code, numbered;\n- work you did NOT do, and why;\n- a risk or a follow-up somebody has to pick up.\n\nSo: verdict is \"pass\" → move the card and say nothing. Verdict is \"fail\" → the\ncomment IS the deliverable, and it has to be precise enough to act on without a\nsecond round trip.\n\n**Never paste the pull request link or number.** It is a field on the task and\nthe board renders it next to the card; repeating it in a comment on every hand-\noff is the same fact three times. The same goes for the merge commit — the task\nrecords it — and for the branch name.\n\n## Length\n\n**Three to six lines is normal. Fifteen is the ceiling, and hitting it should\nfeel wrong.** A hand-off, a verdict, a status note — each is a few sentences.\n\nIf the detail genuinely doesn't fit, it isn't a comment. Put it in a task\ndocument if your role can attach one (`add_task_document`); otherwise cut it to\nthe actionable lines — the evidence stays. QA: your `review_criterion` note on\nthe rejected criterion already carries the per-criterion evidence; a comment\nrepeats it only when something needs a person's decision beyond the verdict\nitself.\n\n## Write this\n\n```\nBlocked on AC3: \"export streams large projects\" — `GET \u002Fv1\u002Fexport`\nbuffers the whole CSV in memory (exporter.go:88) and the 30s proxy\ntimeout cuts it at ~40k rows. Streaming needs the chunked writer in\ninternal\u002Fhttp — in scope for this task, or a follow-up?\n```\n\n## Not this\n\n```\n## Summary\nI have completed a comprehensive investigation of the issue described in\nthis task. Below you will find a detailed breakdown of my analysis...\n\n## Background\nThis task was assigned to me in the in_progress column...\n\n## What I Did\n1. First, I began by reading the relevant files...\n2. Then I examined the handler...\n[continues for two screens]\n```\n\nThe second one says less. Everything before \"Blocked on AC3\" is throat-clearing,\nand the numbered narration of which files you opened is a transcript, not a\nfinding.\n\n## Rules\n\n- **No preamble.** Never open with what the task was, what column it was in, or\n  what you were asked to do. Everyone reading already knows — start with the\n  finding.\n- **No narration of your own process.** \"I read X, then I searched Y, then I\n  realised Z\" is your history, not the result. Give Z.\n- **No headed report structure** for a routine update. `## Summary` \u002F\n  `## Background` \u002F `## Next Steps` on a three-sentence message is packaging\n  heavier than the contents.\n- **Name things exactly.** File, symbol, command, error text, expected vs\n  actual. One precise line beats a paragraph of description.\n- **Don't restate what the board already shows.** The task title, the column,\n  the assignee, the acceptance criteria, the pull request and the pipeline\n  result are all on the card.\n- **Don't pad.** No \"I hope this helps\", no \"please let me know if you need\n  anything else\", no summary of the summary.\n- **Evidence stays, prose goes.** Commands, outputs, the url and viewport of a\n  screenshot, and reproduction steps are the valuable part — keep every one of them, and cut the\n  sentences around them.\n\n## Where this does not apply\n\nStructured deliverables have their own required shape and are not comments:\nQA's numbered expected-vs-actual failure list, a rejection note naming what\nfailed, an analysis document, an implementation plan. Follow those formats.\nThe rule here is about the prose you wrap around them — there should be almost\nnone.\n","# Board comment style\n\nWrite task comments the way a colleague writes them: short, specific, done.\n\nA board comment is read by a teammate scrolling a card, not by a grader. Nobody\nreads the second screen. A long comment does not prove more work happened — it\nburies the one line that mattered.\n\nYour run's final message is not a comment: it becomes the run summary and,\nfor a developer, the commit message. The rules below are about `add_task_comment`\nand `comment_on_pull_request`, not that message.\n\n## First: is this a comment at all?\n\n**Nothing that went WELL needs a comment.** A passed review, a green build, an\napproved criterion, a merged pull request, a successful deploy, \"moving this to\nhuman_uat\" — the board already shows every one of those, in the column, the\ncriteria, the PR field, the pipeline panel and the task history. Writing them\ndown again is the noise that makes the comments nobody can skip impossible to\nfind.\n\nComment when something needs a person or the next agent to **act**:\n\n- a rejection, and exactly why (expected vs actual, file:line, the failing step);\n- a failure, a blocker, a refusal you could not work around;\n- a question you cannot answer from the code, numbered;\n- work you did NOT do, and why;\n- a risk or a follow-up somebody has to pick up.\n\nSo: verdict is \"pass\" → move the card and say nothing. Verdict is \"fail\" → the\ncomment IS the deliverable, and it has to be precise enough to act on without a\nsecond round trip.\n\n**Never paste the pull request link or number.** It is a field on the task and\nthe board renders it next to the card; repeating it in a comment on every hand-\noff is the same fact three times. The same goes for the merge commit — the task\nrecords it — and for the branch name.\n\n## Length\n\n**Three to six lines is normal. Fifteen is the ceiling, and hitting it should\nfeel wrong.** A hand-off, a verdict, a status note — each is a few sentences.\n\nIf the detail genuinely doesn't fit, it isn't a comment. Put it in a task\ndocument if your role can attach one (`add_task_document`); otherwise cut it to\nthe actionable lines — the evidence stays. QA: your `review_criterion` note on\nthe rejected criterion already carries the per-criterion evidence; a comment\nrepeats it only when something needs a person's decision beyond the verdict\nitself.\n\n## Write this\n\n```\nBlocked on AC3: \"export streams large projects\" — `GET \u002Fv1\u002Fexport`\nbuffers the whole CSV in memory (exporter.go:88) and the 30s proxy\ntimeout cuts it at ~40k rows. Streaming needs the chunked writer in\ninternal\u002Fhttp — in scope for this task, or a follow-up?\n```\n\n## Not this\n\n```\n## Summary\nI have completed a comprehensive investigation of the issue described in\nthis task. Below you will find a detailed breakdown of my analysis...\n\n## Background\nThis task was assigned to me in the in_progress column...\n\n## What I Did\n1. First, I began by reading the relevant files...\n2. Then I examined the handler...\n[continues for two screens]\n```\n\nThe second one says less. Everything before \"Blocked on AC3\" is throat-clearing,\nand the numbered narration of which files you opened is a transcript, not a\nfinding.\n\n## Rules\n\n- **No preamble.** Never open with what the task was, what column it was in, or\n  what you were asked to do. Everyone reading already knows — start with the\n  finding.\n- **No narration of your own process.** \"I read X, then I searched Y, then I\n  realised Z\" is your history, not the result. Give Z.\n- **No headed report structure** for a routine update. `## Summary` \u002F\n  `## Background` \u002F `## Next Steps` on a three-sentence message is packaging\n  heavier than the contents.\n- **Name things exactly.** File, symbol, command, error text, expected vs\n  actual. One precise line beats a paragraph of description.\n- **Don't restate what the board already shows.** The task title, the column,\n  the assignee, the acceptance criteria, the pull request and the pipeline\n  result are all on the card.\n- **Don't pad.** No \"I hope this helps\", no \"please let me know if you need\n  anything else\", no summary of the summary.\n- **Evidence stays, prose goes.** Commands, outputs, the url and viewport of a\n  screenshot, and reproduction steps are the valuable part — keep every one of them, and cut the\n  sentences around them.\n\n## Where this does not apply\n\nStructured deliverables have their own required shape and are not comments:\nQA's numbered expected-vs-actual failure list, a rejection note naming what\nfailed, an analysis document, an implementation plan. Follow those formats.\nThe rule here is about the prose you wrap around them — there should be almost\nnone.\n",{"name":5,"category":24,"description":7},"collaboration","main","910394a0b6db9fc8c9a8f36328ec421d3ebd8b38","catalog\u002Fagents\u002Fqa-agent\u002Fskills\u002Fboard-comment-style",18,"https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper","https:\u002F\u002Ftasktrooper.ai","https:\u002F\u002Fgithub.com\u002Fmakifbaysal","Senior Software Developer","2026-11-15 04:50:29",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add makifbaysal\u002Ftasktrooper --skill board-comment-style",{"tool":40,"command":41},"bunx","bunx skills add makifbaysal\u002Ftasktrooper --skill board-comment-style",{"tool":43,"command":44},"pnpm","pnpm dlx skills add makifbaysal\u002Ftasktrooper --skill board-comment-style","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fqa-agent\u002Fskills\u002Fboard-comment-style\u002FSKILL.md",true,[],[49,55,62,69,76,83],{"skillNo":50,"name":51,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":54,"publishedAt":19},"01M7CSVEPQW6J6TD6CS2T5FPNZ","visual-craft","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fvisual-craft\u002FSKILL.md",[],[],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":19},"01M7CSVAQG91ETHQ0HBNZDG5FR","ux-copy","Use when you write any words a user reads in a mockup or a hand-off - content language and voice, buttons, labels, errors, empty states, confirmations, numbers and dates, and the longest-string check","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fux-copy\u002FSKILL.md",[],[],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M7CSV6H0J38659NDXHJQ8396","screen-mockup-html","Use when you draw screens as the design task's HTML mockup - ONE canvas document holding every screen and every variant side by side, the sanitizer-safe recipe, phone and wide frames, the states grid, static control states, and the loopback self-check with screenshots at 375, 768 and 1440 attached to the task","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fscreen-mockup-html\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M7CSV3JFRF3BM3XK52M7YEYR","performance-awareness","How the performance score moves for your role. Use when the score context shows a declining trend, or before handing off work you have not self-checked against every criterion.","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fperformance-awareness\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M7CSTZDH00YRF5SCT7BRT9QD","design-variants","Use when a screen design needs variants - how many, variants as side-by-side rows on the one canvas, what makes two variants genuinely different, recommending one, how the human's choice is read, and narrowing to the chosen one in revision","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fdesign-variants\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7CSTV6P3SM3PAE28DB0RF77","design-system-authoring","Use when you derive, change or extend a design system - where tokens live per stack, the DTCG token tree, role-based names for both themes, base vs layer vs drift, the DESIGN.md section order, the inventory format, the contrast check and the lint every proposal returns","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fdesign-system-authoring\u002FSKILL.md",[],[]]