RFC: PAO External Communications — Community Response Drafting with Human Review Gate #426

RFC: PAO External Communications — Community Response Drafting with Human Review Gate

Enable PAO to draft community responses on bradygaster/squad issues and discussions, with humanized tone and human-gated posting.

Status: Approved by team — requesting community feedback
Phase 1 Effort: 12-17 hours (EECOM estimate)
Reviewers: FLIGHT ✅ | EECOM ✅ | FIDO ⚠️ (5 blockers mitigated) | PAO ✅

Summary

This RFC proposes giving PAO (DevRel) the capability to draft responses to community questions, bug reports, and discussions on the Squad repository — with strict human oversight and tone controls.

Why this matters: Squad's community is growing. Discussions and issues often sit unanswered for days because the team is heads-down on code. PAO can scan for unanswered items, draft helpful responses using Squad's context, and present them for human review. The human posts after approval.

What this enables: Faster first-response times for community questions. Better signal aggregation (unanswered discussions reveal doc gaps, feature requests, and confusion patterns). More consistent tone in external communications. And crucially — PAO never posts autonomously. Every response goes through human review.

This is Phase 1 (draft-only mode). Phase 2 (semi-autonomous, scheduled scans) requires explicit approval from Brady after Phase 1 proves reliable.

Background: Brady's Constraints

Brady approved this feature with five non-negotiable requirements (Teams chat, 2026-03-15):

1. Humanized tone is mandatory — use tone patterns that sound warm, helpful, and human (not robotic or corporate)
2. Never autonomous — all responses are drafted, never posted directly by the agent
3. Human review gate — PAO produces a table of proposed responses; Brady or Dina reviews before posting
4. Never mean — tone must be polite, kind, and constructive under all circumstances
5. Reputational awareness — comments post from a human GitHub account; agent unpredictability is a known risk

These constraints shape the entire architecture.

Architecture: Scan → Draft → Review → Post

┌──────────────┐    ┌───────────────┐    ┌───────────────┐    ┌─────────┐
│  PAO scans   │───▶│  PAO drafts   │───▶│ Human reviews │───▶│ Human   │
│  issues and  │    │  responses    │    │  draft table  │    │ posts   │
│ discussions  │    │  (humanized)  │    │   (approve/   │    │approved │
└──────────────┘    └───────────────┘    │  edit/skip)   │    └─────────┘
                                          └───────────────┘

Phase 1 workflow (manual trigger):

1. Trigger: User says "PAO, check community" or Ralph detects unanswered items and adds squad:needs-response label
2. Scan: PAO reads open issues and discussions (via GitHub MCP or gh CLI), filtered by:
   • No squad team response yet
   • Created in last 7 days (configurable)
   • Not labeled squad:internal or wontfix
3. Draft: For each item, PAO:
   • Reads the full thread
   • Classifies response type (welcome, troubleshooting, redirect, acknowledgment, closing, technical uncertainty)
   • Drafts response using humanizer skill (tone enforcement)
   • Validates tone against anti-patterns
4. Present: PAO outputs a review table with confidence flags:

📝 PAO — Community Response Drafts
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

| # | Item          | Author  | Type             | Confidence | Draft Preview              |
|---|---------------|---------|------------------|------------|----------------------------|
| 1 | Discussion #402| @user1 | Troubleshooting  | 🟢         | "Thanks for reporting..."  |
| 2 | Discussion #401| @user2 | Feature guidance | 🟡         | "Great question! Squad..." |
| 3 | Issue #324    | @user3 | Technical detail | 🔴         | "⚠️ Needs Flight review"   |

**Confidence Legend:**
🟢 High (answered before, clear docs, community consensus)
🟡 Medium (technically sound but minor uncertainty or tone-dependent)
🔴 Needs review (technical uncertainty, policy decision, reputational risk)

Full drafts below ▼

