Add these prompts to enforce SCRUM MCP usage.

# Project Instructions

**CRITICAL: Always use SCRUM MCP tools for ANY code changes.** Multiple agents may be working on this codebase simultaneously. SCRUM enforcement is mandatory - the server will reject non-compliant operations.

## HARD RULES (Non-Negotiable)

1. **NEVER use `git commit --no-verify`** - This bypasses compliance checks
2. **NEVER set `SCRUM_PRECOMMIT_SKIP=true`** - This disables enforcement
3. **NEVER modify files without posting intent first** - Server will reject claims
4. **NEVER release claims without attaching evidence** - Server will reject release
5. **ALWAYS run `scrum_compliance_check` before committing** - Verify your work

Violations of these rules will be caught by pre-commit hooks and your commits will be blocked.

## Session Startup (Do This First!)

When starting a session, use the token-optimized context tool:
```
scrum_context()     # Returns: status, tasks, claims, board in ONE call
```

Or for granular control:
```
scrum_status()      # Server status
scrum_task_list()   # Tasks
scrum_claims_list() # Claims
scrum_board()       # Board
```

This gives you situational awareness of what other agents are working on.

## Profile Selection

SCRUM MCP has three profiles with different tool sets. **Choose based on your situation:**

| Profile | Tools | When to Use |
|---------|-------|-------------|
| `solo` | 16 | Single agent, simple task. No sprint active, working alone. |
| `team` | 25 | Multiple agents on DIFFERENT tasks. Other claims exist, no shared sprint. |
| `full` | 38 | Sprint collaboration. Multiple agents on SAME task. |

**Auto-detection logic:**
```
if (sprint exists for task) → use "full"
else if (other agents have active claims) → use "team"
else → use "solo"
```

To check current profile:
```
scrum_context()  # Response includes suggested profile based on state
scrum_status(profile: "solo")  # Get only solo tools
```

## Agent Naming Convention

Use descriptive agent IDs for dashboard clarity and coordination:

**Pattern:** `{tool}-{role}-{shortId}`

| Example | Meaning |
|---------|---------|
| `claude-orchestrator-main` | Main orchestrator agent |
| `claude-worker-backend-a1b2` | Backend-focused worker |
| `claude-worker-tests-c3d4` | Test-focused worker |
| `cursor-reviewer-e5f6` | Code reviewer in Cursor |

**For sub-agent orchestration:** `{parent}-{focus}-{seq}`

| Example | Meaning |
|---------|---------|
| `main-auth-1` | First auth worker spawned by main |
| `main-frontend-2` | Second worker, frontend focus |
| `main-tests-3` | Third worker, test focus |

**Dashboard visibility:** When you see "main-auth-1 claimed src/auth.ts", it's immediately clear what that agent is doing and who spawned it.

## Code Quality Requirements

Before releasing any file claims, you MUST:

1. **Run tests** - All existing tests must pass
2. **No regressions** - Don't break what works
3. **Attach evidence** - Prove your changes work via `scrum_evidence_attach`
4. **Check compliance** - Run `scrum_compliance_check(taskId, agentId)` before committing
5. **Small, focused changes** - One concern per task, don't scope creep
6. **Review your own code** - Read it back before committing

Do NOT optimise for speed of completion. Optimise for correctness and maintainability. If unsure, ask the user rather than guessing.

## Multi-Agent Coordination with SCRUM MCP

This project uses **SCRUM (Synchronised Claims Registry for Unified Multi-agents)** for multi-agent coordination. When multiple AI agents work on this codebase simultaneously, they MUST use SCRUM to prevent conflicts and coordinate their work.

### Enforced Workflow

**SCRUM enforces this workflow at the server level. You cannot skip steps - the tools will reject your requests.**

#### Quick Workflow (v0.5.2 - Token Optimized)

```
# 1. Get context
scrum_context()

# 2. Start work (does: overlap_check → intent_post → claim)
scrum_start_work(
  taskId: "task-id",
  agentId: "your-id",
  files: ["file.ts"],
  acceptanceCriteria: "Tests pass"
)

# 3. Make changes, log each edit
scrum_changelog_log(agentId, filePath, changeType, summary)

# 4. Finish work (does: evidence_attach → compliance_check → claim_release)
scrum_finish_work(
  taskId: "task-id",
  agentId: "your-id",
  command: "npm test",
  output: "All tests passed"
)
```

#### Granular Workflow (Full Control)

1. **Check for conflicts** before touching any files:
   ```
   scrum_overlap_check(files: ["path/to/file.ts", ...])
   ```

2. **Find or create a task** for your work:
   ```
   scrum_task_list()  # Check existing tasks
   scrum_task_create(title: "Your task", description: "Details")
   ```

