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 agentmods add skills/bradygaster/squad/external-commsnpx skills add bradygaster/squad --skill external-commsgit clone --depth 1 https://github.com/bradygaster/squadWhat 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 | $0.00020 | $0.03023 |
| Opus 5 | $0.00010 | $0.01511 |
| Sonnet 5 | $0.00004 | $0.00605 |
| Haiku 4.5 | $0.00002 | $0.00302 |
Grade A, and why
external-comms 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 2d 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.
Copies of this mod
8 near-identical copies found in the catalogue:
- external-comms — 100% identical, 0 lines differ
- external-comms — 100% identical, 658 lines differ
- external-comms — 100% identical, 658 lines differ
- external-comms — 100% identical, 658 lines differ
- external-comms — 100% identical, 658 lines differ
- external-comms — 100% identical, 658 lines differ
- external-comms — 100% identical, 658 lines differ
- external-comms — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 330 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Context
Phase 1 is draft-only mode.
- PAO scans issues and discussions, drafts responses with the humanizer skill, and presents a review table for human approval.
- Human review gate is mandatory — PAO never posts autonomously.
- Every action is logged to
.squad/comms/audit/. - This workflow is triggered manually only ("PAO, check community") — no automated or Ralph-triggered activation in Phase 1.
Patterns
1. Scan
Find unanswered community items with GitHub MCP tools first, or gh issue list / gh api as fallback for issues and discussions.
- Include open issues and discussions only.
- Filter for items with no squad team response.
- Limit to items created in the last 7 days.
- Exclude items labeled
squad:internalorwontfix. - Include discussions and issues in the same sweep.
- Phase 1 scope is issues and discussions only — do not draft PR replies.
Discussion Handling (Phase 1)
Discussions use the GitHub Discussions API, which differs from issues:
- Scan:
gh api /repos/{owner}/{repo}/discussions --jq '.[] | select(.answer_chosen_at == null)'to find unanswered discussions - Categories: Filter by Q&A and General categories only (skip Announcements, Show and Tell)
- Answers vs comments: In Q&A discussions, PAO drafts an "answer" (not a comment). The human marks it as accepted answer after posting.
- Phase 1 scope: Issues and Discussions ONLY. No PR comments.
2. Classify
Determine the response type before drafting.
- Welcome (new contributor)
- Troubleshooting (bug/help)
- Feature guidance (feature request/how-to)
- Redirect (wrong repo/scope)
- Acknowledgment (confirmed, no fix)
- Closing (resolved)
- Technical uncertainty (unknown cause)
- Empathetic disagreement (pushback on a decision or design)
- Information request (need more reproduction details or context)
Template Selection Guide
| Signal in Issue/Discussion | → Response Type | Template |
|---|---|---|
| New contributor (0 prior issues) | Welcome | T1 |
| Error message, stack trace, "doesn't work" | Troubleshooting | T2 |
| "How do I...?", "Can Squad...?", "Is there a way to...?" | Feature Guidance | T3 |
| Wrong repo, out of scope for Squad | Redirect | T4 |
| Confirmed bug, no fix available yet | Acknowledgment | T5 |
| Fix shipped, PR merged that resolves issue | Closing | T6 |
| Unclear cause, needs investigation | Technical Uncertainty | T7 |
| Author disagrees with a decision or design | Empathetic Disagreement | T8 |
| Need more reproduction info or context | Information Request | T9 |
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.
- 2d ago First seen · 330 lines · 20 tokens per session scan A 00e68bc3da9a
external-comms is a skill published in the GitHub repository bradygaster/squad (3,150 stars, last pushed today), licensed MIT. It adds 20 tokens to every session and 3,023 once invoked, about $0.0001 per session on Opus 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-08-30.
Other skills, from other repositories
coding-agents-farm
To orchestrate parallel coding-agent farms (Claude, Codex, Copilot, Gemini, etc.) on isolated git worktrees.
clean-architecture-dotnet
Use when domain logic leaks into API/Infrastructure, project references violate layer boundaries, or you need to decide between CQS (always), CQRS bus (complex domains), and DDD patterns (invariants and events).
mutation-testing
Use when running mutation testing, killing mutants, verifying test quality, checking mutation score, or analyzing survivors after the test baseline is green.
outside-in-tdd
Use when writing tests from the outside-in, defining behavior before code, or any feature where tests should start from observable business behavior and let internal design emerge.
extracting-code-structure
Use when listing all methods, functions, or classes in a file, exploring unfamiliar code, getting API overviews, or deciding what to read selectively without loading entire files.
querying-yaml
Use when querying YAML files, filtering or transforming configuration data, or extracting specific fields from large YAML files like docker-compose.yml or GitHub Actions workflows without loading entire files (saves 80-95% context).