5. Human action: User reviews each draft, says "post 1 and 3" or "edit 2" or "skip all"
6. Post: Human (or PAO with explicit permission) posts approved responses via gh CLI
7. Audit: Every action logged to .squad/comms/audit/{timestamp}.md

Phase 1 Scope: Draft-Only Mode (Launch)

What ships in Phase 1:

• New Squad skill: humanizer — tone enforcement patterns for external-facing content
• New Squad skill: external-comms — PAO's workflow for scanning, drafting, and presenting community responses
• PAO charter updates — add external communications to responsibilities
• Ralph integration — Ralph adds squad:needs-response label to unanswered items (human-triggered PAO scan)
• Review table with confidence flags (🟢/🟡/🔴) to reduce reviewer cognitive load
• 7 response templates (welcome, troubleshooting, feature request, redirect, closing, "we don't know yet", technical uncertainty)
• Audit logging for every draft-review-post action
• Safe word mechanism (pao halt) to stop all pending posts
• Thread summary extraction for long threads (>10 comments)
• Tone validation tests and CI lint

What does NOT ship in Phase 1:

• Autonomous posting (explicitly blocked by Brady)
• Scheduled scans (manual trigger only)
• Cross-repo communications (squad-skills, squad-IRL, etc.)
• Automated audit reporting (manual review of audit logs)

Phase 1 readiness checkpoint (2 weeks after launch):

• Minimum 10 drafts per week
• Human review turnaround <24 hours (prove workflow is sustainable)
• Zero "this is inappropriate" feedback from Brady
• At least one instance of each response type successfully posted
• Weekly signal summary delivered (responses → product signals)

Phase 2 Scope: Semi-Autonomous (Future — Requires Brady Approval)

Phase 2 only proceeds after Brady approves Phase 1 output quality.

What Phase 2 adds:

• Ralph auto-spawns PAO or sends async message when unanswered items detected
• Drafts written to .squad/comms/outbox/ as markdown files
• New CLI commands: squad comms review, squad comms post, squad comms history
• Scheduled scans (daily or hourly, configurable)
• Auto-posting with approval gate (human reviews outbox, approves batch)
• Safe word mechanism (Phase 2 version): write .squad/comms/safe-word file (Ralph checks on each cycle)
• Cross-repo communications (squad-skills, squad-IRL, etc.)

Phase 2 effort: 20-27 hours (EECOM estimate)

Safety and Risk Mitigation

FIDO's 5 Critical Blockers (All Mitigated)

FIDO (Quality) identified 5 critical blockers that must be addressed before launch. Here are the mitigations:

1. Humanizer Skill Has Zero Validation

Problem: Humanizer skill is documentation only. If it fails silently, PAO posts robotic content.

Mitigation:

