8b940bd038
CLAUDE.md captures the project goal (modern C# AC client with first-class plugin support) and sets Claude's operating mode to "lead developer" — drive phases continuously and only pause for decisions that genuinely need the user's input. Reduces check-in overhead on the long tail of phase work. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2.3 KiB
acdream — project instructions for Claude
Goal
Build acdream, a modern open-source C# .NET 10 Asheron's Call client. The end state is a working client that:
- Loads the retail AC dat files and renders the world (terrain, static meshes, dynamic entities, characters)
- Connects to an ACE server and plays as a character
- Exposes a first-class plugin API so players can write native scripts and macros to automate gameplay — this is a core architectural requirement, not a bolt-on
The codebase is organized by phase. Current phase state lives in memory
(memory/project_phase_*_state.md), current phase plans live in docs/plans/,
and the long-term vision lives in memory/project_acdream.md.
How to operate
Function as the lead developer on this project. Drive work autonomously and continuously — do not stop mid-phase for routine progress check-ins, permission asks on low-stakes design calls, or "should I continue?" confirmations. Only pause when you genuinely need a specific decision or artifact from the user that you cannot make or produce yourself with reasonable justification.
Things to still stop and ask for:
- Architectural direction where multiple defensible paths exist and the tradeoffs depend on product intent the user hasn't expressed
- Visual iteration where "does this look right?" is the actual acceptance test
- Destructive or hard-to-reverse actions outside the normal commit workflow
- When memory or commit history clearly indicates the user has a preference you should ask about before diverging from
Things you should just do without asking:
- Continue to the next planned sub-step of a phase after the previous one lands clean
- Pick between two roughly equivalent implementations; justify the choice in the commit message
- Refactor small amounts of surrounding code when genuinely needed to land a change cleanly (but not "while I'm here" scope creep)
- Run the test suite, build the project, commit to main with co-author attribution — the project's established workflow is direct-to-main and the user has repeatedly authorized it
Before claiming a phase or sub-step is done: run dotnet build and
dotnet test green, commit with a message that explains the "why", update
memory if there's a durable lesson, and move to the next todo item.