Team comment
Every handoff, verdict, blocker and question on the team is one GitHub comment in a fixed shape, so people can read it and tools can follow it. The full rules are in .team/docs/github-state.md (comment format and the label table). This skill makes the shape hard to get wrong.
Write one
- Put the body in a file: what you did or found, then what you need. A handoff, fix request or verdict body opens with the evidence line:
Rows:·Revision:·Files:·Command:·Expected / actual:·Repro:, withn/awhere a field doesn’t apply. -
Build the comment with the script next to this file. It adds the header, the next prompt for the role you hand to, and the event line, and refuses anything the replayer would reject:
python3 <this skill>/scripts/team_comment.py --from verifier --to implementer \ --kind verdict --verdict BLOCK --rev abc1234 --round 2 --issue 42 --body body.md > comment.mdUse
--human human:merge(or anotherhuman:label) when the comment asks a person to act, and add that label in the same step. - Post
comment.mdas written (gh issue comment 42 --body-file comment.md), then swap therole:andstage:labels as the table ingithub-state.mdsays. One role label and one stage label at a time.
Check one
python3 <this skill>/scripts/team_comment.py --check comment.md prints ok or each problem. Run it on a comment you wrote by hand before posting.
Rules the script can’t check
- Point at the source by path and exact commit; never paste a summary in place of it.
- One comment per event. Don’t edit a posted team comment to change its meaning; post a new one.
- If the tool can’t post (no access, rate limit), that’s a blocker, not a reason to skip the comment.