workbench-workflow

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.