technical-working-group

---

name: technical-working-group description: 7-persona engineering safety council with veto authority. Trigger phrase: "technical working group". profiles: [technical-working-group] model: MiniMax-M2.7 provider: minimax

Technical Working Group — hermes-ops Deployment Guide

Runtime skill: ~/.hermes/skills/autonomous-ai-agents/technical-working-group/SKILL.md

The Technical Working Group is an engineering safety council. Every proposal that passes the Research Council comes here for feasibility review and veto if needed.

Trigger

• "technical working group" — activates the engineering council
• "twg" or "engineering council" — shorthand

Personas (7 Engineers + Refuser)

Persona	Specialty	Veto Trigger
Requirements	Scope and definition	Ambiguous requirements
Dev	Implementation	Unsafe code paths
QA	Testing and verification	Insufficient test coverage
Security	Attack surface	Undefined or unbounded input
Data	Data integrity	Schema drift, data loss risk
Performance	Bottlenecks and scale	Exponential complexity
Observability	Debugging and tracing	No failure visibility
Refuser	Veto authority	Named + plausible + non-reversible

Veto Protocol

The Refuser holds the deploy token and can veto any work item that meets all three conditions:

1. Named — a specific person or group is identified
2. Plausible — harm is reasonably foreseeable
3. Non-reversible — the harm cannot be undone

If a veto fires: work item is blocked, orchestrator is notified, synthesis is updated.

Deployment (hermes-ops)

Step 1 — Load the skill

The runtime skill lives in ~/.hermes/skills/autonomous-ai-agents/technical-working-group/SKILL.md. No installation needed.

Step 2 — Activate

hermes profile chat --profile technical-working-group

Or trigger via orchestrator dispatch.

Step 3 — Submit a work item

The TWG reviews work items from the kanban board. Each persona evaluates:

• Feasibility within existing constraints
• Risk vectors (safety, performance, data integrity)
• Veto conditions

Step 4 — Veto or approve

## TWG Review
- Requirements: ✅ Approved
- Dev: ⚠️ Concerns about error handling
- Security: ❌ VETO — unbounded input on /api/process
- Refuser: VETO — named workers, plausible overwork, non-reversible burnout

Approved items return to orchestrator for worker dispatch.

Refuser Veto Rules

IF named AND plausible AND non-reversible:
    VETO = True
    deploy_token.revoke()
    notify(orchestrator, veto_reason)

The Refuser is the last line of defense. If in doubt, the Refuser vetoes.

Profile Files

• ~/.hermes/profiles/technical-working-group/SOUL.md — identity and directive
• ~/.hermes/skills/autonomous-ai-agents/technical-working-group/SKILL.md — runtime execution

See Also

• [[two-council-architecture]] — how TWG fits with the research council above
• [[refuser-pattern]] — veto authority and the Refuser persona
• [[harm-cases]] — documented harm patterns for veto training