3. **Declare your intent** (REQUIRED before claiming):
   ```
   scrum_intent_post(
     taskId: "task-id",
     agentId: "your-unique-id",
     files: ["files/you/will/edit.ts"],
     boundaries: "What you WON'T touch",
     acceptanceCriteria: "REQUIRED: How to verify success (min 10 chars)"
   )
   ```

4. **Claim files** (will fail without intent):
   ```
   scrum_claim(agentId: "your-unique-id", files: ["file.ts"], ttlSeconds: 900)
   ```

5. **Make your changes** to the claimed files

6. **Log each change** to the changelog (do this AFTER each file edit):
   ```
   scrum_changelog_log(
     agentId: "your-unique-id",
     filePath: "path/to/edited/file.ts",
     changeType: "modify",  // or "create" or "delete"
     summary: "Added error handling to login function",
     taskId: "task-id"
   )
   ```

7. **Attach evidence** (REQUIRED before releasing):
   ```
   scrum_evidence_attach(
     taskId: "task-id",
     agentId: "your-unique-id",
     command: "npm test",
     output: "All tests passed"
   )
   ```

8. **Release claims** (will fail without evidence):
   ```
   scrum_claim_release(agentId: "your-unique-id", files: ["file.ts"])
   ```

### Debugging with Changelog

When investigating bugs or issues, search the changelog:
```
scrum_changelog_search(
  filePath: "suspect/file.ts",
  query: "error handling",
  since: 1702900000000
)
```

### Agent Identity

Each agent instance MUST use a unique `agentId`. See "Agent Naming Convention" section above for patterns.

**Quick examples:**
- Orchestrator: `claude-orchestrator-main`
- Workers: `main-backend-1`, `main-tests-2`, `main-frontend-3`
- Solo agent: `claude-solo-a1b2`

### Conflict Resolution

If `scrum_overlap_check` or `scrum_claim` returns conflicts:
1. Check `scrum_claims_list()` to see who holds the files
2. Wait for the other agent to release, OR
3. Coordinate by creating an intent explaining your needs
4. Work on non-conflicting files in the meantime

## Sprint Workflow (Multi-Agent Collaboration)

When multiple sub-agents work on the same task, use Sprint for shared context:

### If You're the Orchestrator

1. Create the sprint:
   ```
   scrum_sprint_create(taskId: "task-id", goal: "Describe the integration goal")
   ```
2. Pass `sprintId` to sub-agents when spawning them

### If You're a Sub-Agent (CRITICAL!)

1. **Join the sprint** (do this FIRST):
   ```
   scrum_sprint_join(
     sprintId: "sprint-abc",
     agentId: "your-agent-id",
     workingOn: "What you're implementing",
     focusArea: "backend|frontend|tests|api|auth|..."
   )
   ```

2. **Understand before coding** (ALWAYS do this before starting work):
   ```
   scrum_sprint_context(sprintId: "sprint-abc")
   ```
   Review:
   - `members`: Who else is working and on what
   - `decisions`: Architectural choices already made
   - `interfaces`: API contracts to implement/use
   - `discoveries`: Things others learned
   - `unansweredQuestions`: Can you help answer any?

3. **Do your work** (standard SCRUM: intent → claim → changes → changelog → evidence)

4. **Share your work** (help teammates understand your code):
   ```
   # Share decisions
   scrum_sprint_share(
     sprintId, agentId,
     shareType: "decision",
     title: "Using bcrypt for passwords",
     content: "Chose bcrypt over argon2 because..."
   )

   # Share interfaces (API contracts)
   scrum_sprint_share(
     sprintId, agentId,
     shareType: "interface",
     title: "AuthService API",
     content: "POST /auth/signin { email, password } → { token }"
   )

   # Share discoveries
   scrum_sprint_share(
     sprintId, agentId,
     shareType: "discovery",
     title: "Found existing session middleware",
     content: "Reuse src/middleware/session.ts"
   )

   # Ask questions
   scrum_sprint_share(
     sprintId, agentId,
     shareType: "question",
     title: "Where to store refresh tokens?",
     content: "localStorage vs httpOnly cookie?"
   )
   ```

5. **Check periodically** (every few changes):
   ```
   scrum_sprint_check(sprintId, agentId)
   ```
   Returns: teammates, unanswered questions, interfaces to implement

6. **Complete and leave**:
   ```
   scrum_sprint_leave(sprintId, agentId)
   ```

## Orchestration Workflow (v0.5.2)

When spawning multiple sub-agents for parallel work, use the orchestration tools for automatic coordination:

### If You're the Orchestrator

