---
name: workbench-workflow
description: Arma Reforger Workbench workflow, testing guidelines, and debugging patterns
version: 1.0.0
---

# Workbench Workflow

Quick reference for working with Arma Reforger Workbench. For detailed patterns, see resource files below.

---

## When to Use This Skill

Use this skill when:
- Testing changes in Workbench
- Debugging compile errors
- Understanding Workbench limitations
- Planning manual testing procedures
- Working with prefabs, configs, or layouts
- Troubleshooting runtime issues

---

## Quick Reference

### Testing Guidelines
No automated build or test system available. All testing manual via Workbench. User compiles in Workbench and reports errors. Be specific about what to test and how.

**See:** `testing-guidelines.md` for manual test procedures

### Compile Errors
EnforceScript has specific error patterns. Common issues: missing semicolons, ternary operators, type mismatches, missing strong refs. Errors show in Workbench console.

**See:** `compile-errors.md` for common errors and fixes

### Debug Patterns
Use Print() for debug output, check Workbench console logs. No interactive debugger. Add debug prints strategically to trace execution and inspect values.

**See:** `debug-patterns.md` for debugging techniques

### Workbench Tips
Prefabs edited in Workbench, layouts in UI editor, configs in text editor. Save often. Workbench can crash. Always test changes in play mode.

**See:** `workbench-tips.md` for Workbench best practices

---

## Critical Constraints

- ❌ **No automated builds** - User compiles in Workbench
- ❌ **No unit tests** - Manual play-testing only
- ❌ **No interactive debugger** - Use Print() for debug output
- ✅ **Be specific** - Tell user exactly what to test
- ✅ **Test incrementally** - Small changes, test often
- ⚠️ **Workbench can crash** - Save frequently
- ✅ **Check console** - Errors show in Workbench console
- ⚠️ **Play mode testing** - Always test in play mode, not just edit mode

---

## Workflow Pattern

### Development Cycle

1. **Write code** in Claude Code
2. **User opens Workbench** and compiles
3. **User reports** compile errors
4. **Fix errors** based on report
5. **Repeat** until compiles
6. **User tests** in play mode
7. **User reports** bugs/issues
8. **Fix issues**
9. **Repeat** until working

### Testing Cycle

1. **Define test procedure** - Specific steps to test feature
2. **User follows procedure** in Workbench play mode
3. **User reports results** - What worked, what didn't
4. **Fix issues** if needed
5. **Retest** until feature works

---

## Common Workflow

### After Code Changes

Tell user:
```
Please test in Workbench:
1. Open Overthrow.Arma4 in Workbench
2. Let it compile (check console for errors)
3. If compile errors, report them to me
4. If compiles: Enter play mode
5. Test: [specific steps]
6. Report: [specific things to check]
```

### After Compile Errors

Ask user:
```
Please copy the exact error messages from the Workbench console
and send them to me. I'll fix the compile errors.
```

### After Runtime Errors

Ask user:
```
Please:
1. Check the Workbench console for any error messages
2. Try: [specific test step]
3. Report: What happened vs what should happen
```

---

## Resource Files

Detailed documentation organized by concern:

1. **testing-guidelines.md** - Manual test procedures for different component types
2. **compile-errors.md** - Common EnforceScript compile errors and solutions
3. **debug-patterns.md** - Using Print(), console logs, debugging techniques
4. **workbench-tips.md** - Working with prefabs, configs, layouts, best practices

---

## Key Differences from Other Dev Environments

- **No npm/build scripts** - Workbench handles compilation
- **No test framework** - Manual testing only
- **No debugger** - Print-based debugging
- **No hot reload** - Restart play mode to test changes
- **No CI/CD** - Local Workbench testing only
- **User is QA** - User tests everything manually

---

**Pattern:** Start here for quick reference, dive into resource files for detailed procedures.