How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/tabooharmony/roblox-brain --skill roblox-collaboration-modeBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
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