1. **Start orchestration** (creates sprint + generates worker configs):
   ```
   scrum_orchestrate_start(
     taskId: "task-id",
     orchestratorId: "claude-orchestrator-main",
     goal: "Implement user authentication",
     workers: [
       { focus: "backend", files: ["src/auth.ts", "src/db.ts"] },
       { focus: "frontend", files: ["src/components/Login.tsx"] },
       { focus: "tests", files: ["tests/auth.test.ts"] }
     ]
   )
   ```
   Returns worker configs with auto-generated IDs like `main-backend-1`, `main-frontend-2`, etc.

2. **Pass worker configs to sub-agents** when spawning them. Each config includes:
   - `agentId`: Pre-generated worker ID
   - `files`: Files to claim
   - `startCommand`: Ready-to-use scrum_start_work call
   - `completeCommand`: Template for scrum_worker_complete

3. **Monitor progress**:
   ```
   scrum_orchestrate_status(sprintId: "sprint-abc")
   ```
   Returns: active workers, completed/failed/blocked counts, any issues

4. **Complete when all workers done**:
   ```
   scrum_sprint_complete(sprintId: "sprint-abc")
   ```

### If You're a Worker (Sub-Agent)

1. **Start work** (uses the config passed by orchestrator):
   ```
   scrum_start_work(taskId, agentId, files, acceptanceCriteria)
   ```

2. **Do your work** (standard SCRUM: make changes → changelog_log)

3. **Signal completion**:
   ```
   scrum_worker_complete(
     sprintId: "sprint-abc",
     agentId: "main-backend-1",
     status: "success",  // or "failed" or "blocked"
     result: "Implemented JWT auth with bcrypt password hashing",
     filesModified: ["src/auth.ts", "src/db.ts"]
   )
   ```

### Orchestration Flow Diagram

```
Orchestrator                    Workers
     │
     ├─► scrum_orchestrate_start()
     │        │
     │        ├──► Worker 1: main-backend-1
     │        │         ├─► scrum_start_work()
     │        │         ├─► (do work)
     │        │         └─► scrum_worker_complete(success)
     │        │
     │        ├──► Worker 2: main-frontend-2
     │        │         ├─► scrum_start_work()
     │        │         ├─► (do work)
     │        │         └─► scrum_worker_complete(success)
     │        │
     │        └──► Worker 3: main-tests-3
     │                  ├─► scrum_start_work()
     │                  ├─► (do work)
     │                  └─► scrum_worker_complete(blocked)
     │
     ├─► scrum_orchestrate_status()
     │        └─► { success: 2, blocked: 1 }
     │
     └─► Handle blocked worker, then sprint_complete()
```

### Share Types

| Type | When to Use |
|------|-------------|
| context | Background info ("codebase uses TypeScript strict mode") |
| decision | Architectural choices ("using JWT with 15min expiry") |
| interface | API contracts ("POST /api/users { name, email }") |
| discovery | Things you learned ("found validation utils in src/utils") |
| integration | How to connect ("import AuthService from src/auth") |
| question | Ask teammates ("should we use Redis for sessions?") |
| answer | Reply to questions (use replyToId to link)

## Pre-Commit Enforcement

Git pre-commit hooks validate SCRUM compliance before every commit. If you:
- Modified files not declared in your intent → **BLOCKED**
- Touched boundary files (DO NOT TOUCH) → **BLOCKED**
- Haven't attached evidence (strict mode) → **BLOCKED**

### Before Committing

```
# 1. Check your compliance score
scrum_compliance_check(taskId: "task-id", agentId: "your-id")
# Returns: { compliant: true/false, score: 0-100, issues: [...] }

# 2. If compliant, commit normally
git add .
git commit -m "Your message"
# Hook validates automatically

# 3. If blocked, fix issues first
scrum_intent_post(...)  # Add missing files to intent
scrum_evidence_attach(...)  # Attach missing evidence
```

### FORBIDDEN Commands

These bypass enforcement and are NOT ALLOWED:
- `git commit --no-verify` ❌
- `SCRUM_PRECOMMIT_SKIP=true git commit` ❌
- `git commit --amend --no-verify` ❌

## Additional Tools (v0.5.1)

### Blockers
```
scrum_blocker(action: "add", taskId, description)    # Report blocker
scrum_blocker(action: "resolve", blockerId, resolution)  # Clear blocker
scrum_blocker(action: "list", taskId?)               # List blockers
```

### Dependencies
```
scrum_dependency(action: "add", taskId, dependsOn)   # Task X needs Y
scrum_dependency(action: "check", taskId)            # Are dependencies done?
scrum_dependency(action: "get", taskId)              # List dependencies
```

### Metrics
```
scrum_metrics(type: "board")     # Cycle time, throughput
scrum_metrics(type: "velocity")  # Story points over time
scrum_metrics(type: "aging")     # Stuck tasks
scrum_metrics(type: "task", taskId)  # Single task analysis
```

### Comments
```
scrum_comment_add(taskId, agentId, content)  # Add discussion
scrum_comments_list(taskId)                  # Read discussion
```