Working Group Architecture Helper

Your agent for facilitating working group discussions on software architecture — helping structure proposals, evaluate alternatives, build consensus, and produce actionable outcomes from group decision-making.

When to Use This Agent

Choose Working Group Architecture Helper when:

• Facilitating architecture working group meetings and discussions
• Structuring RFC (Request for Comments) proposals for team review
• Building consensus on cross-team technical decisions
• Documenting working group outcomes as Architecture Decision Records
• Evaluating competing proposals with structured comparison frameworks

Consider alternatives when:

• You need individual architecture advice — use an architect agent
• You need implementation planning — use a planner agent
• You need code review — use a code reviewer agent

Quick Start

Copy
# .claude/agents/wg-helper.yml
name: Working Group Architecture Helper
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Architecture working group facilitator for structured proposals, consensus building, and decision documentation

Example invocation:

claude "Help structure our working group's discussion on adopting a service mesh — create an RFC comparing Istio, Linkerd, and Consul Connect against our requirements"

Core Concepts

RFC Process

Phase	Activity	Duration
Draft	Author writes initial proposal	1 week
Review	Team members leave comments	1 week
Discussion	Working group meeting to address concerns	1-2 meetings
Decision	Accept, reject, or revise	Meeting consensus
Implementation	Approved RFC becomes a project	Per roadmap

RFC Template

Copy
# RFC: [Title]

**Author**: [Name]  **Status**: Draft  **Date**: YYYY-MM-DD

## Summary
[1-2 paragraph overview]

## Motivation
[Why this change is needed]

## Proposal
[Detailed description of the proposed approach]

## Alternatives Considered
### Option A
- Pros / Cons / Risk

### Option B
- Pros / Cons / Risk

## Migration Plan
[How to adopt this incrementally]

## Open Questions
[Questions for the working group]

Configuration

Parameter	Description	Default
process_type	Decision process (rfc, adr, lightweight, formal)	rfc
consensus_model	Agreement model (unanimous, majority, lazy-consensus)	lazy-consensus
stakeholders	Who must approve (team-leads, architects, all)	architects
documentation	Output format (rfc, adr, meeting-notes)	rfc
timeline	Decision timeline (days)	14

Best Practices

1. Separate the proposal from the discussion. The RFC document should present the proposal objectively. Discussion, objections, and alternatives belong in comments or meeting notes. This keeps the proposal clean and makes the final decision document useful as a reference.

2. Use lazy consensus to avoid decision paralysis. In lazy consensus, a proposal is accepted unless someone explicitly objects within the review period. This prevents decisions from stalling because busy people haven't responded. Silence equals agreement.

3. Require alternatives in every proposal. A proposal without alternatives is a mandate, not a decision. Even if the author is confident in their approach, documenting alternatives shows due diligence and gives reviewers confidence that options were evaluated.

4. Time-box discussions to force decisions. Set a decision deadline (2 weeks from RFC publication). If consensus isn't reached by the deadline, the working group chair makes the call. Open-ended discussions drift indefinitely.

5. Archive all RFCs regardless of outcome. Rejected proposals are valuable — they document why an approach was considered and rejected. Future teams with the same idea can read the rejection rationale instead of re-evaluating from scratch.

Common Issues

The loudest voice dominates the working group. Structured RFC processes give everyone time to read and comment asynchronously before the meeting. Require written comments before the discussion meeting to equalize participation.

Working group decisions are ignored by teams. Decisions without follow-through plans are just opinions. Attach implementation tasks, deadlines, and owners to every decision. Track adoption in subsequent meetings.

RFCs take months to resolve because they're too broad. An RFC that proposes changing the entire platform architecture will never reach consensus. Scope RFCs to specific, bounded decisions that can be evaluated independently.