GSwitch

Orchestrates a virtual engineering team with 7 roles working sequentially: Think, Plan, Build, Review, Test, Ship, and Reflect via shared memory coordination.

Security Scan

The skill's documentation describes a multi-agent build-and-deploy workflow but its runtime instructions ask agents to execute file operations, spawn subagents, and include filesystem paths in shared logs while failing to declare needed tools, timeouts, or credentials — several mismatches that could leak data or enable unsafe behavior.

Purpose & Capability

The skill claims to orchestrate a build→test→deploy workflow but does not declare any required binaries, environment variables, or credentials even though roles reference deployments, CI checks, real browser testing, and tools like 'exec', 'sessions_spawn', 'Claude Code', and image generators. Deploy and CI actions normally require repo/infra credentials and platform tools; their absence is an incoherence (either the skill assumes broad platform privileges or the documentation is incomplete).

Instruction Scope

SKILL.md and role files instruct agents to run commands via 'exec', open real browsers for E2E testing, spawn subagents, and repeatedly APPEND to a shared-memory folder while explicitly asking to 'INCLUDE file paths!'. That creates a risk of exposing internal filesystem structure or sensitive paths. The instructions also set runTimeoutSeconds: 0 (no timeout) in examples, enabling potentially unbounded agent runs if platform enforces that value. The guidance is broad and grants agents discretion to read/write project files and spawn fixes, which can be reasonable for automation but is not constrained or scoped here.

Install Mechanism

This is instruction-only (no install spec, no code files to execute). That lowers risk from arbitrary downloads. Installation is manual copying and config edits; no download URLs or extracted archives are present.

Credentials

No environment variables or credentials are declared, yet roles require actions that normally need secrets (deploying to production, running CI, accessing repos, image APIs). The skill repeatedly instructs including file paths in shared memory (potentially exposing secrets or config locations). Tools and services referenced (Claude Code, dalle/minimax-image, exec) are not declared as required resources. This mismatch suggests incomplete or under-specified privileges and raises the chance the skill will either fail or implicitly rely on broad platform permissions.

Persistence & Privilege

always is false (good). The skill instructs creating agents and modifying OpenClaw config and a shared-memory directory; that requires the user to write to workspace/config files but the skill does not request to be force-included. Autonomous invocation of agents and spawning subagents is core to the design; combined with the other concerns (no credential declarations, APPEND-ONLY shared memory containing file paths, unlimited runTimeout) this increases blast radius if misused. No evidence the skill modifies other skills or system-wide settings beyond the user's OpenClaw config.

What to consider before installing

What to consider before installing: 1) The skill's docs tell agents to run commands, open real browsers, spawn child agents, and include file paths in a shared-memory log — this can leak project structure and sensitive paths. 2) The skill references deploying to production and running CI but declares no credentials or required tools; decide where the agents will get repo/cloud access and don't point shared-memory at sensitive directories. 3) Set safe defaults before use: change runTimeoutSeconds from 0 to a finite limit, restrict spawn depth and concurrency, and sandbox any exec capability. 4) Review and sanitize the shared-memory path and the append format; avoid storing secrets or full absolute paths there. 5) Only run this on a non-sensitive workspace or in a sandboxed environment until you confirm behavior. 6) If possible, ask the author for an explicit list of required binaries/APIs and the minimal credentials needed (and why), and request documented safeguards for exec/sessions_spawn and deployment steps. Additional information that would reduce my concern: an explicit list of required tools/credentials and clear safeguards (time limits, sandboxing, least-privilege instructions) showing how deployments and exec calls are authorized and contained.

GSwitch - OpenClaw Multi-Agent Coordination System

Inspired by Garry Tan's GStack, adapted for OpenClaw

Concept

GSwitch turns OpenClaw into a virtual engineering team with 7 specialized roles working in a coordinated workflow.

Core Philosophy

"Skill feeds into the next. Nothing falls through the cracks because every step knows what came before."

Workflow: Think → Plan → Build → Review → Test → Ship → Reflect

---

The 7 Roles

Role	ID	Primary Function
CEO	{username}-ceo (Main)	Rethink problems, set direction
Engineering Manager	{username}-em	Architecture, technical decisions
Designer	{username}-designer	UI/UX, catch AI slop
Reviewer	{username}-reviewer	Code review, find bugs
QA Lead	{username}-qa	Real browser testing
Security Officer	{username}-security	OWASP + STRIDE audits
Release Engineer	{username}-release	Deploy, PR management

Note: Replace {username} with your own username when installing.

---

Shared Memory

All agents share: /path/to/GSwitch/shared-memory/{username}/

Format: YYYY-MM-DD.md Rule: APPEND ONLY, NEVER OVERWRITE

---

Configuration

{
  "maxSpawnDepth": 5,
  "runTimeoutSeconds": 0,
  "sharedMemory": "/path/to/GSwitch/shared-memory/{username}/"
}

---

Workflow Sequence

Phase 1: Think (CEO)

• /office-hours - Understand the problem deeply
• Output: Design document

Phase 2: Plan (CEO + EM + Designer)

• /plan-ceo-review - CEO reviews problem framing
• /plan-eng-review - EM reviews architecture
• /plan-design-review - Designer reviews UI/UX

Phase 3: Build (EM/Coder)

• Implement based on approved plan
• Write to shared memory on completion

Phase 4: Review (Reviewer)

• /review - Code review, find bugs
• Spawn related agent to fix if issues found

Phase 5: Test (QA)

• /qa - Real browser testing
• Identify issue type → spawn related agent to fix

Phase 6: Ship (Release)

• /ship - Deploy to production
• QA passed before deploy

Phase 7: Reflect (All)

• /retro - Document learnings
• Update shared memory

---

Coordination Rules - IMPORTANT

Core Principle

Each agent ONLY does their own job. NEVER do others' work. Send tasks to the right department.

Each Role Has Own Responsibility

Role	Responsibility
EM	Code, Architecture, Technical
Designer	Design, UI/UX, Content
Reviewer	Code Review
QA	Testing, Final Gate
Security	Security Audit
Release	Deployment

When Finding Issues

Issue Type	Send To
Code/Technical	→ EM
Design/UI/UX	→ Designer
Security	→ Security
Multiple types	→ All relevant agents

After Completion

1. Write to shared memory (INCLUDE file paths!)
2. Spawn next agent for workflow
3. If issues found → spawn related agent to fix
4. QA is the FINAL gate before Release

---

Shared Memory Format

Each agent appends:

### {username}-role | HH:MM
- 任務：[Task description]
- 結果：[Success/Failure]
- 發現：[Issues if any]
- 檔案位置：[Project file path]
- 下一步：[Next step]
---

---

Installation

1. Copy GSwitch folder to your OpenClaw workspace
2. Replace {username} with your username in all files
3. Create agents with IDs: {username}-em, {username}-designer, etc.
4. Set shared memory path in agent configs

---

Inspired by Garry Tan's GStack GSwitch for OpenClaw