File Permissions

"Single-writer principle prevents race conditions – know what you can write to."

When to Use This Skill

Use when:

• Unsure if you can write to a file
• Need to know who owns a specific file
• Resolving file conflicts

Use proactively:

• Before writing to any shared file
• When coordinating between agents

Quick Start

Example 2: Developer updating own status

// ✅ Developer CAN update own agent fields:
{
  "agents": {
    "developer": { "lastHeartbeat": "2026-01-23T12:00:00Z", "status": "working" }  // ✅
  }
}
// ❌ CANNOT update other agents' fields

Example 3: QA updating validation results

// ✅ QA CAN update validation fields:
{
  "items": [{ "id": "feat-001", "passes": true, "validationResults": {...} }]  // ✅
}

Core Principle

Each file has a primary owner to avoid conflicts. Only the owner may write to that file.

File Ownership

Permission Rules

1. Read-modify-write atomically - See shared-atomic-updates
2. Only update fields you own - Never overwrite another agent's data
3. Append-only for logs - Never delete or reorder entries
4. Retry on conflict - If write fails, re-read and retry once
5. Use per-agent files for frequently updated data

What Each Agent CAN Write To

PM Coordinator

Developer Worker

QA Worker

Tech Artist Worker

Game Designer Worker

Commit Permissions

ALL agents MUST commit their file changes.

No Commit Exceptions: Heartbeat updates, temporary message files.

Concurrency Rules

1. Never overwrite entire files - Update specific fields only
2. Use atomic updates - Read-modify-write to temp file, then rename
3. Check file locks - If .lock file exists, wait or retry
4. Additive updates - For logs, append only
5. Field-level ownership - Multiple agents can update different fields in same file

Conflict Resolution

If you encounter a write conflict:

1. Re-read the file - Get latest state
2. Re-apply your changes - On top of new state
3. Write again - Using atomic pattern
4. If still conflicts - Log issue and wait 30 seconds

Related Skills