Commonly is a self-hosted collaborative workspace where people work with multiple AI agents, each retaining its own name, memory, skills, and workstation. Teams use it to assign and refine real work across different agent runtimes, and the catalogue entries supply agents, skills, and instructions for use in those rooms.
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 Team-Commonly/commonly --skill working-in-turnsgit clone --depth 1 https://github.com/Team-Commonly/commonlyWrote 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/team-commonly/commonly/working-in-turns)<a href="https://agentmods.dev/skills/team-commonly/commonly/working-in-turns"><img src="https://agentmods.dev/badge/skills/team-commonly/commonly/working-in-turns/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/team-commonly/commonly/working-in-turns"><img src="https://agentmods.dev/badge/skills/team-commonly/commonly/working-in-turns.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.00017 | $0.00540 |
| Opus 5.5 | $0.00007 | $0.00216 |
| Sonnet 5.5 | $0.00003 | $0.00108 |
| Haiku 4.5 | $0.00002 | $0.00054 |
Grade A, and why
working-in-turns 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 today.
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 — 33 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Working in Turns
- Size each turn to finish well inside its run timeout. The default is 15 minutes; only adapters that honor
COMMONLY_AGENT_RUN_TIMEOUT_MScan use a longer value such as2700000(45 minutes). If the work is larger, split it and say how in the row. - Push a checkpoint commit before the final five minutes of the run timeout. A draft PR is enough; a timeout sends SIGTERM and loses uncommitted work.
- Put every gate ask on the PR with the exact head and in the pod.
- Ask reviewers in a pod they actually belong to.
- After a HOLD, fix it, push the new head, and re-ask on the PR.
- File every verdict as described in review checklist rule 44 and rule 51: the first line must name the exact head and verdict, and the final non-blank line must be the bare
GATE: PASSorGATE: HOLDsentinel. - After filing a verdict, choose a checkout strategy: inspect and remove/prune a temporary PR checkout only after checking for uncommitted work, or keep one reusable checkout and clean/refetch it for the next review.
- Never use
git worktree remove --forcebefore checking for uncommitted work.
Gate ask template
Address the reviewer in a pod they belong to and include the PR number, exact head SHA, files or properties to check, and the required verdict form:
Please review PR # at
<full-head-sha>. Check<files/properties>. File the verdict as a PR review. Its first line must beHEAD: <full-head-sha> — GATE: PASSorHEAD: <full-head-sha> — GATE: HOLD, and its final non-blank line must be exactlyGATE: PASSorGATE: HOLD, per review checklist rules 44 and 51. After filing it, inspect a temporary checkout for uncommitted work before removing it and pruning; otherwise clean and refetch the reusable checkout for the next review.
Use one reusable checkout per seat when appropriate; inspect temporary checkouts before removing them.
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.
- today First seen · 33 lines · 17 tokens per session scan A e845d41f26c2
working-in-turns is a skill published in the GitHub repository Team-Commonly/commonly (1,370 stars, last pushed today), licensed Apache-2.0. It adds 17 tokens to every session and 540 once invoked, about $0.0001 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-25.
Other skills, from other repositories
flag-cleanup
Weekly reusable-session feature-flag cleanup for {{targetrepo}}. Inventories every feature flag, classifies each as fully rolled out, long dead, partial rollout, or active experiment, removes the flag and the dead branch it guards on an isolated branch when the suite is green, and opens a PR — never touching a flag…
guardian
Gatekeeping Git/PR by classifying change essence and recommending granularity, naming, and strategy; the ship recipe also executes PR delivery (create, CI watch, merge, cleanup) with Ask First on merge. Use when PR preparation, commit strategy, or gated PR delivery is needed.
trail
Investigating git history, analyzing regression root causes, and performing code archaeology. Time-travels through commits to uncover truth. Use for git history investigation.
pr-authoring
Playbook for deployment-aware pull requests — the 11-section format that turns a PR into a reviewable contract; why, decision requested, change map, review order, evidence, verification, risk, rollback. Used for the Define→build handoff and any PR a great-pm-driven project opens.
pr-review
Playbook for reviewing pull requests — verdict format, verification-not-trust, severity-ranked findings with concrete fixes, risk acceptance on the record. The reviewer-side counterpart of pr-authoring.
implement-specs
Implement code changes from an existing specs/ /TECH.md, one Implementation Plan step per commit, and update the spec in the same PR whenever reality diverges. Use after write-tech-spec, or when the user points at an existing TECH.md and says "implement this".