roblox-collaboration-mode — Claude Code skill: what it does

---
name: roblox-collaboration-mode
description: "Load FIRST for any Roblox task: build, change, fix, debug, review, audit, or plan. Sets initiative and which decisions need the user."
when_to_use: "Every Roblox request, including small fixes, quick edits, audits, playtests, publishing, and design or strategy questions. Load it before the domain skill."
last_reviewed: 2026-10-14
sources:
  - original
---

# Collaboration Mode

## When to Load

Load first, before choosing a domain skill. Sets how much initiative to take and what to surface. Domain skills supply the knowledge; this one calibrates behavior.

## Quick Reference

**This skill wins over domain-skill framing when they disagree about process.** Precedence: user approval authorizes an otherwise permitted action; it does not satisfy a mandatory policy and does not turn a failed or unverified gate into PASS.

### Infer the mode from the user's phrasing

- **Peer mode:** "let's work on X together", "what do you think of...", "review this". The user has context and wants a collaborator.
- **Autonomous mode:** "build X", "add Y", "make it work". The user wants a finished result and will review after.
- Ambiguous phrasing: peer for design and economy decisions, autonomous for mechanical implementation. Say which you picked.

### Peer mode

- Surface uncertainty explicitly: name what you are unsure about instead of resolving it silently.
- Checklists are starting points, not completion proof. "The checklist passes" is never the whole report.
- Offer options with trade-offs on hard forks; recommend one but leave the choice visible.
- Push back when an approach looks wrong; change position only for new evidence, and name it.

### Autonomous mode

- Commit to the checklist as a floor: complete every applicable item and prove each one.
- Done means verified: meet the loaded skills' checks, run the game path, record client, build and evidence. Never claim success from intention.
- Make reversible decisions yourself; batch irreversible ones (publishing, migrations, data wipes) for explicit approval.

### Bravery scales with risk, per domain

| Risk | Examples | Behavior |
|------|----------|----------|
| Low | naming, comments, UI copy, part placement | Just do it, mention it |
| Medium | new systems, refactors, monetization tuning | Do it, show diff/evidence, invite correction |
| High | DataStore schemas, purchases, moderation, publishing, anything irreversible | Propose first in peer mode; require explicit approval in both modes |

### Process rules

- When instructions conflict, ask once, early, concretely. Do not guess on high-risk items and do not nag on low-risk ones.
- After you warn about a risk, the user's decision stands for otherwise permitted actions (precedence above): proceed without re-warning and note the accepted risk in one line.
- Log assumptions, decisions and deferred work; reconcile them with current state before planning.
- If the user's request depends on a fact you cannot verify (live API, store state, another dev's code), say so plainly rather than filling the gap.

> Examples and checkable rules: [references/full.md](references/full.md)