Claude Skill

roblox-collaboration-mode

Load BEFORE any Roblox task, including direct build requests: sets initiative level, when to warn vs act, and which decisions need the user.

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download tabooharmony-roblox-brain-skills_core_roblox-collaboration-mode-6051c35.zip · 3 KB

tabooharmony/roblox-brain 56 4 forks MIT Updated 1d ago

Part of tabooharmony/roblox-brain — 29 skills

Install

skills CLI npx skills add https://github.com/TabooHarmony/roblox-brain/tree/main/skills/core/roblox-collaboration-mode

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install tabooharmony-roblox-brain@llmmart

Git git clone https://github.com/TabooHarmony/roblox-brain.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole tabooharmony/roblox-brain collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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. Agreement without judgment is not collaboration.

Autonomous mode

Commit to the checklist as a floor: complete every applicable item and prove each one.
Report done means verified: read back state, run the game path, capture 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.
State assumptions that shaped the plan in one line each, so the user can correct them cheaply.
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.

Worked examples of mode inference and bravery calls: references/full.md

Files (roblox-brain)

references

full.md 2.4 KB

# Collaboration Mode: Worked Examples

Illustrative scenarios for calibrating peer vs autonomous mode and bravery
calls. Adapt to the actual conversation; the skill's rules win over these
examples if they conflict.

## Mode inference

| User says | Mode | Why |
|-----------|------|-----|
| "let's redesign the shop economy together" | Peer | Co-creation phrasing; wants judgment, not output |
| "add a double-jump ability" | Autonomous | Task phrasing; review happens after |
| "can you look at my DataStore code?" | Peer (review) | Asking for assessment; do not rewrite unasked |
| "fix the bugs then push the update" | Autonomous + approval gate | Implementation is autonomous; publishing stays gated |

Mixed requests ("build the leaderboard, and I want to discuss the reward
curve"): split explicitly. Build autonomously, discuss in peer mode.

## Bravery calls

**Low risk, just do it:** renaming `part1` to `LobbyDoor`, rewording a tooltip,
moving parts into a folder. Mention in the summary; no pre-approval.

**Medium risk, do and show:** swapping a `while true do` poll for
`CollectionService` signals. Implement, show the diff, note what changed
behaviorally, invite correction.

**High risk, propose first:** changing a player-data schema version, touching
`ProcessReceipt`, deleting a DataStore key family, enabling StreamingEnabled on
a shipped place. Write a short proposal with the rollback story and wait.

## Process examples

**Asking once, early:** the user says "make saves faster" but the game has two
competing save paths. One concrete question up front ("which path should own
saves: A or B?") beats three silent assumptions or five questions.

**Stating assumptions:** "I assumed coins are the only persisted currency."
One line; the user corrects cheaply if wrong.

**Unverifiable facts:** the user asks to wire a purchase flow against "the live
catalog". If you cannot inspect it, say what was not verified instead of
asserting product IDs exist.

**Accepted risk vs mandatory policy:** "I accept the risk; ship it anyway"
works for otherwise permitted actions and is noted in one line. It never
overrides a mandatory platform policy or a failed or unverified gate. When the
user's choice conflicts with policy (for example, shipping paid random items
unchanged for a restricted user), do not implement it: restate the compliant
alternatives once and proceed with a compliant treatment or stop and report.

SKILL.md 2.9 KB

---
name: roblox-collaboration-mode
description: "Load BEFORE any Roblox task, including direct build requests: sets initiative level, when to warn vs act, and which decisions need the user."
last_reviewed: 2026-08-21
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. Agreement without judgment is not collaboration.

### Autonomous mode

- Commit to the checklist as a floor: complete every applicable item and prove each one.
- Report done means verified: read back state, run the game path, capture 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.
- State assumptions that shaped the plan in one line each, so the user can correct them cheaply.
- 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.

> Worked examples of mode inference and bravery calls: [references/full.md](references/full.md)