roblox-collaboration-mode
Skill150 starsChanged 51 days agoMITView on GitHub
Load FIRST for any Roblox task: build, change, fix, debug, review, audit, or plan. Sets initiative and which decisions need the user.
In this repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- roblox-architectureSkill
- roblox-dataSkill
- roblox-luau-coreSkill
- roblox-luau-patternsSkill
- roblox-luau-typesSkill
- roblox-networkingSkill
- roblox-performanceSkill
- roblox-securitySkill
- roblox-server-dataSkill
- roblox-analyticsSkill
- roblox-game-designSkill
- roblox-growth-designSkill
- roblox-monetizationSkill
- roblox-player-psychologySkill
- roblox-animation-vfxSkill
- roblox-audioSkill
- roblox-buildingSkill
- roblox-cameraSkill
- roblox-guiSkill
- roblox-inputSkill
- roblox-lightingSkill
- roblox-localizationSkill
- roblox-npc-aiSkill
- roblox-physicsSkill
- roblox-cloudSkill
- roblox-publish-checklistSkill
- roblox-studio-mcpSkill
- roblox-toolingSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 35
Commit to the checklist as a floor: complete every applicable item and prove each one.
- Distinctive: line 49
When instructions conflict, ask once, early, concretely.
- Distinctive: line 50
After you warn about a risk, the user's decision stands for otherwise permitted actions (precedence above): proceed without re-warning and …
- Distinctive: line 52
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 …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.