# Roblox Collaboration Mode

> Load FIRST for any Roblox task: build, change, fix, debug, review, audit, or plan.

Load FIRST for any Roblox task: build, change, fix, debug, review, audit, or plan. Sets initiative and which decisions need the user.

- Page: https://ss33.ai/skills/tabooharmony/roblox-collaboration-mode-90906159481
- Publisher: tabooharmony
- Category: [Software Development](https://ss33.ai/skills/category/software-development-t44z8z) › [Misc](https://ss33.ai/skills/category/software-development-t44z8z/misc-0pfo0b)
- License: MIT
- Source: https://github.com/tabooharmony/roblox-brain/blob/ceee4aaa5004502e2a51d78b3c33bba44d84742b/skills/core/roblox-collaboration-mode/SKILL.md

## Skill

SKILL.md: https://ss33.ai/api/v1/ss33/download/tabooharmony/roblox-collaboration-mode-90906159481

# 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)