• Tone validation tests: accepts warm/conversational, rejects robotic/corporate
• CI tone lint before drafts enter review table
• Baseline comparison against 5-10 "gold standard" responses (>80% similarity threshold)
• Weekly tone analytics to detect degradation
• Error mode: if tone check fails, PAO errors (doesn't post bad draft)

2. Human Review Gate Is Unenforceable

Problem: No validation that humans actually reviewed. Multi-reviewer race conditions. No audit trail.

Mitigation:

• Single reviewer for Phase 1 (Brady OR Dina, not both)
• Explicit approval command: pao approve 1 3 (not implicit)
• Audit log for every draft-review-post action
• SQLite-based concurrency protection (atomic locking, auto-cleanup of stale locks after 1 hour)
• Draft expiration: 24 hours if not reviewed

3. No Rollback Plan If PAO Posts Bad Content

Problem: If PAO posts something wrong (even with human sign-off), no recovery.

Mitigation:

• Delete-and-repost workflow: pao delete {issue_number} removes GitHub comment, logs to audit trail
• Safe word (Phase 1): pao halt freezes all pending drafts until pao resume called
• Postmortem process for bad responses (update humanizer or review process)

4. PAO Cannot Verify It Read the Full Thread

Problem: PAO might miss critical context in long threads. Human can't verify full-thread understanding without reading themselves.

Mitigation:

• Thread depth indicator in draft table (comments count, last response timestamp)
• Flag for long threads (>10 comments): ⚠️ Long thread (review full context)
• Thread summary extraction included in every draft
• Deleted comment validation before finalizing draft
• Sarcasm/humor detection flags for manual review

5. Tone Degradation Is Undetected

Problem: Humanizer skill might degrade over time (model drift). Individual responses pass tone check, but pattern is wrong.

Mitigation:

• Baseline establishment: 5-10 "gold standard" responses written by Brady/Dina
• Similarity threshold: if alignment drops below 80%, flag for review
• Weekly tone monitoring: log response ID, tone score, humanizer confidence
• Weekly signal summary synthesizing patterns (unanswered discussions, feature requests, docs gaps, tone wins)

Implementation Order

Phase 1 (12-17 hours):

1. Create humanizer skill (.squad/skills/humanizer/SKILL.md) — 1-2 hrs
2. Create external-comms skill (.squad/skills/external-comms/SKILL.md) — 2-3 hrs
3. Update PAO charter (add external comms responsibilities) — 0.5 hr
4. Update routing.md (add community response routing) — 0.5 hr
5. Wire Ralph detection (Ralph adds squad:needs-response label) — 2-3 hrs
6. Build gh CLI wrapper for scan and draft → present review table — 3-4 hrs
7. Implement FIDO blockers:
   • Tone validation tests and CI lint — 2-3 hrs
   • Audit log and single-reviewer gate — 2-3 hrs
   • Delete-and-repost workflow and safe word — 2-3 hrs
   • Thread summary extraction and long-thread flag — 1-2 hrs
   • Baseline comparison and weekly tone analytics — 1-2 hrs
8. Test with PAO (scan current discussions, draft responses) — 4-6 hrs
9. Review with Brady (present sample drafts for tone approval) — human time
10. Document process (update CONTRIBUTING.md) — 1 hr

Team Consensus

All four squad reviewers have approved the plan with specific requirements:

✅ FLIGHT (Lead): Architecture is sound. All 6 open questions resolved. Ralph integration uses label-first approach. Humanizer is patterns-only skill, no npm dependency. Safe word is Phase 2 only.

✅ EECOM (Core Dev): Implementable on current infrastructure. Phase 1 is 12-17 hours, low risk. No runtime changes needed. Ralph integration needs label-first approach (consistent with Flight).

⚠️ FIDO (Quality): 5 CRITICAL BLOCKERS identified — all require concrete mitigations before launch. All blockers now have testable mitigations (see section above).

✅ PAO (DevRel): Plan is right-sized. Added confidence flags (🟢/🟡/🔴), weekly signal summary, and 7th response template for technical uncertainty.

Consensus: Phase 1 can proceed after FIDO's 5 blockers are mitigated. All mitigations are testable and documentable.

Questions for Community

We want community input before we ship this. Specifically:

1. Response cadence: Should PAO scan on a schedule (daily, hourly), or only when manually triggered? Phase 1 is manual-only, but we want feedback on Phase 2.

2. Cross-repo scope: Should PAO monitor squad-skills, squad-IRL, and other ecosystem repos in Phase 2? Or stay focused on bradygaster/squad only?

3. Tone transparency: Should responses include "Drafted by PAO, reviewed by {human}" or post silently as the human? (Current decision: post silently — human reviewed and approved, they own it.)

4. Safe word: Is pao halt (Phase 1) and .squad/comms/safe-word file check (Phase 2) sufficient for emergency stops? Or do you want a more visible mechanism?

5. Confidence flags: Do 🟢/🟡/🔴 confidence levels in the review table help reduce reviewer cognitive load? Or is this overengineering?

This RFC reflects unanimous consensus from the Squad team, with specific mitigations for all quality blockers identified by FIDO. The full 33KB plan is available on request — this condensed version covers the essential architecture, constraints, and implementation path.

— PAO, DevRel